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

Just right-click on the icon and then click on minimize in the context menu.

Alternatively, right-click on the taskbar and select "settings for icons-only task-manager".
Then configure the middle-mouse button option dropdown menu to
"minimize window/group".
Now middle clicking should show or hide all windows of one application at once.

(In reply to Lukas from comment #2)
> Just right-click on the icon and then click on minimize in the context menu.
> 
> Alternatively, right-click on the taskbar and select "settings for
> icons-only task-manager".
> Then configure the middle-mouse button option dropdown menu to
> "minimize window/group".
> Now middle clicking should show or hide all windows of one application at
> once.
That's a helpful workaround but not the behavior from KDE4 that was much simpler and didn't require any unintuitive setup or anything.

I would think this to be a rather easy feature to add? At least in the icons-only task manager settings you have the middle click action option, an action that brings all windows to the front in that drop down should be fairly easy to implement by someone familiar with KDE dev?

Though from the sounds of it they want to change the behaviour of LMB instead of using MMB, which is fair enough...? Is changing the action to that binding difficult to have as an option?

(In reply to Brennan Kinney from comment #4)
> I would think this to be a rather easy feature to add? At least in the
> icons-only task manager settings you have the middle click action option, an
> action that brings all windows to the front in that drop down should be
> fairly easy to implement by someone familiar with KDE dev?
> 
> Though from the sounds of it they want to change the behaviour of LMB
> instead of using MMB, which is fair enough...? Is changing the action to
> that binding difficult to have as an option?

It does seem that it would make sense for a "bring forward all windows" to be implemented. Then, the KDE customizable approach ought to allow that as an option for *either* left or middle click. And there should be an option for the current behavior of left-click to be used either for left or middle click. Naively, I agree it seems this should be easy if not trivial to implement.

> Naively, I agree it seems this should be easy if not trivial to implement.

Feel free to send a patch.

(In reply to Kai Uwe Broulik from comment #6)
> > Naively, I agree it seems this should be easy if not trivial to implement.
> 
> Feel free to send a patch.

I'd give this a go if I can. The majority of code to work with seems to be located here? https://github.com/KDE/plasma-desktop/tree/master/applets/taskmanager

I'm trying to track how `requestToggleMinimized()` is defined and implemented. Is this calling a C++ method? If you could help me understand how the existing methods are implemented I'll try to contribute this feature along with one of my own(clicking the app icon will show the last active window in that group). 

Do you know if these two features have relevant API calls I can use? For Aaron's feature presumably I would be able to get an array of windows that I could iterate through and call an API to bring each to the front(possibly in an order to preserve their Z index as a whole?). 

The window switch(alt + tab) or another method possibly does the API call to make a given window active, would that be the way to go or is there a better way?

For my feature, given the activate window API, I should just need to be able to query what was the last active window for that app icon group. How do I get this information?

I used blame to find this commit: https://github.com/KDE/plasma-desktop/commit/2a24828eedfb14d9a5489cbb7a6a52cf1c0169e6

Is that roughly what is required to add a feature? It's missing the API call being made? Soon as I have the info I need I'll give this a shot :)

plasma-workspace.git:libtaskmanager/tasksmodel.h @ requestToggleMinimized.

I'm confused about this:

> the behavior from KDE4 that was much simpler

AFAIR, the behavior in KDE 4 was the same.

> For my feature, given the activate window API, I should just need to be able to query what was the last active window for that app icon group. How do I get this information?

You can't easily. That's why it's not implemented. You have KWindowSystem::stackingOrder() to get the stacking order for shown windows, and raising them in that order is easy. But minimized windows don't appear in the stacking order, and adding massive amounts of stacking order tracking to the TM is a no-go.

Otherwise your deductions are all correct, going over the windows in the group in either QML or on the C++ side is easy enough.

> Is that roughly what is required to add a feature?

Sorta kinda no not really. That calls requestToggleMinimized on the model index for the group which will run that action over the group members, but toggleMinimize is not the same as raise.

If you're willing to sacrifice stacking order stuff is easy but this will just predicate the next bug report ("Clicking on a group to bring its windows to the front doesn't preserve the order I left them in").

> You have KWindowSystem::stackingOrder() to get the stacking order for shown windows

That's the stacking order for all windows(bar minimized) right? Is there events I can use to track the stack order on the JS end? I could probably maintain my own tracking of stack order per app with arrays? Or is there something bad about that I'm not aware of? Personally if they have minimized windows you could argue they expect them to remain minimized when raising the group.

For my feature, if I'm able to know when windows become active and know what group they belong to I can probably track that on the JS/QML end too. So if a window gets minimized it could still be stored as the last active window for the app raising it on click.

It's highly undesirable to track stacking order in the Task Manager (and even more so on the QML/JS side) for many reasons:

- It's error-prone because it's non-trivial to get right. For example, how does the stacking order of a hidden window relate to shown windows as they get raised and lowered while the window is hidden? This kind of behavior is undefined and differs by window manager, so even if you manage to mimick KWin behavior, ...

- It's enormously inefficient. Every window state changes you have yet another process doing stuff in response for something rarely needed.

I won't accept it in review (I wrote and maintain all this stuff) so ... I'm not saying there isn't a sane way to do this, but I haven't sat down and done the research on what that way is. It might be interesting to look at how the Mac OS window manager does it, since they were comitted to MDI for a long time and probably have protocols around per-window-set focus planes.

> how does the stacking order of a hidden window relate to shown windows as they get raised and lowered while the window is hidden?

I'm not too concerned about tracking minimized windows. If I was to have windows 1-5 with the z order 1-5 respectfully, and window 3 was minimized, it would still be tracked as 3, if 2 were raised to the top it's now above the minimized window which is still above 1. I'm probably making a mistake with that basic approach somewhere. 

I think for a first iteration just raising the open windows above all others while keeping their stack order in the group the same should be fine? Like mentioned, minimized windows with that sort of behaviour probably should remain minimized.

> I won't accept it in review (I wrote and maintain all this stuff) 

No worries, something is better than nothing :) I can avoid the JS tracking arrays/logic. Are you also against tracking the last active window in a group? I don't imagine that being a problem, when a window becomes active it just stores itself into it's group, should be one line? `lastActive[app_name] = active_window`. If you're against that too, I could just take the window with the highest z index(or stack order as you're referring to it as) for the app, which presumably involves iterating with a loop through the stack order array until I find a match?

