| Summary: | Minimizing a window doesn't move it to the bottom of the Task Switcher (alt+tab) list anymore | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | JanKusanagi <jan-bugs> |
| Component: | tabbox | Assignee: | Nate Graham <nate> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | default_357-line, jan-bugs, jk, kde, mh, nate, ricardo |
| Priority: | NOR | Keywords: | regression, usability |
| Version: | 5.20.0 | ||
| Target Milestone: | --- | ||
| Platform: | Mageia RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/b3e9c819537cf292d9b1c4d19c5ce7adde00158e | Version Fixed In: | 5.21 |
| Sentry Crash Report: | |||
|
Description
JanKusanagi
2020-10-16 21:39:11 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. :) >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.
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? (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 =) In the meantime, could we maybe have a config file option, without a GUI counterpart? Just so some of us don't go insane =) Sure, I'll submit one and we'll see where it goes. No promises, sorry. :) https://invent.kde.org/plasma/kwin/-/merge_requests/370 Thanks, appreciated =) 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. :) 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. Speak up in https://invent.kde.org/plasma/kwin/-/merge_requests/370. :) 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 Was this backported to 5.20.3? *_* 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. 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! Glad you've managed to get relief. :) 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. See https://bugs.kde.org/show_bug.cgi?id=427840#c11for a way to go back to the old behavior. 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. Yes, such an idea has been floated before and I quite like it. I think it would make a lot of sense! *** Bug 432548 has been marked as a duplicate of this bug. *** 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. :) Yeah, I understand. :) We will probably eventually add a non-hidden configuration UI for this. 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.) |