Bug 427840 - Minimizing a window doesn't move it to the bottom of the Task Switcher (alt+tab) list anymore
Summary: Minimizing a window doesn't move it to the bottom of the Task Switcher (alt+t...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (show other bugs)
Version: 5.20.0
Platform: Mageia RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Nate Graham
URL:
Keywords: regression, usability
: 432548 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-10-16 21:39 UTC by JanKusanagi
Modified: 2022-06-18 12:45 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.21


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JanKusanagi 2020-10-16 21:39:11 UTC
SUMMARY

For the longest time, before Plasma 5.20, minimizing a window moved it to the bottom of the alt+tab list, which in my workflow meant "I don't want to access this window anytime soon". Now, that's no longer possible and requires some muscle-memory re-training, which makes me go back to the "pseudo-discarded" window all the time.

https://xkcd.com/1172/

I'm sure the new behavior makes sense to a lot of people, but this was well-established behavior, that some of us count on :'(

Thanks for listening.


STEPS TO REPRODUCE
1. Set your task switcher's "sort order" to "recently used" (I believe this is the default)
2. Open at least 3 windows.
3. Minimize one of them.
4. Press/hold Alt+Tab to see the task switcher.


OBSERVED RESULT
The window you just minimized is the next option in the list. If you press alt+tab and release quickly, you'll just end up going back to the minimized window.

EXPECTED RESULT
The minimized window should (optionally, if you wish) go to the bottom of the list. 



SOFTWARE/OS VERSIONS

GNU/Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.20.0
KDE Frameworks Version: 5.75
Qt Version: 5.15.1

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2020-10-16 22:49:28 UTC
This was an intentional change and I still think it's a better default than the old way. But I have heard multiple complaints, not just yours. And listening to user feedback is important to me.

So I'll make you a deal: I'll re-add it as an off-by-default option in the Task Switcher KCM if we can remove the "Alternative" task switcher style in exchange. :)
Comment 2 David Edmundson 2020-10-16 23:06:10 UTC
>So I'll make you a deal: I'll re-add it as an off-by-default option in the Task Switcher KCM if we can remove the "Alternative" task switcher style in exchange. :)

I don't follow the logic.
Comment 3 Nate Graham 2020-10-16 23:39:53 UTC
The logic essentially is that there's a certain "options budget" in any UI. If you go "over budget", your UI becomes confusing and overwhelming. We can avoid spending into our budget (whatever it is) if we replace options on a one for one basis: remove one, and add another.

In this case, I haven't ever found anyone to understand the option for an alternative task switcher, so I don't think that removing it to make room for another option would be a big problem.

Does that make any sense?
Comment 4 JanKusanagi 2020-10-16 23:43:21 UTC
(In reply to Nate Graham from comment #3)
> In this case, I haven't ever found anyone to understand the option for an
> alternative task switcher, so I don't think that removing it to make room
> for another option would be a big problem.

Not to stop anyone from freeing "budget" for the option I want, but I don't see what's so weird about the alternative switcher. AFAICT, it's there so you can have, say, alt+tab for a classic list switcher, and say, meta+tab for a flip cover switcher, so you can use one or the other depending on what you need in the moment.

I _personally_ don't have a use for that, but XKCD 1172 =)
Comment 5 JanKusanagi 2020-10-19 16:05:44 UTC
In the meantime, could we maybe have a config file option, without a GUI counterpart?

Just so some of us don't go insane =)
Comment 6 Nate Graham 2020-10-20 20:22:31 UTC
Sure, I'll submit one and we'll see where it goes. No promises, sorry. :)

https://invent.kde.org/plasma/kwin/-/merge_requests/370
Comment 7 JanKusanagi 2020-10-20 22:30:23 UTC
Thanks, appreciated =)
Comment 8 Nate Graham 2020-10-21 00:18:55 UTC
Well don't thank me yet; it hasn't been merged and I can't guarantee that it will be. But I guess you can carry it as a local patch if you build stuff from source. :)
Comment 9 JanKusanagi 2020-10-21 22:19:29 UTC
Well, I thank you for trying and for the good intentions =)

After several days with this, I can now really say it's maddening at times. I saw in the MR for the original change how someone had exactly the same issue that I have, understanding the effect of "minimization moves to the bottom" just like I do.
Comment 10 Nate Graham 2020-10-22 01:37:12 UTC
Speak up in https://invent.kde.org/plasma/kwin/-/merge_requests/370. :)
Comment 11 Nate Graham 2020-11-04 16:17:00 UTC
Git commit b3e9c819537cf292d9b1c4d19c5ce7adde00158e by Nate Graham.
Committed on 04/11/2020 at 16:16.
Pushed by ngraham into branch 'master'.

[focuschain/task switcher] Add hidden option to govern repositioning minimized windows

