| Summary: | After removing a second panel with taskbar, windows still animate minimization into it | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Daniel Vrátil <dvratil> |
| Component: | Task Manager and Icons-Only Task Manager widgets | Assignee: | Eike Hein <hein> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | darkinosunino, dcalvino, kontakt, mgraesslin, nate, notmart |
| Priority: | NOR | ||
| Version First Reported In: | 5.1.95 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Daniel Vrátil
2015-01-15 12:54:12 UTC
This happens because Task Manager instances will export the new target geometry for a client to kwin (via window props) every time a task button moves. Task Managers visualizing the same clients will therefore have contention and which one will win depends on timing. Destroying any one of them doesn't make the other re-export - there's no communication between separate instances. One way to avoid this in your scenario, on the user level, is to configure each Task Manager to only show windows from that screen. It would be nice to solve this. My preferred way would be to augment the comm protocol between the Task Manager and kwin to let kwin know about every task button and have it pick which one to minimize to, although the destruction case is then still non-trivial to handle. The alternative would be to make Task Managers communicate with each other. Since they're usually in the same process there are ways to do this (starting with static members in the C++ backend, ugly as it is). This is low-priority though and probably won't be addressed soon. I'll add Martin to CC just so he's in the loop. > It would be nice to solve this.
Wayland?
^ Fine with me :). Although I suppose the basic design work on this is somewhat windowing-system-independent. nah, on X11 we use the NETWM spec and would have to move away from it. On Wayland we will have our own custom interface anyway. also, for a while the old task manager still exists evn if hidden, for the delete undo stuff *** Bug 365137 has been marked as a duplicate of this bug. *** This bug exists in Plasma 5.7. Still present in Plasma 5.20 (i.e. current git master). I can also reproduce just by adding a Task Manager widget to the desktop on a single screen. After removing it, windows still want to minimize into the location where it was. Still the case in 5.22.5. The only way to get it to grab the minimization "focus" again on the main panel is to make some re-arrangement or change to it. It seems the focus goes to whatever panel got modified/changed last. Acceptable workaround, but I'd propose to have the panels clearly identified in some form on a setting and perhaps using window rules be able to force them to minimize to a specific panel. That would also allow specific apps to minimize to specific panels. No idea how hard that'd be though, maybe it's not possible. Operating System: Manjaro Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 Kernel Version: 5.13.15-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-8700K CPU @ 3.70GHz Memory: 15,6 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2 Still happens on 6.4 beta. Not all windows minimize to the same Task Manager tho, e. g. if you add a widget to the desktop, minimize some app, then remove the widget, the windows you didn't touch minimize to the previously existing Task Manager (in my case, that's in the panel), and only the one that got minimized to the new keep minimizing to the now deleted one's position. I guess still low prio, but minimizing on the Task Manager that was last clicked would maybe the best one? Especially in the case, where you minimize the app from the Task Manager. |