Patch v0.0.32 should address this issue. Again, I apologize for the inconvenience.
Just added patch v0.0.33 to address some bugs -- thanks for reporting them, Alan!
- Adjusted some layout items when WazeBar is in full-screen mode.
- Fixed bug where WMECH wouldn't show if enabled, but not integrated.
- Fixed bug where current theme was not properly marked as checked in WazeBar menu (cosmetic implications only).
Patch 0.0.34 finally updates the user-interface, giving WazeBar a much needed face-lift!
Hi Alan, thanks for testing!AlanOfTheBerg wrote:Here's a functionality bug:
1. Enter in a search and go there.
2. Click in the Search box and drag to highlight the previously-entered search info, because you want to replace it with a new search.
3. Don't stop the drag in the box, but holding the mouse down, continue dragging left or right.
What happens when you release the mouse button: whatever portion of the Waze Bar you release from will send a mouseup event and activate that control.
What should happen: wherever you release the mouse button should not activate that control, but retain focus/action on the search box.
I'm conflicted with this one:
- Buttons should respond to the mouseup event, so that it gives you a chance to move your mouse off the button if you change your mind, therefor not triggering it. mousedown or click events would all trigger before you take your finger off the mouse; you haven't committed yourself yet to that decision.
- Does anyone drag to highlight text in an input field anymore? One-click: focus; double-click: select word; tripple-click: select all content in the input field.
Perhaps the solution here is to auto-select the content on focus?
1. Yes, sometimes the page takes too long too load before WazeBar tries to position its menues. I have this on the to-do list. You should see the menu position improve after reloading (which should go faster.AlanOfTheBerg wrote:Shiny!
I do wish some of the icons had some color to them. But it works just fine for me.
Here's a couple issues I noticed just in terms of visual. This is all in the beta, because, as you noted, that's the future interface, so I figure to spend my testing time there:
1. Clicking on Highlight Segments and the drop-down appears under the word "Welcome" way to the left
2. The + menu is missing Gas Station and Parking Lot
3. When integrating WMECH and URO, in the beta, their respective tabs still appear.
4. Highlight segments in last x days doesn't have a default number of days. I thought there used to be a '7' in there?
2. Ah, two new items. Will add them ASAP.
3. I'll check that out, easy enough to fix, providing its not a result of an error.
4. Not sure about this one. I'll check to make sure its getting the values properly.
That absolutely makes sense. I'll have to think about how best to track and control that aspect without introducing more bugs. The difference here is that one is a web control, and the other is an app control -- they don't always behave the same, even though one might expect they should.AlanOfTheBerg wrote:Here's my take on the functionality expectations: (I am unsure what the technical difference between a mousedown/up and a mouseclick event.) If the mousedown/up event doesn't occur in the same control, then the control shouldn't activate.mike-bronner wrote:I'm conflicted with this one:
- Buttons should respond to the mouseup event, so that it gives you a chance to move your mouse off the button if you change your mind, therefor not triggering it. mousedown or click events would all trigger before you take your finger off the mouse; you haven't committed yourself yet to that decision.
- Does anyone drag to highlight text in an input field anymore? One-click: focus; double-click: select word; tripple-click: select all content in the input field.
Perhaps the solution here is to auto-select the content on focus?
I compare this to the same action if you highlight the URL in the address bar of Safari and drag further to a menu or back button or right to the RSS/refresh controls. None of them activate when the drag ends there.
This is a pretty minor bug, but one I found accidentally, so it could happen to anyone, right?
I was contemplating that as well.AlanOfTheBerg wrote:Future auto-save functionality: ability to adjust the auto-save change count value. I find 10 is too few for me.
Haha!AlanOfTheBerg wrote:I forgot I set it, and then it saved in the middle of making many edits and thought "How did I hit Ctrl+S?" And then it did it again and I thought, "I was nowhere near save. WTH!?" And then I remembered...
Good point. I think I know how it can be done ... have you gotten a response from bgodette?AlanOfTheBerg wrote:Auto-save and GeoWipe can conflict. Well, that is, auto-save will interrupt GeoWipe. If you are at 9 edits and select five segments to wipe, only one of the segments will actually get wiped because autosave kicks in and doesn't allow the other wipes to proceed.
Have fun figuring out if that one can be worked around!? (Well, as an external script, probably not, but if you were to pull it internally, perhaps?)
Roger that. Bug found, squashed, and ready for next patch.AlanOfTheBerg wrote:Found a bug: the change counter does not update when doing undo. You can use Ctrl/Cmd+z or hit the Undo button to perform the undo, and while the undo actions are happening on the map, the counter doesn't change. Because of this, the re-do button state doesn't properly update.
It will change and reflect the correct current number of changes if you hit Ctrl+Shift+z to re-do. (You can't hit the button because it stays disabled even after using Undo.)
Patch v0.0.35 should address the following issues:
- Fixed enabling/disabling of edit buttons based on available edits, selections, etc. This includes Save button and counter, Undo, Redo, and Delete buttons.
- Fixed bug where URO and WMECH options were still displayed in tabs on WME Beta.
- Added Gas Station and Parking Lot to Add menu.
Re: WazeBar v0.0.32 - Safari Extension for Waze Map Editor