> Are you also against tracking the last active window in a group?

Yes, sorry (I know it's frustrating to get shot down without reasoning, but there's a host of issues there starting with it not being as easy as "app_name" ...).

BTW: You can take a look at PagerModel in plasma-desktop.git:applets/pager for some inspiration re how it combines stackingOrder with libtm's WindowTasksModel. If we move this into libtm proper the Pager code will also need to be refactored. And none of this will work on Wayland for the time being because KWS::stackingOrder doesn't work there.

I would also like this and am also fine with minimized windows' ordering being untracked. It could be as simple as this:

- First un-minimize minimized windows, in any order
- Then, activate non-minimized windows, in reverse order such that the most-recently-used window winds up on top

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

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

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

The duplicated bugs aren't quite the same. Two are saying clicking should cycle toplevels.

Generally it's waaaay more productive when bug reports state the problem and not propose solutions. Something this and all the duplicates do :/

I can't imagine bringing multiple windows forward at once being a good solution to anything. If I have a maximised dolphin and 2 smaller ones lower in the stack I have no way to access the ones lower in the stack.

(In reply to David Edmundson from comment #19)

> I can't imagine bringing multiple windows forward at once being a good
> solution to anything. If I have a maximised dolphin and 2 smaller ones lower
> in the stack I have no way to access the ones lower in the stack.

I imagine this: Multiple windows of the same application are split side-by-side, and bringing them to front shows all of them. The windows are not overlapping or stacked thereafter, because they were side-by-side before they were minimized.

(In reply to Lukas Ba. from comment #20)
> (In reply to David Edmundson from comment #19)
> 
> > I can't imagine bringing multiple windows forward at once being a good
> > solution to anything. If I have a maximised dolphin and 2 smaller ones lower
> > in the stack I have no way to access the ones lower in the stack.
> 
> I imagine this: Multiple windows of the same application are split
> side-by-side, and bringing them to front shows all of them. The windows are
> not overlapping or stacked thereafter, because they were side-by-side before
> they were minimized.

It's not just minimization. Maybe there are multiple windows being used all visible at once by one program, and then a second (maybe even full-screen) program is opened or brought forward. Now, there's no way to easily go *back* to see the multiple windows of the original program other than minimizing or pushing to the back the particular blocking windows.

I want a way to have a multi-window program open, then move to another program, and then go back to the first by choosing the first (rather than thinking about which program(s) to hide).

> I can't imagine bringing multiple windows forward at once being a good
> solution to anything. If I have a maximised dolphin and 2 smaller ones lower
> in the stack I have no way to access the ones lower in the stack.

It should preserve your last stack order. If you had an application with a window arrangement open and it made sense to you, it will come back that way. You wanted a big window on top of everything else, it will come back that way. You wanted one big window in the back and two small on top it, it will come back that way. You need to navigate windows within the app, there are multiple ways and shortcuts for it.

The issue is you can't arrange windows from one application and easily switch back to them. Even worse are applications who require two windows to be useful.

That said: I have no idea about the actual implementation, so I'm might be ignorant here, but maybe a similar result is easier achieved in the Task Switcher. The Task Switchers already shows all active windows in order of last usage, the information is there. The Task Switcher also already has an option to show only one window per application. Add an option to activate all the windows which are aggregated by that icon and at least I wouldn't need this feature in the TM anymore.

(In reply to openmail+kde from comment #22)
> > I can't imagine bringing multiple windows forward at once being a good
> > solution to anything. If I have a maximised dolphin and 2 smaller ones lower
> > in the stack I have no way to access the ones lower in the stack.
> 
> It should preserve your last stack order. If you had an application with a
> window arrangement open and it made sense to you, it will come back that
> way. You wanted a big window on top of everything else, it will come back
> that way. You wanted one big window in the back and two small on top it, it
> will come back that way. You need to navigate windows within the app, there
> are multiple ways and shortcuts for it.
> 
> The issue is you can't arrange windows from one application and easily
> switch back to them. Even worse are applications who require two windows to
> be useful.
> 
> That said: I have no idea about the actual implementation, so I'm might be
> ignorant here, but maybe a similar result is easier achieved in the Task
> Switcher. The Task Switchers already shows all active windows in order of
> last usage, the information is there. The Task Switcher also already has an
> option to show only one window per application. Add an option to activate
> all the windows which are aggregated by that icon and at least I wouldn't
> need this feature in the TM anymore.

To be clear, I've gotten used to the original double-middle-click workaround mentioned in comment 2 https://bugs.kde.org/show_bug.cgi?id=370258#c2 It's just certainly non-obvious for anyone not introduced to the idea.

Regarding Bug 407144 (https://bugs.kde.org/show_bug.cgi?id=407144):

The behavior described in Item 1 of the description is achieved with KWin Task Switcher if you choose to sort the application windows by "Recently used" and if you check "Only one window per application". If Task Manager could do the same (mainly the stacking order), it would be a more homogeneous feeling when switching apps and/or windows.

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

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 368867

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 424268 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/71

Git commit ebaddb7d82b76613dcc010058283df47bb628aaa by Nate Graham.
Committed on 23/07/2020 at 15:39.
Pushed by ngraham into branch 'master'.

[applets/taskmanager] Offer better options when activating grouped tasks

Currently we get many complaints about the behavior of clicking on
grouped tasks, especially for the Icons-Only Task Manager, where the
Present Windows effect is always used when available.

This commit overhauls what happens when you click on a grouped task to
offer three options:
1. Show tooltips (new default setting)
2. Show Present Windows effect
3. Show textual list (AKA group dialog)

The user is now free to choose in the settings window which visualization
best suits them.

This commit does not implement the most heavily-requested option--to
bring forward all of the windows belonging to a grouped task
(https://bugs.kde.org/show_bug.cgi?id=370258)--as it is still blocked by
some technical isues related to stacking order and outstanding UX
uncertainty regarding what should happen when one or more of the windows
in a group happens to beminimized. However, since this commit introduces
a config UI for choosing the desired behavior when activating a grouped
task, there is now a place to put that option once it is implemented.
Related: bug 424268, bug 390400
FIXED-IN: 5.20

Depends on https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/39

M  +1    -1    CMakeLists.txt
M  +4    -0    applets/taskmanager/package/contents/config/main.xml
M  +49   -0    applets/taskmanager/package/contents/ui/ConfigBehavior.qml
M  +5    -3    applets/taskmanager/package/contents/ui/Task.qml
M  +27   -7    applets/taskmanager/package/contents/ui/code/tools.js

https://invent.kde.org/plasma/plasma-desktop/commit/ebaddb7d82b76613dcc010058283df47bb628aaa

I've submitted a merge request for this: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/84

Git commit c73f703c8f067d6b82ab2380794a05b7ec439445 by Nate Graham.
Committed on 29/07/2020 at 21:22.
Pushed by ngraham into branch 'master'.

[applets/taskmanager] Make new "cycle through tasks" option the default

This is ultimately the sanest default as it provides the quickest way to
perform the two most common actions for grouped tasks: switching to the
last-used one, or hunting through all of them to find the one you want.
The "Cycle through task" option allows you to perform both actions with
clicks on the same icon, meaning that you don't have to move your cursor
or your visual focus compared to using any of the other three methods.

M  +1    -1    applets/taskmanager/package/contents/config/main.xml
M  +1    -1    applets/taskmanager/package/contents/ui/ConfigBehavior.qml
M  +39   -31   applets/taskmanager/package/contents/ui/code/tools.js

https://invent.kde.org/plasma/plasma-desktop/commit/c73f703c8f067d6b82ab2380794a05b7ec439445

Implemented with https://invent.kde.org/plasma/plasma-desktop/-/commit/39eaa5493df26659c33622d5c2bab1dafd923dcc and https://invent.kde.org/plasma/plasma-desktop/-/commit/c73f703c8f067d6b82ab2380794a05b7ec439445!

Git commit 06b0ee3a11f6f3d90ec2a2aebb7dfb2421c705c3 by Usarin Heininga.
Committed on 19/03/2021 at 20:57.
Pushed by meven into branch 'master'.

Implement WaylandTasksModel LastActivated role.

Window activation is tracked to implement a new front-
end feature to activate the most recently active window (or fall
through to stacking order otherwise) subsequently.

M  +9    -0    libtaskmanager/waylandtasksmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/06b0ee3a11f6f3d90ec2a2aebb7dfb2421c705c3