[focus indication]: appears in tabs, lists, checkboxes without any keyboard interaction, should not be visible default without keyboard interaction

[star-buck]

[star-buck]

here is the setting shown to be off, still any focus indicator is visible (it was working, so no focus indicator at all was visible some Netrunner version before):

[eikehein]

In case it helps Marco: I can't reproduce this on my system (KDE git, Qt 5.9 branch).

[eikehein]

To clarify, on my system, the option correctly disables the focus indicator in lists as the option text indicates. It doesn't disable the focus indicator under e.g. checkbox labels, that's also not what the option promises.

The focus indicator is required to know which control currently has focus e.g. when using keyboard navigation. In lists it can be redundant with the selection marker (that's why there is an option), but also lists exists where focus and selection are separately managed (e.g. when multiple selection is allowed).

[notmart]

so, the option for lists should disable focus indicators everywhere, or a new option should be introduced instead?

[eikehein]

It would have to be a new option. As mentioned disabling focus indicators everywhere breaks keyboard navigation support. Changing the behavior would break systems where this option is enabled.

[star-buck]

A) It worked like that before, disabling it everywhere. B) if now it doesnt i request an option again so it does C) even gnome has no more indicators, so its a valid usecase and request.

[star-buck]

D) i recall for checkboxes to have the colorindicator to show which option is highlighted, so this would be redundant if still working.

[eikehein]

There are different ways to communicate "this control is focused right now". Colorizing controls is an option. Breeze currently choses this underlining design. I don't know if this changed at any point or not, but it's the current situation. I also don't know if this option ever disabled focus indicators everywhere (if it did, with the same option text, it would have been a pretty big bug). Making it do that now would in any case break keyboard nav on existing systems as mentioned, unless redesigning focus indication to work via different visual means such as colorization.

So there's two options:

a) Redesign focus indication in Breeze not to use an underlline.

b) Add a "Break my UI please" option that disables focus indication entirely.

And another matrix of upstream vs. Netrunner-specific for a and b.

Thoughts on which is preferrable?

[eikehein]

Because "even gnome has no more indicators, so its a valid usecase and request" struck me as unlikely, here's a screenshot of a dialog using the default GTK+ 3 theme:

As you can see at the "Poll Disk I/O" checkbox it does have a focus indicator. IMHO it's a lot uglier than Breeze's in the way it overlaps the checkbox.

It's true that the focus indicators don't work in the Breeze GTK+ port. This is a bug in Breeze GTK+ that needs to be fixed.

[eikehein]

Here's the focus indicator design in the very latest version of vanilla Gnome 3, from Fedora 26 Alpha, in a dialog from Gnome system settings:

(Last checkbox.)

I find Breeze's underline design more modern and less Win95 than GTK+'s marching ants personally.

[eikehein]

Focus indicator in single selection list:

[eikehein]

Further discussion:

