LineEdit: implement show-password icon for the Qt style

[dfaure]

The implementation and icon come from the material style, given that Qt itself doesn't have that feature.

[ogoffart]

given that Qt itself doesn't have that feature.

Maybe that's a reason not to merge this. The goal of the Qt style is to integrate into "native" Qt desktop, and if password fields don't have this feature, then we shouldn't have it.
What do you think?

(Implementation looks good otherwise)

[dfaure]

Well, my thinking was that we could do better than Qt :-)
It feels weird that a feature would disappear just by changing the style of a slint app.
In other words, I don't see why slint users should be penalized by the fact that Qt is inferior, when using a slint app.

Also, some people implement this feature on top of Qt (e.g. https://qgis.org/pyqgis/3.40/gui/QgsPasswordLineEdit.html, https://kushaldas.in/posts/creating-password-input-widget-in-pyqt.html) which is exactly what I'm proposing to do here.

[dfaure]

@tronical @szecket Any opinion?

BTW I noticed since my last comment that password lineedits in KDE also have a reveal icon.

[tronical]

Slint defaults to the Qt style only on Linux. On Linux, the Qt style can have a variety of different looks.

The tradeoff I see is between the password icon ruining the appearance with a particular style and the user missing out on the feature of being able to see (toggle) the password in cleartext.

In the most general scope, this seems very risky. If suddenly a QStyle came around the renders a line edit in a significantly different way, the assumptions here about placement and layout might be visually and usability wise bad.

That said, I don’t see massive development on the Linux desktop styling in combination with QStyle. So I think this is a safe patch to apply. Just my two cents :)

[tronical]

(On a more general note, I tend to agree with the issues about the use of icons outlined here and prefer an overall different design that uses text, which also implies custom controls)

[dfaure]

(I have to disagree with that article. Just because Twitter got it wrong, doesn't mean the rest of the world is pretty much aligned, which is actually one of the recommendations of the article.... Text based solutions are very verbose and eat too much space.
And really, what's the actual problem? Can't people see the actual black-circles taking the place of the password letters? That itself is pretty clear about the current state of things.
The only problem I can see is when it's empty and people start to type. We could decide to fix that by saying that empty always reverts to hidden. Not sure what other implementations do about this though...)

[szecket]

I think the functionality is nice to have. I think the visual language, while sometimes backwards is just double reinforcement of the dots that appear by default so pressing the button just toggles the current state. They all can be confusing given the right context.

[dfaure]

Is there any reason left for this not to be merged?