Bug 410594 - Reverse switching uses "recently used" when "stacking order" is chosen
Summary: Reverse switching uses "recently used" when "stacking order" is chosen
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (show other bugs)
Version: 5.16.4
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Vlad Zahorodnii
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-08-04 23:09 UTC by JKS
Modified: 2023-06-26 13:12 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JKS 2019-08-04 23:09:14 UTC
SUMMARY
[Reverse switching]'s behavior on "stacking order" is "recently used".

STEPS TO REPRODUCE
1. Choose "stacking order" in 
"Task Switcher/Main/Content/Sort order".

2. Have at least three windows open. Say windows A, B and C, 
(they were created in that order) with window A focused.

3. Press Alt + Shift + Tab, relase, press Alt + Shift + Tab 
again

OBSERVED RESULT
Focus changes like A --> C --> A, i.e., it behaves like the "recently used" option chosen.

EXPECTED RESULT
It should be A --> C --> B

SOFTWARE/OS VERSIONS
GNU+Linux
KDE Plasma Version: 5.16.4
KDE Frameworks Version: 5.60.0
Qt Version: 5.13.0

ADDITIONAL INFORMATION
Similarly, the behavior of [reverse switching] on "Recently used" option is "Stacking order".
Comment 1 Rickard Westman 2019-08-24 23:43:18 UTC
Bug also applies to the actions "Walk Through Windows of Current Application (Reverse)", "Walk Through Windows of Current Application Alternative (Reverse)", and "Walk Through Windows Alternative (Reverse)".

Also note that the options "recently used" and "stacking order" are not simply swapped around - when "stacking order" is used (erroneously due to this bug) it's  not reversed with respect to the normal/forward cycling order, but the same.
Comment 2 Rickard Westman 2019-08-25 00:40:30 UTC
Just noticed that this bug was originally filed for a newer version of KDE than the one I'm running, so I'm not sure whether my added comment #1 really applies.  I'm running these versions:

Linux/KDE Plasma: Kubuntu 18.04
KDE Plasma Version: 5.12.8
KDE Frameworks Version: 5.44.0
Qt Version: 5.9.5
Comment 3 zyf0330 2020-05-18 08:08:32 UTC
I am not sure if this bug affects feature 'recently used'.
I set sort order as 'recently used', but alt+tab doesn't honor it.
Comment 4 kelpdip 2021-04-25 18:47:28 UTC
I believe this is partially a byproduct of ingrained UI expectations BUT there is still a bug in sequential order switching.

Sort order = Recently used:
'Default' Alt-tab (forward switch) uses 'recently used' order when set to 'Recently used' sort order in settings UI.
'Default' Alt-shift-tab (reverse switch) uses reverse stacking order when set to 'Recently used' sort order in UI. 

While confusing at face value, this is a byproduct of simple UI expectations, and possibly not a bug. 'Recently used' and 'Stacking order' are possibly expected to be simply inverted. The power-user workaround would then be to have both sort rules simultaneously active in 'Main' and 'Alternative', and to split the keybindings across these tabs.

However, this approach fails!
1. The reverse sequential order in 'Stacking order' is not actually sequential at all.
2. The reverse sequential order in 'Recently used' is a real reverse sequential order.
3. The forward sequential order in 'Stacking order' is a completely different sequential order from #2.

The end result is lack of keybinding support for basic forward/backward window walking, which is a powerful thing to bind to a rotary input device.
Comment 5 kelpdip 2021-08-23 23:51:14 UTC
To update, bug still exists on:
Operating System: Debian GNU/Linux 11
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Comment 6 Rickard Westman 2023-06-26 13:12:39 UTC
Seems fixed as of this version:

Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3

With this version, the reproduction steps in the original report no longer triggers the bug, and the seemingly related problem in comment #1 doesn't occur either.  I haven't changed the status of the bug since I'm not a KDE developer, but perhaps it should be.