Bug 454842 - Window highlight effect is now rather faint and easy to miss
Summary: Window highlight effect is now rather faint and easy to miss
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-present-windows (show other bugs)
Version: 5.24.90
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Nate Graham
URL:
Keywords: regression, usability
Depends on:
Blocks:
 
Reported: 2022-06-04 15:56 UTC by Ilya Bizyaev
Modified: 2022-07-17 20:02 UTC (History)
7 users (show)

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


Attachments
original size of the highlight (245.08 KB, image/png)
2022-06-15 23:02 UTC, Christian (Fuchs)
Details
suggested bigger highlight (201.73 KB, image/png)
2022-06-15 23:02 UTC, Christian (Fuchs)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ilya Bizyaev 2022-06-04 15:56:05 UTC
1) Hard to tell which window is selected with the keyboard
Before Plasma 5.25, hovered or keyboard-selected windows in the Present Windows effect would become bigger (with animation), so it was easy to see where the focus is and where it transitions. Now the focused window is signalled with a narrow semi-transparent highlight, and it takes me much more time to figure out which window is focused.

2) Switching focus away from the search bar with the down arrow key is broken
When the effect is triggered with a shortcut (Ctrl-F9 here), it's the search bar that is highlighted, and pressing the down arrow to choose the first window makes the highlight just vanish. Further arrow presses suggest it is probably the first window that is sort of focused, but there is no highlight to tell that, and pressing Enter does not actually select it.

3) Selecting the search bar with the keyboard is only possible once
If I trigger the effect with my mouse, the search bar is not selected, and I can press Ctrl-F or the up arrow once to select it. But once I navigate away from it, I can no longer return to it without the mouse.
If I trigger the effect with my keyboard, the search bar is focused from the start, and if I navigate away from it, there's no way back without the mouse.

4) Using the mouse and then the keyboard results in double focus
If I use the "hot corner" to trigger the effect and leave the mouse hovering a window, then start using the arrow keys, I get 2 focus highlights which look identical. It is then hard to guess which of the two windows will get selected if I press Enter.


SOFTWARE/OS VERSIONS
Operating System: openSUSE Leap 15.3
KDE Plasma Version: 5.24.90
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.2
Graphics Platform: X11
Graphics Processor: Mesa DRI Intel® UHD Graphics

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2022-06-06 19:57:31 UTC
> 1) Hard to tell which window is selected with the keyboard
Agree. The highlight effect could be more obvious. Let's use this bug report to track the issue.

> 2) Switching focus away from the search bar with the down arrow key is broken
IIRC this is an X11-specific problem; it works fine for me on Wayland. Let's get a separate bug report for this.

> 3) Selecting the search bar with the keyboard is only possible once
Ctrl+F works for me on Wayland, but I can reproduce that the up arrow key won't focus it. Let's get a separate bug report for this.

> 4) Using the mouse and then the keyboard results in double focus
Can reproduce. Let's get a separate bug report for this.
Comment 3 Christian (Fuchs) 2022-06-15 23:02:02 UTC
I assume that's the bug that Nate meant in the VDG group, thus suggesting that here: 

