Bug 343428 - Checkbox on hover highlights are potentially confusing
Summary: Checkbox on hover highlights are potentially confusing
Status: RESOLVED FIXED
Alias: None
Product: Breeze
Classification: Plasma
Component: QStyle (show other bugs)
Version: 5.1.2
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Hugo Pereira Da Costa
URL:
Keywords:
: 349072 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-28 00:01 UTC by Juan Carlos Torres
Modified: 2016-06-27 12:00 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Breeze style checkboxes, normal and highlighted (32.25 KB, image/png)
2015-01-28 00:02 UTC, Juan Carlos Torres
Details
mockup of proposed solution (10.20 KB, image/png)
2015-11-07 06:46 UTC, Andrew Lake
Details
New theme with qt5 clock settings kcm module (32.51 KB, image/png)
2016-06-27 12:00 UTC, Jonathan Wakely
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Juan Carlos Torres 2015-01-28 00:01:38 UTC
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.
Comment 1 Juan Carlos Torres 2015-01-28 00:02:14 UTC
Created attachment 90727 [details]
Breeze style checkboxes, normal and highlighted
Comment 2 Hugo Pereira Da Costa 2015-02-02 22:55:43 UTC
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 ?
Comment 3 Eike Hein 2015-04-23 12:01:56 UTC
Ping Andrew? :)
Comment 4 Hugo Pereira Da Costa 2015-04-24 15:34:17 UTC
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 ???
Comment 5 Hugo Pereira Da Costa 2015-04-24 15:34:31 UTC
(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 ...
Comment 6 Hugo Pereira Da Costa 2015-04-24 15:42:01 UTC
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.
Comment 7 Hugo Pereira Da Costa 2015-04-24 15:42:51 UTC
... although honestly, I don't think the report itself is a real issue ... You get used to it IMHO
Comment 8 Andrew Lake 2015-04-24 22:21:18 UTC
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.
Comment 9 Eike Hein 2015-06-13 13:10:24 UTC
*** Bug 349072 has been marked as a duplicate of this bug. ***
Comment 10 Jonathan Wakely 2015-06-13 22:07:40 UTC
(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.
Comment 11 Jonathan Wakely 2015-06-13 22:12:57 UTC
(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.
Comment 12 Andrew Lake 2015-10-27 21:24:46 UTC
The proposed solution has not yet been implemented but the report is probably valid.
Comment 13 Hugo Pereira Da Costa 2015-10-29 10:00:53 UTC
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
Comment 14 Hugo Pereira Da Costa 2015-10-29 10:01:36 UTC
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.
Comment 15 Andrew Lake 2015-10-29 18:43:17 UTC
Sure Hugo, I'll work up a quick mockup shortly and post here.
Comment 16 Andrew Lake 2015-11-07 06:46:21 UTC
Created attachment 95366 [details]
mockup of proposed solution

Mockups as promised
Comment 17 Jonathan Wakely 2015-11-08 09:25:46 UTC
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?
Comment 18 Hugo Pereira Da Costa 2015-11-09 08:25:29 UTC
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
Comment 19 Hugo Pereira Da Costa 2015-11-09 08:26:54 UTC
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.
Comment 20 Hugo Pereira Da Costa 2015-11-09 08:29:27 UTC
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.
Comment 21 Jonathan Wakely 2015-11-09 09:01:58 UTC
Not sceptical, just keen to know that the problem cases as originally reported are OK now, and it looks good to me. Thanks!
Comment 22 Hugo Pereira Da Costa 2015-11-09 09:06:01 UTC
(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 :).
Comment 23 Jonathan Wakely 2016-06-27 12:00:34 UTC
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.