Bug 374481

Summary: When using Present Windows effect for grouped Task Manager icons with Task Manager set to show windows from all Activities, clicking on one from a different activity shows the effect with no windows
Product: [Plasma] kwin Reporter: Shitikanth <golu3990>
Component: effects-present-windowsAssignee: KWin default assignee <kwin-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: kde, lemmyg, mgraesslin, nate, notuxius, plasma-bugs
Priority: NOR    
Version: 5.23.5   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In:

Description Shitikanth 2017-01-03 07:13:58 UTC
Expected behavior: It should switch to the most recently used window of the application, or at least show a list of windows of the application that the user can select from (this is the behavior of the standard task manager).

Steps to Reproduce:
1. Use icon only task manager
2. Open multiple instances of an application
3. Go to a different activity
4. Click on that application's icon
Comment 1 Eike Hein 2017-01-03 07:22:55 UTC
Doing nothing is certainly unexpected. Normally the "Present Windows" effect should engage, and if the effect is not available, the popup dialog with the list should appear as in the standard TM. What are you Desktop Effecs settings?
Comment 2 Shitikanth 2017-01-03 17:36:25 UTC
@Eike The "Present Windows" effect is engaged normally when I click on the icon in the same activity the application windows are open in. However, if I go to a different activity and click on the icon (I have "Show only tasks from the current activity" option disabled), nothing happens.

I think what is happening is that the "Present Windows" effect looks for the windows of that application only in the current activity, but since there *are* no windows of that application in the activity I am in, nothing shows up.
Comment 3 Eike Hein 2017-01-04 05:13:55 UTC
You might be on to something here. The real thing works a bit differently - the Present Windows effect has no idea about applications, the Task Manager just gives it a list of windows to show. But KWin probably refuses to show windows not of the current activity. I think this is wrong. I'll CC Martin Graesslin.
Comment 4 Alexander Mentyu 2018-02-05 10:20:53 UTC
Switching of activities is working both after clicking on informational tips previews and left click menus (when 'Present windows' effect is disabled) for selected apps - but 'Present windows' effect isn't working

Plasma: 5.11.5
Apps: 17.12.1
Frameworks: 5.42.0
Qt: 5.10.0
Kernel: 4.14.16-1-MANJARO
Comment 5 Eike Hein 2018-02-05 11:13:01 UTC
Marting, ping?
Comment 6 Martin Flöser 2018-02-05 17:38:56 UTC
activity support in KWin is basically unmaintained.
Comment 7 Eike Hein 2018-02-06 06:12:51 UTC
That's not a super useful response, though. Can you see into assigning this ticket to KWin and outfitting it with proper information (title, details)? Thanks.
Comment 8 Kai Uwe Broulik 2018-02-06 14:31:38 UTC
Present Windows indeed ignores windows not on the current activity. I think if a 3rd party explicitly sets a list of windows to be shown (ie. this use case, ModeWindowGroup) it should ignore activities.
However, even if it did that, the window pixmap wouldn't be kept around if the window is on another activity, so this isn't as trivial as it seems.
Comment 9 galder 2022-01-30 16:05:59 UTC
Looks like an old issue. Setting it to needs more info.
Please try with a newer version(plasma 5.23.5) and if this is not an issue any more let us know.
Bugs placed into NEEDSINFO status will receive a reminder if the ticket:

    Is at least 15 days old
    Has not received any comment within 15 days

If a bug remains in NEEDSINFO for another 15 days with no comment, it will be closed as RESOLVED > WORKSFORME.
If a bug remains in NEEDSINFO with a comment provided within less than 15 days, no action will be taken (as it does not meet the above criteria).
Comment 10 Nate Graham 2022-01-30 19:51:09 UTC
This issue is definitely still an issue. Please don't put bugs in NEEDSINFO WAITINGFORINFO status just because they're old--especially not if comments indicate that developers have found the issue (even if they forgot to mark it as confirmed).

Moving to KWin since the issue here is that the Present Windows effect is not activity-aware.
Comment 11 Marco Martin 2022-05-06 11:38:23 UTC
Git commit ae1937badc097a864ecfc62e79e7a3899c3be572 by Marco Martin.
Committed on 06/05/2022 at 11:37.
Pushed by mart into branch 'master'.

Remove completely present windows

since it has been replaced by windowview, and Desktop Grid
is ported as well, remove present windows which is effectively dead code
now
Related: bug 447001, bug 362844, bug 450487, bug 453426, bug 185381, bug 413342, bug 451150, bug 283333, bug 315314, bug 397500, bug 321236, bug 436572, bug 335782

M  +0    -1    src/effects/CMakeLists.txt
D  +0    -45   src/effects/presentwindows/CMakeLists.txt
D  +0    -17   src/effects/presentwindows/main.cpp
D  +0    -18   src/effects/presentwindows/main.qml
D  +0    -75   src/effects/presentwindows/metadata.json
D  +0    -2054 src/effects/presentwindows/presentwindows.cpp
D  +0    -343  src/effects/presentwindows/presentwindows.h
D  +0    -51   src/effects/presentwindows/presentwindows.kcfg
D  +0    -104  src/effects/presentwindows/presentwindows_config.cpp
D  +0    -46   src/effects/presentwindows/presentwindows_config.h
D  +0    -487  src/effects/presentwindows/presentwindows_config.ui
D  +0    -36   src/effects/presentwindows/presentwindows_proxy.cpp
D  +0    -35   src/effects/presentwindows/presentwindows_proxy.h
D  +0    -6    src/effects/presentwindows/presentwindowsconfig.kcfgc

https://invent.kde.org/plasma/kwin/commit/ae1937badc097a864ecfc62e79e7a3899c3be572
Comment 12 Nate Graham 2022-05-06 13:29:28 UTC
This still affects the new QML-based Present Windows effect; re-opening.