--- WindowHeap.qml      2022-06-16 00:33:35.627845270 +0200
+++ WindowHeapOrig.qml  2022-06-16 00:34:06.419713139 +0200

                PlasmaCore.FrameSvgItem {
                    anchors.fill: parent
-                   anchors.margins: -PlasmaCore.Units.smallSpacing
+                  anchors.margins: -PlasmaCore.Units.largeSpacing * 2  

would lead to the attachment I'll upload in a sec which would be a lot easier to notice, it would also surround the window label. 
If people prefer a smaller one that doesn't surround the label, mediumSpacing would probably do
Comment 4 Christian (Fuchs) 2022-06-15 23:02:26 UTC
Created attachment 149765 [details]
original size of the highlight
Comment 5 Christian (Fuchs) 2022-06-15 23:02:48 UTC
Created attachment 149766 [details]
suggested bigger highlight
Comment 6 Niklas Stephanblome 2022-06-22 15:24:57 UTC
It doesn't have to be THAT huge as in your 2nd attachement but I do agree that it could be bigger.
Comment 7 Niklas Stephanblome 2022-06-22 15:26:37 UTC
Bugs 2 and 3 of this bug report (the issue with the keyboard) has now been fixed with this merge request (which will be merged in a few hours hopefully): https://invent.kde.org/plasma/kwin/-/merge_requests/2562
Comment 8 Christian (Fuchs) 2022-06-22 15:36:57 UTC
(In reply to Niklas Stephanblome from comment #6)
> It doesn't have to be THAT huge as in your 2nd attachement but I do agree
> that it could be bigger.

The problem on an in-between is that it will most likely go right through the window title label. 
If we change it, I guess it either has to just not, or also include the window label (which imho is correct, since that label is part of what the user selected. If you e.g. select a file in a file manager, the file name is also part of the selection highlight). 

But maybe that whole label could be a bit repositioned.
Comment 9 Niklas Stephanblome 2022-06-22 15:40:02 UTC
> The problem on an in-between is that it will most likely go right through
> the window title label. 
> If we change it, I guess it either has to just not, or also include the
> window label 
Or we could leave the highlighting box as it is and instead make all unselected windows darker. Then it would be very noticable but still look good. What do you think?
Comment 10 Christian (Fuchs) 2022-06-22 15:43:56 UTC
(In reply to Niklas Stephanblome from comment #9)
> > The problem on an in-between is that it will most likely go right through
> > the window title label. 
> > If we change it, I guess it either has to just not, or also include the
> > window label 
> Or we could leave the highlighting box as it is and instead make all
> unselected windows darker. Then it would be very noticable but still look
> good. What do you think?

Hm, sorry but imho that would be the worse solution for mainly two reasons: 

1) it would not be consistent, the highlight is sort of the same that we use in lists and it looks similar enough to non-QML qt app selections
2) The darker windows part was discussed in a different bug report about the desktop grid, where in the past the non-active ones were darker. People argumented, imo correctly so, that in an overview you should be able to easily "read" all elements, and making some elements darker works a bit against that. 

Note that my above patch is a quick and dirty solution, it could probably be fine-tuned, it could be done in a way so that there is still a margin between windows  (which is what currently makes it look bad) and maybe the label could be re-thought and -positioned, then I think a bigger selection box would solve the problem and look nice.
Comment 11 Maximilian Böhm 2022-06-22 16:18:40 UTC
Instead of this faint blue margin, I suggest a darker one. I’m against the bigger highlight box. Present Windows/Exposé has this appeal of a floating window overview. If you draw this big boxes, it will look less natural, more constrained and more like the Alt + Tab "Grid" effect option. Please don’t go this way.
macOS 10.7 had this darker blue highlight in Mission Control: https://youtu.be/lTU7i_DtrdQ?t=282
Whis is still present today: https://youtu.be/uBYP5IdfoCo?t=89
I think, that’s the best way. Just paint the highlight darker.
Comment 12 Maximilian Böhm 2022-06-24 01:58:09 UTC
Another possible alternative could be to just zoom in the window your mouse is over a bit like the old Present Windows effect has done. But without the darkening of the unfocused windows like before. This newer was especially pleasing in the old effect. But the slight zoom in combined with the faint blue could be enough.
See here for this subtle zoom up of the window in the old Present Windows implementation: https://youtu.be/ysGu5fU6oFg?t=4

With a closer inspection of the current implementation, I see the highlight box does not only draw the outline but also does dye the window with this light blue highlight color. A darker tone thus would make the window darker and that’s not ideal when you are working with pictures/videos.
I’m not that positive for this dyeing in general and would favorite a darker tone highlight outline without dyeing the actual window + a subtle zoom in like the old implementation did pretty well with its organic and playful touch.
Comment 13 Bug Janitor Service 2022-07-15 01:42:46 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2659
Comment 14 Nate Graham 2022-07-17 03:08:15 UTC
Git commit a0c8d4b24d816331f4865f167d09880620a61a19 by Nate Graham.
Committed on 17/07/2022 at 02:55.
Pushed by ngraham into branch 'master'.

WindowHeap: expand size of highlight

Currently, the highlight effect is not very visible because it only
barely peeks out of the window thumbnail. We can make it bigger by
making it peek out a little bit more, and also by including the window
title and icon (when visible) within it.

M  +1    -1    src/effects/private/qml/WindowHeap.qml
M  +7    -2    src/effects/private/qml/WindowHeapDelegate.qml

https://invent.kde.org/plasma/kwin/commit/a0c8d4b24d816331f4865f167d09880620a61a19