GNOME Bugzilla – Bug 746202
Provide a stronger focus indication for text entries, by desaturating selected but backdropped text
Last modified: 2018-03-31 13:10:06 UTC
Created attachment 299392 [details] [review] use insensitive color for unfocused selected items So to not confuse the user giving the false appeareance that the item is focused and can receive input, when it really cannot as it's unfocused, especially in text entries.
Created attachment 299394 [details] Adwaita light before patch Screenshot taken from gtk3-demo entry demo, it shows adwaita bug in current state, the text entry is not focused (Close button has focus) but the entry selected text color makes the user to think he can entry text (as if entry was focused) when it really cannot.
Created attachment 299395 [details] Adwaita light after patch This is after applying patch, now unfocused selected text uses backdrop_insensitive_color which is also adjusted for dark variant.
the color name doesn't sound right for this. it should be unfocused_selected_bg_color. If we don't have such a thing, chances are it is intentional that we don't differentiate...
Created attachment 299543 [details] [review] Adwaita: desaturate selected color for backdrop
Attachment 299543 [details] pushed as 6f478db - Adwaita: desaturate selected color for backdrop
(In reply to Jakub Steiner from comment #5) > Attachment 299543 [details] pushed as 6f478db - Adwaita: desaturate selected > color for backdrop I've just tried the patch, so thank you for fixing the backdrop case. I personally was more interested in fixing the unfocused case, as a means to fix https://bugzilla.gnome.org/show_bug.cgi?id=704352#c0 and so given that you think my fix was not the correct one.. can you suggest what the correct fix would be? do you think the filechooser should add custom css to desaturate the filename entry selected text when it's unfocused ?
Thanks for clearing up the use case.
Created attachment 299665 [details] [review] Adwaita,HC: distinguish selected and selected:focus - in some corner cases it is desirable to distinquish beteen a selected item and a selected focused item
Created attachment 299666 [details] screenshot of a distinct selected & selected focused items Need an ACK from Lapo on this one. While the backdrop case is clear, going fully desaturated on selected items and only blue on :selected:focus seems harsh.
(In reply to Jakub Steiner from comment #7) > Thanks for clearing up the use case. When I created this bug I set it as a blocker of bug 704352 but maybe you didn't notice, anyway I could have made it more clear too. (In reply to Jakub Steiner from comment #9) > Created attachment 299666 [details] > screenshot of a distinct selected & selected focused items > > Need an ACK from Lapo on this one. While the backdrop case is clear, going > fully desaturated on selected items and only blue on :selected:focus seems > harsh. My 2.5 cents (euro rate is going down): After seeing your screenshot, I'm not really sure the "desaturate when unfocused" is so important for widgets that are not text entries.. I mean it's cool because in your screenshot you can clearly see what part of the ui has the focus, but on the other hand I think the sidebar selected element being fully blue looked better, even when the focus is on file list. For text entries this is more a big deal as there is a greater wasted effort from the user when he tries to type to no avail. So in other words, if you|lapo|designers think your patch is too aggressive as it affects all widgets, we could just restrict it to text entries (which is what the original bug was about) and incorporate more widgets in the future as the need arises (in form of bugs filed).
The desaturation also applied on .suggested-action:active and .destructive-action:active (when clicking…), that looks a little weird.
And the GtkListBoxRows do not take the good color in backdrop state (they’re remaining white on black).
Jakub, leaving colors alone (do not desaturate as we used to do) is a design choice, to make backdrop windows more usefull (think about side to side windows and stuff like that), so this is NOTABUG to me.
Also I think this is inconsistent, focus on entries is indicated with the focus glow, that's a selection, that is a selection, I don't get the problem at all.
reverted commit 6f478db2facd8744714b7ab374d2687d777653a3
Maybe it's our way to indicate the entry has focus which is a bit weak and the focused text is more prominent than that. I'd really like to have subtler text selections w/o the color invertion similarly to what osx does, but that would need a border which is not possible currently with gtk, anyway we could do something like the following to visually strengthen the focus indication: [for the inspector] .entry:focus { box-shadow: inset 0 3px rgba(0, 0, 0, 0.02), inset 0 2px rgba(0, 0, 0, 0.03), inset 0 1px rgba(0, 0, 0, 0.08), inset 0 0 0 1px #4a90d9, 0 1px white; }
Looks good to me. Jakub says 'do whatever Lapo says'. So, go for it
Fix push'd to master
Matthias, Do you want this in 3.16 branch as well?
It doesn't look like this was ever actually completed, and the original issue - the lack of differentiation between selected text in focussed vs unfocussed text widgets - is still extant and causing a lot of frustration and noise, e.g. in Bug 770941. I think we should revisit this, especially given comments like > I'd really like to have subtler text selections > w/o the color invertion similarly to what osx does, > but that would need a border which is not possible currently with gtk (A) Subtler text selections would remove a lot of annoyance for users in GTK+ 3 (B) GTK+ 4 could maybe redo this in a way you'd prefer more
The preferred solution is to deselect the text on focus-out, so closing: https://bugzilla.gnome.org/show_bug.cgi?id=770941#c30 I guess I also misunderstood > I'd really like to have subtler text selections which probably referred to focussed selections.