The details like this are important to get right and as far as I can see the convention of the icon being the action that will be performed is followed. Not a bug in this case, but worth discussing as it could mean there are other icons that may be wrong.
I have a media player control widget (no idea what is the real name) and it shows me this:
Bottom left is in the KDE panel and shows me the present status of the player, which was paused during 1st screenshot.
In the widget you see the arrow button in the middle indicating when you click it the player will (re-)start playing.
In the second screenshot it is kust the other way around.
Not at all.
You keep approaching this from your original perspective, that this is obviously wrong and needs to be changed. People have shown you lots of examples that it is nowhere near as obvious as you claim, yet they are the ones resisting improvements.
In any case, since there is no clear consensus on what is correct (see the examples), I think being consistent is more important here. Which means using what your toolkit provides or what your HIG mandate. This way, even if someone considers the behaviour wrong, it’s at least the same everywhere.
First, people were opposed to improvements and now you accuse me of lying when I am just reiterating previous posts, which you seem to have either ignored or misread:
As you can see, these posts all express that the current version is correct/consistent, and I was just trying to get that point across and politely suggesting that you may want to take a different perspective than “I am right, it’s obvious, and everyone else is resisting improvement”.
Sure, that’s why the button on a password field with hidden contents has an open eye symbol, to make you able to see. Just like other buttons are labelled with the result of the act of clicking, like “save”, “search”, “replace”.
I did. The whole article is about the fact that the current iconography is ambiguous and not at all clear, unlike what you keep repeating. Sure, they suggest a solution to standardize the design language. And in that paragraph, they even suggest the same as you. But I don’t read this as “this is obvious, so let’s all use the same symbols”, they suggest standardization and then pick one, without any justification. And from my experience and the examples that I and others have shown you, this seems to be the rarer of the two semantics.
In any case, I am done engaging with this. I don’t appreciate being accused of lying, when I am just trying to help. I wish you all the best in this thread and in this community.
I agree with Lars above. The eye should show what will happen when it is clicked and not the current state.
There are many other places where this is the same, including many web site signin pages such as banks, medical records sites, etc.
Please always be nice to others. We can disagree on what we believe should be correct without making personal attacks. Calling Lars a ‘liar’ is a personal attack. This behavior goes against the CoC for this forum and potentially can cause those who misbehave to be banned from the site.
I possible solution to clarify this ambiguous button behavior if there is room would be to show the current state with an arrow pointing to the new state if clicked.
That may be possible, but it is certainly (to me at least) unambiguous for the closed eye to indicate hide and the open eye to indicate show.
Even in the new setup screens for fedora Workstation there is a button bar that displays enable 3rd party repos that clearly indicates what clicking that button does, and not the current state of the toggle. (many other similar toggles indicate the same – the anticipated result and not the current state)
Yes, agreed. I understand it how it works. Honestly I don’t even think I’ve ever paid attention to it. I just click it until it displays my password and never bothered to consider what the button meant. However, this might help OP understand it.