Since some people apparently liked the old behavior of moving minimized
windows to the end of the focus chain, let's let them have it if they
set a hidden config option:

`MoveMinimizedWindowsToEndOfTabBoxFocusChain=true` in the `[TabBox]` group
of the kwinrc file.

We can add a UI for it later if needed.
FIXED-IN: 5.21

M  +5    -1    abstract_client.cpp
M  +10   -6    focuschain.cpp
M  +3    -0    kwin.kcfg
M  +11   -0    options.cpp
M  +6    -0    options.h

https://invent.kde.org/plasma/kwin/commit/b3e9c819537cf292d9b1c4d19c5ce7adde00158e
Comment 12 JanKusanagi 2020-11-08 01:01:36 UTC
Was this backported to 5.20.3? *_*
Comment 13 Nate Graham 2020-11-08 02:52:33 UTC
5.21 only I'm afraid. You can built your own KWin from source to either manually backport it, or use the 5.21 version. See https://community.kde.org/Get_Involved/development.
Comment 14 JanKusanagi 2020-11-09 14:59:15 UTC
Thankfully the Mageia packagers were able to accommodate me and backported it.
It helps that some of them were also annoyed by the new behavior (let's not forget, changed suddenly after years and years of working a certain way... XKCD 1172!! xD)

I'm using it now and it works fine  =)
Thanks!
Comment 15 Nate Graham 2020-11-09 16:18:43 UTC
Glad you've managed to get relief. :)
Comment 16 Matthias Heinz 2021-01-21 21:44:18 UTC
Hi,

I recently updated to Plasma 5.20.5 and at first I thought I was going insane and then I gladly found this bug report.

Why has it changed? There was no necessity to do this and it doesn't make any sense at all. If a user minimizes a window there is a reason for it: To get it away and have it running in the background and not care about it for some time.

As a very very long term developer who does ui stuff: You don't change behavior like this. Never. You make a new option if you think the other behavior is better, but never make it a default until you have verified it is really better (which is it not).

I hope you consider this answer as not too rude, but this is annoying me for some days now.

And I have the feeling that when Plasma 5.20 starts trickeling down into all the distributions that don't ship every release this bugreport might blow up a bit.
Comment 17 Nate Graham 2021-01-21 22:11:26 UTC
See https://bugs.kde.org/show_bug.cgi?id=427840#c11for a way to go back to the old behavior.
Comment 18 Ricardo J. Barberis 2021-01-29 15:38:42 UTC
I just want to let you guys know that this behaviour change affects me too, it's very annoying.

As a workaround, instead of minimizing windows now I move them to another virtual desktop :)


I already set MoveMinimizedWindowsToEndOfTabBoxFocusChain in my kwinrc file but I have to agree with Matthias Heinz that these kind of changes should never be the default. 

I understand also that not making a new setting the default can/will hamper its discoverability but maybe something could be implemented like in Android apps?

Let me see if I can explain it (english is not my native language): on Android, when you update some apps and open them afterwards, it shows you a blue circle with suggestions as to how to use the new features.

It's a one time thing and I'm not even sure if it's a native Android thing, or some manufacturer setting (I have a Motorola phone and a Samsung tablet, I believe I've seen this on both but I might be mistaken).

Anyway, just floating the idea to see what you think.
Comment 19 Nate Graham 2021-01-29 17:13:23 UTC
Yes, such an idea has been floated before and I quite like it. I think it would make a lot of sense!
Comment 20 Nate Graham 2021-02-06 22:02:02 UTC
*** Bug 432548 has been marked as a duplicate of this bug. ***
Comment 21 FeepingCreature 2021-07-28 05:33:51 UTC
First of all, thank you for the flag!

I just want to explain in some more depth how the old behavior fit into my workflow.

At work, I usually have an "active stack" of recently used windows in my brain that I'm switching around in. These are tasks that I'm actively working on, and the window order is crucial in letting me quickly compare files. For instance, I never read the titles of windows when I'm switching, even beyond one deep, because I'm so reliant on already knowing which window I'm switching to.

However, occasionally things come up that interrupt my routine, such as an email or a Slack message that I need to respond to. In that case, I open the Slack window, keeping the editor window order present in the back of my mind, react to whatever needs reacting to, then minimize the offending window to get back to my work. Effectively, I use "minimize" as a way to say "this distraction is handled."

So KDE happily bringing the distraction right back into the foreground is a bit of a problem for this workflow. :)
Comment 22 Nate Graham 2021-07-28 13:20:39 UTC
Yeah, I understand. :) We will probably eventually add a non-hidden configuration UI for this.
Comment 23 FeepingCreature 2022-06-18 12:45:33 UTC
Looks like https://invent.kde.org/plasma/kwin/-/merge_requests/2496 did just that! Excellent!

(It's slightly different, because I think it moves it to a separate "minimized windows only" segment at the bottom? But probably close enough.)