Breeze seems to apply a sort of "opposite colors" when highlighting menu items, but in the context of checkboxes, it would forces users to pause and try to figure out how the color scheme works. For example, an unchecked box is hollow/empty normally but when highlighted, it becomes filled, giving the impression that it's checked. Vice-versa for checked boxes. (Screenshot attached) Reproducible: Always Steps to Reproduce: 1. Open any menu with checkbox items 2. Highlight that menu item Actual Results: Unchecked boxes look checked, checked boxes look unchecked. Expected Results: Checkboxes should remain consistent so that users can tell just at a glance whether a box is unchecked or not, regardless if it's highlighted.
Created attachment 90727 [details] Breeze style checkboxes, normal and highlighted
agreed with the issue, and its a design flaw ... Because checked checkboxes are 'blue', that is, highlighted, the same color as the selection box, you need to 'invert' them when inside a selected item (be it list, or menu), otherwise you get blue on blue ... Then you also need to invert the unchecked ones, and you get the confusion you mention (which I share) ... Haven't found a better solution so far ... Andrew ?
Ping Andrew? :)
I guess one solution would be to render the "normal" (that is: unselected) checked checkboxes with the foreground color (same as text and same as unchecked) rather than the selection blue. Pros: the selection "color inversion" would feel more natural and less confusing Cons: checked checkboxes would all be less differenciable than unchecked. I'll post a screenshot soon ???
(In reply to Hugo Pereira Da Costa from comment #4) > I guess one solution would be to render the "normal" (that is: unselected) > checked checkboxes with the foreground color (same as text and same as > unchecked) rather than the selection blue. > > Pros: the selection "color inversion" would feel more natural and less > confusing > Cons: checked checkboxes would all be less differenciable than unchecked. > I'll post a screenshot soon ...
http://wstaw.org/m/2015/04/24/plasma-desktopZ13755.png http://wstaw.org/m/2015/04/24/plasma-desktopI13755.png (on the second screenshot, I think here it is obvious that the selected is unchecked) Oppinions welcome.
... although honestly, I don't think the report itself is a real issue ... You get used to it IMHO
Sorry I took so long to respond. Hugo's suggestion does solve the problem, but I think we need to keep the checkboxes using the highlight color instead of the foreground (text) color; consider it a hard design constraint. :-) How about if we keep the interior of the checkbox sacred, regardless of the menu item selection color? So, keep the interior of the checkbox background set to the background color and the "checkmark" rendered in the highlight color, regardless of whether the menu item is selected or not.
*** Bug 349072 has been marked as a duplicate of this bug. ***
(In reply to Hugo Pereira Da Costa from comment #4) > I guess one solution would be to render the "normal" (that is: unselected) > checked checkboxes with the foreground color (same as text and same as > unchecked) rather than the selection blue. How about just making the checkbox actually have some kind of check/tick in it, rather than just a solid block of colour? (In reply to Hugo Pereira Da Costa from comment #7) > ... although honestly, I don't think the report itself is a real issue ... > You get used to it IMHO No, it is *definitely* a real issue, if a checkbox widget does not *instantly* tell you its state, with just a quick glance, then it is broken. Period. You should not have to get used to it.
(In reply to Andrew Lake from comment #8) > How about if we keep the interior of the checkbox sacred, regardless of the > menu item selection color? So, keep the interior of the checkbox background > set to the background color and the "checkmark" rendered in the highlight > color, regardless of whether the menu item is selected or not. Call me old fashioned, but how about actually putting some kind of obvious mark there? A solid block of colour is always going to have this problem. Is it a filled-in box or an empty box? ... if it just looks like a square then it's irrelevant whether it's a blue square or a white square. If you don't want a check/tick to spoil the theme, how about some kind of cross, which could be oriented as + or x, it doesn't matter, it would still change an empty square into a square with an obvious marker in it.
The proposed solution has not yet been implemented but the report is probably valid.
Hi Andrew, Attempt I have tried have failed so far. I guess I am not sure I understand fully what you suggest. Could you use your QML and/or gimp and/or Inskape foo and post screenshots of the solutions you'd suggest (menu-selected checked and uncheched boxes) ? Would help making sure we are on the same page. Thanks in advance, Hugo
PS: for what its worth, I too would really like to keep the current checkbox design, (with the issue here fixed) and not move back to traditional check-marks.
Sure Hugo, I'll work up a quick mockup shortly and post here.
Created attachment 95366 [details] mockup of proposed solution Mockups as promised
Comment on attachment 95366 [details] mockup of proposed solution Could you show what the proposed solution looks like when the highlighted item is selected and the adjacent items are not, and vice versa?
Git commit e59bb5fa129b5daa613c1349ab14c37ec6302157 by Hugo Pereira Da Costa. Committed on 09/11/2015 at 08:25. Pushed by hpereiradacosta into branch 'master'. Render unaltered background behind selected checkboxes (in menus and lists) rather than changing color to Highlight M +39 -0 kstyle/breezehelper.cpp M +6 -0 kstyle/breezehelper.h M +23 -30 kstyle/breezestyle.cpp http://commits.kde.org/breeze/e59bb5fa129b5daa613c1349ab14c37ec6302157
Hi Andrew, I've implemented and played with your mockups, and I must say that's a very neat solution. I've implemented the same for radio buttons too of course. IMHO it works very well, so closing.
Some more screenshots for the skeptical: http://wstaw.org/m/2015/11/09/plasma-desktopa11130.png http://wstaw.org/m/2015/11/09/plasma-desktopT11130.png I believe that even though the surrounding checkboxes in both cases are in the opposite check state, it is still clear what the selected checkbox state is.
Not sceptical, just keen to know that the problem cases as originally reported are OK now, and it looks good to me. Thanks!
(In reply to Jonathan Wakely from comment #21) > Not sceptical, just keen to know that the problem cases as originally > reported are OK now, and it looks good to me. Thanks! No worry, the part on "skeptical" was meant to be a pun, not an insult nor a rant. The question was totally legit :).
Created attachment 99721 [details] New theme with qt5 clock settings kcm module The new version still has problems, see the attached screenshots of the qt5-based Digital Clock Settings dialog. The top one has the selected row checked, the bottom has it unchecked (or is it the other way around?) but when you don't have the two side-by-side to compare it's hard to tell if it's checked.