Feature Requests

[prroots]

Originally Posted by fgd3

That's a very good point. Also, the track button doesn't change color until you move the mouse pointer off of it after you've selected it, which makes it even harder to know if it has been selected. I think all the buttons behave that way, making it hard to be certain a mouse click registered.

Fabbian

Yes, I agree. I've asked previously for some more obvious way to know if tracking is enabled or disabled.
Pete

[HappySeagull]

per track button.just musing and I'm ignorant of what's possible but I'm guessing that it can't be "solved" at the button itself, because the track button is in the toolbar- nothing wrong with that- but there,maybe, it's restricted as to how its display can differ from its fellow buttons...?
so maybe an indicator could be meshed with the gps indicator icon ...perhaps a little red Track- ON light maybe added to the gps icon ...? because "tracking" and GPS are functionally linked anyways....

[HappySeagull]

but that idea conflicts with existing icon... sort of.


TRACK OFF as it is...

TRACK ON?

Maybe the "NoGPS RedDot" could just be repurposed ? or disappear?

[maxxflow]

Originally Posted by HappySeagull

per track button.just musing and I'm ignorant of what's possible but I'm guessing that it can't be "solved" at the button itself, because the track button is in the toolbar- nothing wrong with that- but there,maybe, it's restricted as to how its display can differ from its fellow buttons...?
so maybe an indicator could be meshed with the gps indicator icon ...perhaps a little red Track- ON light maybe added to the gps icon ...? because "tracking" and GPS are functionally linked anyways....

What about just changing the icon on the toolbar button according to status? A red dot in one corner of the button = tracking on, or something similar.
Should be very clear and hard to miss, and avoids introducing new potentially non-intuitive UI elements.

[Viking Sailor]

I truly hate to disagree with you guys...

But I really have no problem telling the state of the track button regardless of whether or not the mouse pointer is on the button. Could this be a case of "better is the enemy of good enough"? It doesn't look broken to me!

Sure, the tool bar buttons could be grouped a bit better. But the buttons all seem to work as they should.

[maxxflow]

We have to realize that any user's experience depends entirely on what platform, underlying widget toolkit & theme is being used. In some cases, it might be be no problem at all to tell the state of a bi-stable button.

In principle, I agree that this shouldn't be fixed in OpenCPN, but upstream in the widget toolkits. But for a practical fix, since many users have a problem here, it might be OK with a fix such as a red dot in the activated button's icon..?

What I really would like to see, though, is a way to configure which buttons are visible. This is not possible now, if I am not mistaken?
I'm thinking of how most word processors etc. let you add/remove buttons and even entire toolbars. That functionality would be great, and I suspect there must already be provisions for it in wxWidgets?

[HappySeagull]

... there are several buttons on the toolbar I never use...the zoom buttons, the change chart scale buttons and (off topic a bit- those green arrows at the screen edge...) maxxflow's idea has merit and I have several other apps I could name that allow choosing tool buttons and I always use that feature where it's available....

Viking,well said. If this were to fatten O by a mb, or mean she needs plastic surgery I'd say forget it. I am suggesting a "Cosmetic Improvement" - Maybelline for O. The track button as is works. It's just that little pause where I peer. It's a pimple. I'm picking at it.... (noted in passing, is there no keyboard shortcut to toggle tracking? ) Anyways, it's bringing up other ideas , that hadn't occurred to me!

You can see from the screengrabs I made what the Track button looks like on my screen on and off. I have to be right in front of the computer to know..or wait for the trackline to appear by zooming in . If my mouse is wireless from a distance it's a little harder. If the buttons went darker or changed colour a little more?

[fgd3]

Originally Posted by Viking Sailor

I truly hate to disagree with you guys...

But I really have no problem telling the state of the track button regardless of whether or not the mouse pointer is on the button. Could this be a case of "better is the enemy of good enough"? It doesn't look broken to me!

Sure, the tool bar buttons could be grouped a bit better. But the buttons all seem to work as they should.

Standard behavior on Windows, Macs, and the few Linux GUIs I've seen is the screen button changes when the mouse button is depressed to show the button down event was recognized. No action takes place until a button up event. If you move the pointer off the button the action is cancelled. I don't think the toolbar button behavior measures up to "good enough".

It's also the case that the toolbar buttons don't show their state clearly enough. A slightly darker shade of gray really isn't a good indicator.

Fabbian

[Viking Sailor]

Originally Posted by fgd3

Standard behavior on Windows, Macs, and the few Linux GUIs I've seen is the screen button changes when the mouse button is depressed to show the button down event was recognized. No action takes place until a button up event. If you move the pointer off the button the action is cancelled. I don't think the toolbar button behavior measures up to "good enough".

It's also the case that the toolbar buttons don't show their state clearly enough. A slightly darker shade of gray really isn't a good indicator.

Fabbian

Fabbian,

What I see on XP is that when the mouse cursor is over an unselected tool bar button a thin line box appears around the button. When the left mouse button is depressed the thin line box becomes a thick (bold) line box. When the left mouse button is released the button state changes to the selected state indicated by a darker button surrounded by a thick line box. This process is reversed when going from the selected to the unselected button state. And, yes, if the mouse cursor is moved off the button before left mouse button is released the select/deselect action will be cancelled. This seems like a well thought-out and logical design with unambiguous indications of each step in the process of going from one state to the other.

And, you have stated this is the standard for Windows, Macs, and some Linux GUI's. Why deviate from this standard? Please, what am I missing here?

Thanks,

[bcn]

Simply that to Happy happened the same as to me (XP and W7):
you just don't notice that the Track mode is not enabled (or you have to look at least twice to be sure).

Nobody questions that the behavior of the user interface adapts the the "style sheet", but it is just not practical.
So my vote as well for having a more "prominent" visual feedback for the state of the function.

bcn

[Jubilee39]

Originally Posted by HappySeagull

I wish it was more obvious that the track button is ON.

The other buttons, well it's pretty obvious, click em, a window opens or the route-pencil attaches to the cursor etc...,but with the track button, it goes a darker shade of pale and if you wait ten minutes (in a sailboat), you'll see the track...hmmm.10 minutes?
My point is, its nature is different from the other buttons.. Perhaps it could blink, or turn red,or something more indicative of "on-ness" than such a slight change. Perhaps my issue is exacerbated by XP in so-called "Classic" look...

I would also like to see a definite indication of tracks on and off. I like to stop and restart the track entering a new bay to make a short file for entering and leaving again.

[fgd3]

Originally Posted by Viking Sailor

Fabbian,

What I see on XP is that when the mouse cursor is over an unselected tool bar button a thin line box appears around the button. When the left mouse button is depressed the thin line box becomes a thick (bold) line box. When the left mouse button is released the button state changes to the selected state indicated by a darker button surrounded by a thick line box. This process is reversed when going from the selected to the unselected button state. And, yes, if the mouse cursor is moved off the button before left mouse button is released the select/deselect action will be cancelled. This seems like a well thought-out and logical design with unambiguous indications of each step in the process of going from one state to the other.

And, you have stated this is the standard for Windows, Macs, and some Linux GUI's. Why deviate from this standard? Please, what am I missing here?

Thanks,

Thanks for your comment. I had missed the thin border which appears when the pointer is moved over the toolbar button and the darker border which registers the button down event. I think those indicators are too subtle and should be made more obvious, but at least they are there.

This is the part you missed. (Maybe there's a difference between XP and Vista and W7. My experience is limited to the latter two.) Where the toolbar buttons deviate from the standard is they do not indicate the button up event has occurred until you move the mouse pointer away from the toolbar button. Only then does the button get darker. The toolbar button should darken immediately when button up occurs.

I just noticed that when you move the mouse pointer over a toolbar button the button turns bright (it's unselected state) as well as showing a thin border. So that may be what masks the button up event until the pointer is moved off the button.

Fabbian

[HappySeagull]

...try the "man overboard" button...no permanent border,no darkening ...does it need one? it isn't really an on-off device! It's a mark dropper.How do you know it dropped a mark? Why, it's on the chart... I see there is logic to the button toolbar but "subtle" is a good description. I still think the purpose of the tracking button (and the autofollow button too) separate these from their fellows as being "on-off" and being gps-oriented and could be improved by giving them a different treatment....maybe they should be grouped together too....

[fgd3]

Originally Posted by HappySeagull

...try the "man overboard" button...no permanent border,no darkening ...does it need one? it isn't really an on-off device! It's a mark dropper.How do you know it dropped a mark? Why, it's on the chart... I see there is logic to the button toolbar but "subtle" is a good description. I still think the purpose of the tracking button (and the autofollow button too) separate these from their fellows as being "on-off" and being gps-oriented and could be improved by giving them a different treatment....maybe they should be grouped together too....

I agree there should be a clear indicator of the state of the auto-follow and tracking functions. A good way to handle it without using any more screen real estate is to put a "light" in the button or to make the button change to a high contrast color. If you use the button as the indicator it's immediately clear what the indicator means. If you add a separate indicator elsewhere you have to give up additional screen space for the indicator and a label that identifies it.

Once again I want to emphasize the importance of providing visible feedback for the button up event. The present approach is just wrong.

Fabbian

[dougwm10]

I am very surprised and concerned by the number of comments regarding the legibility of the menu buttons.

It should go without saying that the operation of each of the buttons MUST be CLEARLY apparent to the user at all times in good and bad conditions.

This is presently not the case and it must be addressed sooner rather than later by the development team.

The use and operation of OPCN must also be easily and clearly identifiable by users with less than perfect eyesight and in bad weather.