[21:37] ‎<‎Sho_‎>‎ can you give me an example of one of our uis where the focus indicator line shows up for tabs?
‎[21:37] ‎<‎Sho_‎>‎ i can't find one quickly so i'm curious about when it happens
‎[21:38] ‎<‎Sho_‎>‎ shpws up on click i mean
‎[21:38] ‎<‎Sho_‎>‎ so for example in the
‎[21:38] ‎<‎Sho_‎>‎ "Configure Breeze" dialog
‎[21:38] ‎<‎Sho_‎>‎ the behavior i see is this
‎[21:38] ‎<‎Sho_‎>‎ 1. normally clicking tabs doesn't show a focus indicator
‎[21:39] ‎<‎Sho_‎>‎ 2. when you use the tab key to the tab bar, it shows a focus indicator
‎[21:39] ‎<‎starbuck1‎>‎ system settings
‎[21:39] ‎<‎starbuck1‎>‎ window deco
‎[21:39] ‎<‎Sho_‎>‎ 3. then when you switch tabs by click, it keeps showing the indicator
‎[21:39] ‎<‎starbuck1‎>‎ breeze
‎[21:39] ‎<‎starbuck1‎>‎ click on that weird placed options button
‎[21:39] ‎<‎Sho_‎>‎ 4. when you click a different control (e.g. checkbox) the focus indicator obviously goes sway from the tab bar
‎[21:39] ‎<‎Sho_‎>‎ 5. then when you click a tab again, no indicator
‎[21:39] ‎<‎starbuck1‎>‎ can shoot you a video it is selected with focus line default
‎[21:39] ‎<‎Sho_‎>‎ so the tab bar is "smart" and shows the indicator only if it was focused by keyboard
‎[21:39] ‎<‎Sho_‎>‎ now
‎[21:39] ‎<‎starbuck1‎>‎ there are more places
‎[21:39] ‎<‎Sho_‎>‎ if we make the other controls also "smart"
‎[21:40] ‎<‎Sho_‎>‎ so they never show the indicator unless focused by keyboard
‎[21:40] ‎<‎Sho_‎>‎ then that might help
‎[21:40] ‎<‎starbuck1‎>‎ in my example, they do
‎[21:40] ‎<‎starbuck1‎>‎ so much for theaory
‎[21:40] ‎<‎Sho_‎>‎ I can't say without research if Qt allows this easily, but it's an idea
‎[21:40] ‎<‎notmart‎>‎ here in tabs (also window deco kcm) i can make tabs have a focus indicator only when i explicitly focused them with the tab key
‎[21:40] ‎<‎Sho_‎>‎ looking for your example
‎[21:40] ‎<‎starbuck1‎>‎ by that logic, it would help if when clicking something, the indicator would also not show up
‎[21:40] ‎<‎notmart‎>‎ not with click
‎[21:41] ‎<‎starbuck1‎>‎ in any place
‎[21:41] ‎<‎starbuck1‎>‎ thats what i meant
‎[21:41] ‎<‎Sho_‎>‎ interesting
‎[21:41] ‎<‎Sho_‎>‎ yeah
‎[21:41] ‎<‎notmart‎>‎ which, is arguably what should do in general
‎[21:41] ‎<‎starbuck1‎>‎ and thats how it was done previously
‎[21:41] ‎<‎Sho_‎>‎ there the indicator is shown first, and doesn't disappear until you move a way
‎[21:41] ‎<‎Sho_‎>‎ my guess is
‎[21:41] ‎<‎Sho_‎>‎ the difference is that i nthat dialog the tab bar has default focus
‎[21:41] ‎<‎Sho_‎>‎ and in the other dialog it doesn't
‎[21:41] ‎<‎starbuck1‎>‎ im glad its broken in breeze gtk
‎[21:42] ‎<‎starbuck1‎>‎ as it gives a really calm feeling not drawing attaention anywhere
‎[21:42] ‎<‎starbuck1‎>‎ especially when indicator got activated once in a optins list, it even shows up on the option on the next tab
‎[21:42] ‎<‎starbuck1‎>‎ not the tab itself, but the next option
‎[21:42] ‎<‎starbuck1‎>‎ ieven if clicked on the next tab by mouse
‎[21:42] ‎<‎starbuck1‎>‎ it doesnt "vanish"
‎[21:43] ‎<‎Sho_‎>‎ it shows on whatever has focus, yeah, so it depends on what in that UI grabs focus
‎[21:43] ‎<‎Sho_‎>‎ i think what we could do is
‎[21:43] ‎<‎Sho_‎>‎ in the central eventfilter in breeze, filter focusin events and check their focusreason
‎[21:43] ‎<‎Sho_‎>‎ and only show the indicator when the focusreason is keyboard, ever
‎[21:43] ‎<‎notmart‎>‎ yeah
‎[21:44] ‎<‎notmart‎>‎ that would be for tabs, checkboxes and radiobuttons i guess
‎[21:44] ‎<‎starbuck1‎>‎ this is how it was then previously, not sure what broke it
‎[21:44] ‎<‎notmart‎>‎ that would be pretty much the behavior of gtk3
‎[21:44] ‎<‎Sho_‎>‎ unlike most toolkits Qt has http://doc.qt.io/qt-5/qt.html#FocusReason-enum and can distinguish
‎[21:44] ‎<‎starbuck1‎>‎ right
‎[21:44] ‎<‎notmart‎>‎ at least the adwaita theme
‎[21:44] ‎<‎Sho_‎>‎ i actually use that in yakuake where the focus indication for terminal splits is done differently for mouse and keyboard
‎[21:45] ‎<‎Sho_‎>‎ (because with mouse you know where you clicked)
‎[21:45] ‎<‎Sho_‎>‎ ok, so let me paste this exchange into the github ticket and then we know what needs investigating in terms of code changes

[notmart]

review that disables focus on mouse click on most elements https://phabricator.kde.org/D5429
like gtk, focus decoration would still be there when the widget is selected by keyboard navigation

[star-buck]

@notmart : any update on this?
i started testing kde neon with 5.10 beta, and the underline basically appears now everywhere when clicked or sometimes even default.

[star-buck]

kde neon 5.10 beta:
installer has items now underlined default without any keyboard or mouse interaction, which draws attention in the case below (but also likely default others) to the first available option.
This is not only distracting (since i do not need a visual clue where the keyboard focus is if i only used the mouse at this point), but also mislaeding as if to require attention as if needed an action here and also gives the impression of a preffered option that is underllined to anyone not familiar of WHY this should be underlined as to only indicate keyboard navigation focus.

[notmart]

The maintainer didn't accept the patch, so the patch will need to be applied in netrunner, @shadeslayer told me it should be easy for how the infrastructure is now

[shadeslayer]

Is there a possibility of getting it upstreamed at some point? Having to patch every future release feels like a huge burden.

[star-buck]

@notmart : please add the breeze patch here:
https://github.com/ds9-extras/breeze-patches

@notmart : is this the link to the breeze git repo the patches have to be applied against?:
https://cgit.kde.org/breeze.git/

[star-buck]

moved ticket to netrunner-relevant tickets:
https://github.com/blue-systems/netrunner-ideas/issues/84

[notmart]

@star-buck yes, is https://cgit.kde.org/breeze.git/
I don't seem to have permissions to push on https://github.com/ds9-extras/breeze-patches should i do a pull request instead?

[star-buck]

uups, you should have now (added your user to the repo there)