Bug 310157 - All panels end up on the same display after coming back from cloning multihead setup
Summary: All panels end up on the same display after coming back from cloning multihea...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: plasma4
Classification: Plasma
Component: multihead (show other bugs)
Version: 4.11.2
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-15 16:45 UTC by Vita Humpa
Modified: 2018-06-08 18:35 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vita Humpa 2012-11-15 16:45:19 UTC
Having set a usual dualhead configuration, with two displays side-by-side sharing the screen and having own panels - if this is changed to cloning instead followed by restoring the original settings - both panels stay at the same display. Looks like the information about the pre-cloning state is lost with cloning.

Reproducible: Always

Steps to Reproduce:
1. Set a side-by-side dualhead configuration. Each display with own panel
2. Now set the two displays to cloning.
3. Set the original setting
Actual Results:  
Both panels are now present on one of the displays, covering each other. If these had a same height before - you will have to move the panel back manually.

Expected Results:  
The other panel jumps back on its original display.
Comment 1 Elias Probst 2013-11-04 18:53:38 UTC
The same issue is present when simply disabling the 2nd screen (no need to switch from dual- to clone-view).

This happens here on 4.11.2.

Looking closer at the changes in plasma-desktop-appletsrc, the problem seems to be:
The [Containment] section which hosts the "plugin=panel" has an attribute "screen" and another attribute "lastScreen".
As far as I understand, "screen" represents the current screen on which the panel is shown and "lastScreen" the previous screen on which is shown, which is supposed to to do exactly what we actually want: remember the panel's latest screen, so it can be restored to this value when connecting the display again.

In reality, the value of "lastScreen" is set to the same value (0) as "screen" at the moment when the 2nd screen is unplugged.

This makes it impossible for Plasma to restore the panel on the 2nd screen, as "lastScreen" doesn't hold the value of last screen anymore.

Another probably related issue might be, that the "geometry" value of the 2nd screen isn't remembered. I don't see anything like "lastGeometry", so once restoring "lastScreen" properly works, the panel might actually be restored with the geometry of screen 0.
Comment 2 Elias Probst 2013-11-06 19:08:41 UTC
After thinking a bit about it: why is a panel moved to another screen at all?
Panels usually contain screen specific items, so why would I have a 2nd panel which is a replicate of my primary panel on my primary screen after unplugging the external display?

I think panels shouldn't be moved to another screen at all but should instead stick to the screen on which they were placed initially all the time.
Comment 3 Aaron J. Seigo 2013-12-17 15:24:22 UTC
because panels that don't get moved are perceived as "lost". guess how many bug reports we got about that? ;)

the shouldn't be covering each other, however; if they overlap they should not be migrated. not having this issue myself, i can't realistically debug it.
Comment 4 Victor B. Gonzalez 2015-09-03 18:30:04 UTC
Not sure if this is the correct bug but adding a secondary panel to a secondary display causes the primary monitor and panel to get clobbered with it if the secondary display is turned off.
Comment 5 Nate Graham 2018-06-08 18:35:52 UTC
Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham