[plasmashell] [Bug 370258] New: No option to bring forward multiple windows of the same program

[Aaron Wolf via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=370258

Bug ID: 370258
Summary: No option to bring forward multiple windows of the
same program
Product: plasmashell
Version: 5.8.0
Platform: unspecified
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Task Manager
Assignee: ***@kde.org
Reporter: ***@gmail.com
CC: plasma-***@kde.org

I happen to be using icon-only task-manager, but this likely applies to all
KDE5 task manager options. When a program has multiple windows, there's no way
to just go back to that program and get all the windows to come to the top!

Reproducible: Always

Steps to Reproduce:
1. Open a program (e.g. Dolphin)
2. Open a second window in the same program
3. Open a second program (e.g. Firefox)
4. Fail to discover a normal single-step mechanism to switch between seeing on
top (A) both windows from the first program together and (B) the window from
the third program

Actual Results:
Click a task-manager icon that indicates multiple windows, they all show in a
zoomed out way which allows selecting only one of them to become active.
Clicking anywhere else results in none of the windows becoming active. No
option available to just bring all the windows from the same program to the
top.

Expected Results:
I expect to be able to quickly switch between two programs where I can get all
the program's windows at once.

[Kai Uwe Broulik]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #1 from Kai Uwe Broulik <***@privat.broulik.de> ---
*** Bug 376159 has been marked as a duplicate of this bug. ***

[Lukas]

https://bugs.kde.org/show_bug.cgi?id=370258

Lukas <***@web.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@web.de

--- Comment #2 from Lukas <***@web.de> ---
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.

[Aaron Wolf]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #3 from Aaron Wolf <***@gmail.com> ---
(In reply to Lukas from comment #2)

Post by Lukas
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.

[Kai Uwe Broulik]

https://bugs.kde.org/show_bug.cgi?id=370258

Kai Uwe Broulik <***@privat.broulik.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |wishlist
CC| |***@privat.broulik.de

[Brennan Kinney]

https://bugs.kde.org/show_bug.cgi?id=370258

Brennan Kinney <polarathene-***@hotmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |polarathene-***@hotmail.
| |com

--- Comment #4 from Brennan Kinney <polarathene-***@hotmail.com> ---
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?

[Aaron Wolf]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #5 from Aaron Wolf <***@gmail.com> ---
(In reply to Brennan Kinney from comment #4)

Post by Brennan Kinney
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.

[Kai Uwe Broulik]

https://bugs.kde.org/show_bug.cgi?id=370258

Post by Aaron Wolf
Naively, I agree it seems this should be easy if not trivial to implement.

Feel free to send a patch.

[Brennan Kinney]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #7 from Brennan Kinney <polarathene-***@hotmail.com> ---
(In reply to Kai Uwe Broulik from comment #6)

Post by Kai Uwe Broulik

Post by Aaron Wolf
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?

[Brennan Kinney]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #8 from Brennan Kinney <polarathene-***@hotmail.com> ---
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 :)

[Eike Hein]

https://bugs.kde.org/show_bug.cgi?id=370258

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.

[Eike Hein]

https://bugs.kde.org/show_bug.cgi?id=370258

Post by Brennan Kinney
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").

[Brennan Kinney]

https://bugs.kde.org/show_bug.cgi?id=370258

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.

[Eike Hein]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #12 from Eike Hein <***@kde.org> ---
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.

[Brennan Kinney]

https://bugs.kde.org/show_bug.cgi?id=370258

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?

[Eike Hein]

https://bugs.kde.org/show_bug.cgi?id=370258

Post by Brennan Kinney
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.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=370258

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
CC| |***@zoho.com
Ever confirmed|0 |1

--- Comment #15 from Nate Graham <***@zoho.com> ---
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

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=370258

--- Comment #16 from Nate Graham <***@zoho.com> ---
*** Bug 384398 has been marked as a duplicate of this bug. ***

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=370258

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |usability

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=370258

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.kde.org/show_b
| |ug.cgi?id=379259

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=370258

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.kde.org/show_b
| |ug.cgi?id=390400