When restoring a group of windows using requestToggleMinimized, the windows seem to be stacked in the order they were opened, but stacking them in most recently used order makes more sense. (Eg. consider the case when there are multiple browser windows opened and in the background and you quickly want to access the last website you have seen.) Reproducible: Always Steps to Reproduce: 1. Configure middle click to inimize/Restore Window or Group 2. Middle click on a group Actual Results: Windows get stacked such that the most recently opened window is on top. Expected Results: Windows get stacked such that the most recently used/focused window is on top. The Smooth Tasks Applet for Plasma 4 implemented this behavior.
I don't think there's any good way to do this in the Task Manager. I don't have a data source for "recently used", and I don't want to track activation changes in the lib. I think for this I'd need a "restore list of windows" API in the windowing system that figures out what to do. Martin?
Even KWin would not be able to handle that without significant engineering effort. The reason for that is that a window is moved to the end of the FocusChain (KWin's model of recently used windows) when it gets minimized. In addition KWin has a chain per desktop and those can be different. KWin would not be able to restore it the way the user expects it. I don't think that it's worth the effort.
Is it guaranteed that restoring a minimized window will activate it btw?
(In reply to Eike Hein from comment #3) > Is it guaranteed that restoring a minimized window will activate it btw? That's X what we are talking about. Nothing is guaranteed, I'd say.
Git commit c0acd1434147cff80de4841c62e766a2bb817c0f by Eike Hein. Committed on 25/11/2019 at 18:50. Pushed by hein into branch 'master'. [libtaskmanager] Track stacking order and window activation (on X11) Summary: `TaskGroupingProxyModel::requestToggleMaximized` now uses this to minimize and restore groups of windows while preserving the stacking order, a frequently user-requested wish. Related: bug 370258 Window activation is additionally tracked to implement a new front- end feature to activate the most recently active window (or fall through to stacking order otherwise) subsequently. A Wayland implementation requires the addition of a `PlasmaWindowManagement::stackingOrder()`, which should be a QList of PlasmaWindow* in stacking order, along with a change signal. We discussed this at the Plasma+KWin sprint and I'll code up patches to KWin and KWayland soon and then implement the new API in here. Reviewers: #plasma Subscribers: davidedmundson, pino, anthonyfieroni, ngraham, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D22053 M +5 -0 libtaskmanager/abstracttasksmodel.h M +19 -6 libtaskmanager/taskgroupingproxymodel.cpp M +21 -1 libtaskmanager/xwindowtasksmodel.cpp https://commits.kde.org/plasma-workspace/c0acd1434147cff80de4841c62e766a2bb817c0f
*** Bug 414720 has been marked as a duplicate of this bug. ***