Registered Member
|
I came to this forum today precisely to report this: it's interesting that this thread got bumped not long ago, and it's also interesting that this behavior was reported 1 year ago and was not changed (without any more discussion from what I could find). So, as a user, I'd like to answer: the second line is perfectly clear, the first line requires a conscious effort every time. I believe that the other way round (i.e. "white always means unchecked, even when the line is selected") would have been slighly more intuitive, but still not clear-cut. In my opinion: - the appearance of a ticked checkbox should not change if the line is selected, only if the tick-status changes (because that's the point of the tick-status) - when glancing at a list, separating ticked items from unticked ones should be instantaneous With the current display, none of this is achieved. On top of that, on some systems, clicking the text of a checkmark does activate it (for example most online forms work like that). Plasma checkboxes (if that makes any sense) don't work like that everywhere... This is not a problem per se, but the UI does not make this behavior crystal-clear! Suggestion : if bringing back the checkmark is not an option, would it be possible, in the default theme, to change the "selected line" display to just a plain color (not the same color as the checkbox!), and not some color inversion? Or are there the same technical limitations? This was taken with kubuntu 15.10, default theme:
Last edited by tverron on Wed Nov 04, 2015 10:56 am, edited 1 time in total.
|
Registered Member
|
|
Registered Member
|
For cross-reference, on 2015-10-23, a new post to the same topic was opened without knowing the first one: viewtopic.php?f=285&t=128946
|
Moderator
|
This bug is so old now and apparently nobody has come up with a solution so here is a KISS one.
I have learned that form follows function. Good designer understands that visual design is a secondary thing. There are two symbols to consider as signs: a tickmark or a crossmark. Nothing else works it seems. So my proposal uses the cross since it's feels more minimalistic than anything I invented for a tick mark: (the 3rd row presents a "3rd state" symbol) Thanks. |
Moderator
|
Crossmark #2 proposal, reminding me a style used on paper forms. Uses thin line compatible with the current aesthetics and used by breeze too. Also the 3rd-state reworked to make it less similar to a checked radio button.
. |
Registered Member
|
Actually, last entry to bug 344348 (https://bugs.kde.org/show_bug.cgi?id=343428) dates from ... today (and the previous one from less than 2 weeks ago), and also has a proposal in there. |
Moderator
|
|
Registered Member
|
Will do asap yes. I'm still a bit worried though that the "checked" + "selected" mark looks too similar to "unchecked" "unelected" with color inversion. Will see.
Guess so, yes. Not sure about Andrew's oppinion about it, but I too think it should be made consistent. |
Registered Member
|
For the record,
I have implements Andrew's soluton for both checkboxes and radiobuttons and pushed the change, because I think it works really well. (kudos) For completeness, two more screenshots, to illustrate that even if the surrounding checkboxes are in the opposite check state as the selected one, it is still clear, IMO, what the selected checkbox state is: |
Moderator
|
Looks great, Hugo.
One only related question is, why the frame of the OFF box is gray and the frame of the ON box is blue. I thought both shall only differ in one thing: existence of the blue box inside. |
Registered Member
|
Wasn't that the design choice from day one ? It is also drawn this way in Andrew's screenshot. I'll let him comment further. |
Moderator
|
Yes it was. I noted the colours just now. One consequence is that the OFF and disabled-OFF check boxes (and radio buttons) look very similar.
|
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan