Bug 368867

Summary:	restoring a group of windows should stack them in recently used order
Product:	[Plasma] plasmashell	Reporter:	gulp21 <support.gulp21+kde>
Component:	Task Manager and Icons-Only Task Manager	Assignee:	Eike Hein <hein>
Status:	RESOLVED FIXED
Severity:	wishlist	CC:	get.sonic, mgraesslin, nate, plasma-bugs
Priority:	NOR
Version:	5.7.5
Target Milestone:	1.0
Platform:	Neon
OS:	Linux
Latest Commit:	https://commits.kde.org/plasma-workspace/c0acd1434147cff80de4841c62e766a2bb817c0f	Version Fixed In:
Sentry Crash Report:

Description gulp21 2016-09-15 19:52:45 UTC

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.

Comment 1 Eike Hein 2016-09-16 09:54:30 UTC

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?

Comment 2 Martin Flöser 2016-09-16 10:39:15 UTC

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.

Comment 3 Eike Hein 2016-09-16 10:53:25 UTC

Is it guaranteed that restoring a minimized window will activate it btw?

Comment 4 Martin Flöser 2016-09-16 11:41:13 UTC

(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.

Comment 5 Eike Hein 2019-11-25 18:54:07 UTC

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

Comment 6 Nate Graham 2019-12-02 20:44:11 UTC

*** Bug 414720 has been marked as a duplicate of this bug. ***