SUMMARY Right now, whenever a display is not connected, there is no way in GUI to manage panels that are on it. This can be an issue if you change out one monitor for another, right now you mostly have two options: 1: delete the entire config and start from scratch 2: create a new panel on the new monitor and leave the old one hanging around in config. In both case, you would have to reconfigure the panel again. In the first case, all your panels even. STEPS TO REPRODUCE Connect a secondary monitor, create a panel on said monitor, disconnect said monitor. DESIRED RESULT Ideally I would like to see an additional while going into the panel edit mode, whenever there are panels that are not currently in view, to for example move them into view, or even just to remove them outright. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.15.7-zen1-1-zen (64-bit) Graphics Platform: X11 Display setup: 3x 1440p (2x 144hz 1x 155hz), 1x 1080p (60hz) ADDITIONAL INFORMATION I am fully aware that my setup with 4 monitors at home (and 5 at work) is rather niche, but it can be a decent time sink. Another thing is, sometimes the panels on secondary monitors seem to vanish, possibly because a driver update lists it different, possibly because I plug things in a different port, or even when I forgot to turn one of them on before boot. Sadly, this is not something I can consistently reproduce, but it happens with some regularity. I often have to recreate panels because of this, sometimes I even get extra duplicate panels somehow. Regardless, even in more common multi-monitor setups it can still happen, just less frequently.
Can you help me understand why you need or want to configure panels that aren't visible? By definition, if they aren't visible, you won't be able to interact with them and make use of your customizations. Is there a problem with configuring them only once they're visible again? If this is to work around a multimonitor bug, we should just fix that bug. :) In which case can you explain the bug that makes you want this feature?
(In reply to Nate Graham from comment #1) > Can you help me understand why you need or want to configure panels that > aren't visible? By definition, if they aren't visible, you won't be able to > interact with them and make use of your customizations. Is there a problem > with configuring them only once they're visible again? > > If this is to work around a multimonitor bug, we should just fix that bug. > :) In which case can you explain the bug that makes you want this feature? There would be two main reasons outside multi-monitor bugs to want them. First to clean up the related configuration files when you know you will not connect the monitor again. Second would be to migrate a panel configuration to a new display layout. Repeating myself does make me feel like it's less of a big deal than I made it out to be. As for the multi monitor issues, I wish I could point at do x and a panel is gone, sadly I have not been able to reproduce the issues on demand. It just happens somewhat randomly at times, sometimes after boot, sometimes after a gaming session disabling all but my main display, saldy nothing more I can say that it happens somewhat frequently. On average, I would say every other week, but it is fairly random.
Sidenote, I have kscreen 2 turned off as a service on my home system. The reason being that 3 of my 4 monitors behave a bit wacky with it enabled, as posted in: 429992, this does not seem to prevent panels from interacting with display changes.
(In reply to qlum from comment #2) > There would be two main reasons outside multi-monitor bugs to want them. > First to clean up the related configuration files when you know you will not > connect the monitor again. Since the configuration data is benign just sitting there on disk, I don't think this is really a valid use case. You never know, you might use that screen again! And if it's driving you crazy, you can always edit the config file by hand. > Second would be to migrate a panel configuration to a new display layout. This seems like a more valid use case, because you could have a panel config on one layout that becomes inaccessible and unable to be moved to a different layout. We are currently experimenting with an idea to make layouts bound not to specific screens, but to the numerical position that a screen occupies in a multi-screen layout. So for example when you have two screens, your second screen gets its own layout, but if you unplug that screen and plug in a totally different screen, it would get the same layout that the old Screen #2 got. So the layout for Screen #2 would never become inaccessible as long as you still had two screens. However this wouldn't help in the case where, say, you had three screens, decided 2 was enough, but wanted to migrate your setup from screen #3 to Screen #2. So we would still have a niche use case for this even with the proposed change. Thankfully this would be satisfied by another piece of in-progress work: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1136. > As for the multi monitor issues, I wish I could point at do x and a panel is > gone, sadly I have not been able to reproduce the issues on demand. It just > happens somewhat randomly at times, sometimes after boot, sometimes after a > gaming session disabling all but my main display, saldy nothing more I can > say that it happens somewhat frequently. On average, I would say every other > week, but it is fairly random. I understand. The code for multimonitor stuff is super awful and fragile and we're currently working on it.
Git commit e66349f795bee64a5a18c2dcc3b5e0471417e251 by Marco Martin, on behalf of Cyril Rossi. Committed on 21/01/2022 at 13:34. Pushed by mart into branch 'master'. Plasmashell : add dialog to manage containments when in edit mode An UI to manage Screen assignment of Containments, the main use case is to recover lost or inactive panels from a display that you can no longer access. qml part: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/618 related to https://phabricator.kde.org/T14346 Access the dialog from Toolbar in Edit Mode (Manage containments) ![Screenshot_20211222_114140](/uploads/31379781e3315a612d695220e623353b/Screenshot_20211222_114140.png) ![Screenshot_20211217_095945](/uploads/f890d5ac9f3ee6e82991d325b3078f5b/Screenshot_20211217_095945.png) To show the dialog, simply enter in `edit mode`, then you can : * See known displays and their panels and desktops, the dialog automatically update when adding/moving/removing a panel. * Delete a panel or a desktop * Recover a panel by moving it to an active display (click on move icon, then select the proper action in drop menu) * Recover a desktop by moving it to an active display, in fact, this will swap it with th targeted desktop * Modifications are automatically applied What I've tested: * Adding a panel, adding some applet on it. Then disabling its display, open the dialog and move it to an active display, restarting session, the panel is here with its applet. * On another display, add applets (sticky note) on the desktop. Disable this display, open the dialog and move it to an active display, restart session, both desktop were swapped and you see the background (if different) and sticky note available. M +1 -0 shell/CMakeLists.txt M +3 -0 shell/packageplugins/shell/shellpackage.cpp A +461 -0 shell/shellcontainmentconfig.cpp [License: LGPL(v2.0+)] A +145 -0 shell/shellcontainmentconfig.h [License: LGPL(v2.0+)] M +209 -0 shell/shellcorona.cpp M +21 -0 shell/shellcorona.h https://invent.kde.org/plasma/plasma-workspace/commit/e66349f795bee64a5a18c2dcc3b5e0471417e251
That fully fixes it, I'd say!
has this been deployed with plasma 5.24? I was looking out for this but can't find a package...
pls forget last comment. If I understand right this will be implemented in 5.25...