Bug 241332

more details are needed, yes. in particular:

* the size of the panels (can just attach your plasma-desktoprc file, even)
* the resolution of the monitors

Created attachment 47875 [details]
plasma-desktoprc

resolutions
primary display: 1440x900
extra monitor: 1920x1200

aaron:
you made the panels migrate when a screen is turned off a while ago
that's coorect, but if the effect is that users remove the migrated panel, that is a bit of a problem.
i think that's an intended behaviour, if it really works i don't know

@Anselmo: do the panels overlap on the single screen when the second screen is disconnected? could you attach a screenshot of the post-migration to this report?

@Marco: we got fairly constant feedback about wanting this as the desired behaviour, and it makes sense in the most common of cases. i suppose we could add a confirmation dialog asking the user if they want to move the panel ... i'd like to avoid doing that if at all possible though. one thing that it currently already checks for (or is supposed to) is whether or not the panels overlap, and if they do, not to move the panel over. it seems like that isn't working, however.

Created attachment 47919 [details]
panels overlap

@Aaron: Yes, they overlap. Snapshot attached.

do you build from source? if so, could you apply a patch and get some additional debug output for us? if so, i'll attach it to this bug report ...

Yep, I build KDE from sources and I can test your patch =)

do you compile from svn? if so, can you svn up and build kdebase/workspace/plasma/desktop/shell/ and look for output that contains PlasmaApp::canRelocatePanel when you replicate the problem? if you don't compile from svn, i'll attach a patch to the bug report ...

Yes, I compile from svn.

I reproduced the scenario "moving from the 2 screens to single screen setup".

In the output:

PlasmaApp::canRelocatePanel: testing: 0 PanelView(0x8dc73f0) QRect(0,0 1920x35) 3 QRect(1440,0 480x35)

Moving back to '2 screens setup', no PlasmaApp::canRelocatePanel in the output.

*** Bug 242662 has been marked as a duplicate of this bug. ***

PlasmaApp::canRelocatePanel: testing: 0 PanelView(0x8dc73f0) QRect(0,0 1920x35)
3 QRect(1440,0 480x35)

that's it? just the one line? 

aaah, because the other panel hasn't been created yet! so this is caused by the panel creation order *goes off to fix*

SVN commit 1142367 by aseigo:

when the containment screen changes, pinch.
CCBUG:241332


 M  +1 -0      panelview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1142367

SVN commit 1142369 by aseigo:

* don't keep panel views around for screens that don't exist
* relocate panels only after all panels that should have views have been set up; prevents errors due to containment loading order
BUG:241332


 M  +22 -14    plasmaapp.cpp  
 M  +2 -1      plasmaapp.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1142369

ok, that _should_ fix the issue seen by the original reporter. if you can please test and confirm, that would be great :)

thanks for the follow ups, they were critical to understanding and fixing this issue.

hm... I was traveling, couldn't test it before. I recompiled KDE trunk with svn r1143681 and unfortunately the problem still happening.

I'll try to check the code later, maybe it's easier to fix here as I'm running KDE in the problematic setup.

i can reproduce with 4.5 rc1

I can confirm that the original problem is still present in 4.5 RC3 on Fedora 13. I can provide any config files or logs if you need additional information.

if you want this fixed in 4.5.0 (or any subsequent release, for that matter), someone with a machine to duplicate this is going to have to step up and so some work. i'm coding in the dark here with a single screen laptop. 

the relevant code is in 

kdebase/workspace/plasma/desktop/shell/plasmaapp.cpp

in PlasmaApp::createWaitingPanels()

one possibility is that the event loop gets re-entered between panels being created and so createWaitingPanels() gets called with an incomplete list of panels.

it could be a simple matter of changing m_panelViewCreationTimer.setInterval(0); to a higher number to allow enough time for all the panels to be created. though if that's the case, that would seem to be a bit of a hack.

perhaps putting a guard around c->initializeLayout(); in PlasmaApp::corona() and not starting m_panelViewCreationTimer until it is done...

but really, this needs to be done on a machine that cn be used to test and reproduce.

SVN commit 1155782 by aseigo:

delay creation of the initial views until everything is set up; might help with BR241332
CCBUG:241332


 M  +6 -2      plasmaapp.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1155782

SVN commit 1155783 by aseigo:

delay creation of the initial views until everything is set up; might help with BR241332
CCBUG:241332


 M  +6 -2      plasmaapp.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1155783

I rebuilt the Fedora RPMs with this patch applied and it doesn't seem to make a difference. 

After running in dual head mode and adding a panel to the second display, moving to a single head setup caused the panels to be "stacked" on the first display. The panels remained stacked on the first display after moving back to a dual head setup.

*sigh* well, thanks for testing. it's now up to someone with such a machine to test.

Ok, I spent some time reading this code and making tests / checking debug output / trying to fix it, with no success until now/

I'll divide the results in 2 cases:

1) The transition between 2 monitors -> 1 monitor happens while plasma-desktop is not running (i.e., planels placed by setupDesktop)

One thing I noticed is that the in this case the comparison pv->screen() == screen->id() in canRelocatePanel is always false, what makes this method returns true. So, once we have a panel candidate to be relocated, it is going to be relocated, independent of the other conditions.

Without that verification, panel overlaps does not happen anymore.
Panels in different positions than the ones in the primary screen are relocated.

---

2) The second screen is turned off while plasma-desktop is running (i.e., screenRemoved in action):

pv->screen() == screen->id() is always true (at least it happened in every test). The problem seems to be pv->geometry().intersects(newGeom) because its result change during the process, probably due to an update in the geometry of the panel being analysed.

----

In both cases, if the extra monitor reappear, nothing happens with the panels (the ones originally from the extra screen are not reset to the original position).

---

Well, this is what I found today. Consider that it was my first contact with this part of plasma code, so I probably skipped something important in these tests. 


A question that comes to my mind is: Why one would be interested in mixing panels from different screens when running the "single screen"? Besides that, when the 2 monitors setup is restored, panels need to be moved manually.
I don't know, it sounds weird and I got the feeling it is over engineering to solve a very particular use case.

Well, that's all for today, I'm sleepy, I can't even review this text, sorry in advance about any stupid thing written here.

Maybe better solution of this bug would be to switch the primary screen on the internal display after disconnecting the external monitor. 

Now it only moves all panels from disconnected monitor/screen to the connected but this will always mess up the panels !!! And even worse is that after reconnecting the external monitor back it forgets positions (original screens) of all panels and move them all to the external screen. 

If would you just switch the primary screen with its panels (I saw primary screen setting in the trunk version in monitor setting) to the remaining monitor it would be more expected behavior.
If the main screen will be on the internal monitor nothing will happen and it will behave like in kde4.4.
If the main screen will be on the external monitor it will jump on the remaining monitor with all panels and widgets.

Same thing happens on openSUSE 11.3 just updated to 4.5. In 4.4 ir worked fine.

I just don't get one thing, why at all panel is going to be moved, if the screen is gone? The best solution, i think, is just to leave them as they where. If the screen with panel is removed, there is no need to change anything, panel disappears, and , even more importantly, next time external display is connected, it is placed, where it should be :)Same thing happens on openSUSE 11.3 just updated to 4.5. In 4.4 ir worked fine.

I just don't get one thing, why at all panel is going to be moved, if the screen is gone? The best solution, i think, is just to leave them as they where. If the screen with panel is removed, there is no need to change anything, panel disappears, and , even more importantly, next time external display is connected, it is placed, where it should be :)

(In reply to comment #25)
> I just don't get one thing, why at all panel is going to be moved, if the
> screen is gone? The best solution, i think, is just to leave them as they
> where. If the screen with panel is removed, there is no need to change
> anything, panel disappears, and , even more importantly, next time external
> display is connected, it is placed, where it should be :)

I agree with you. That's the way it used to work in 4.4.

It seems there are 2 groups of users with different opinions about what should happen when an extra screen is removed. As the group who prefer the current scenario (post 4.5) won't either read or post opinions in this bug report, I think we should discuss this issue in a more visible place (reviewboard? kde forum? mailing list?).

Exactly, one group get used to the behavior in KDE4.4, it wasn't bad but you needed to have panel with all widgets (tasks, system, clock, ..) on both screens. 
And then there is second group used to "Windows behavior" => one panel always on the current main screen (this is the only way how it works now). 
As I wrote in my previous comment, I believe that the correct way is let user choose the "main screen" and this screen will switch on the internal screen after disconnecting (with all its panels). When the external screen will be reconnected it should return back to the previous state !!, not like now when it forgets positions (original screens) of all panels.

I also agree and this bug/feature is the only thing that stops me from upgrading to KDE 4.5. 
As a solution, is it not possible to have a setting somewhere for user to select whether they want the old functionality or the new?

(In reply to comment #27)
> Exactly, one group get used to the behavior in KDE4.4, it wasn't bad but you
> needed to have panel with all widgets (tasks, system, clock, ..) on both
> screens.

Not necessarily, I had one panel with a specific set of plasmoids on the main screen (the notebook's screen) and another set of plasmoids on the monitor screen. As the extra monitor was present only in the office, the panel had plasmoids useful during my workday.

(In reply to comment #28)
> As a solution, is it not possible to have a setting somewhere for user to
> select whether they want the old functionality or the new?

Maybe... yet another setting, but in this case I don't see another alternative.

"I just don't get one thing, why at all panel is going to be moved, if the
screen is gone?"

because it is (apparently) unexpected that panels are no longer accessible just because a screen is removed. we received numerous bug reports about this. it is compounded by the fact that some (rather common) x.org drivers rearrange the screen numbering when screens are added (and not symmetrically to how the numbering is handled when the screen is removed).

"As a solution, is it not possible to have a setting somewhere for user to
select whether they want the old functionality or the new?"

that's not a solution, that's a workaround.

SVN commit 1170103 by aseigo:

give panels a chance to initialize before checking them over for screen, etc.
CCBUG:241332


 M  +20 -8     plasmaapp.cpp  
 M  +6 -1      plasmaapp.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1170103

r1170105 also applies to this report.

SVN commit 1170125 by aseigo:

migrate back to screens when they re-appear
CCBUG:241332


 M  +25 -0     panelview.cpp  
 M  +3 -0      panelview.h  
 M  +9 -2      plasmaapp.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1170125

hopefully with those last three commits things should be working better; i need someone with kdebase/workspace/plasma/desktop/shell/ from trunk to test and confirm. if all is good, i'll backport the changes.

Aaron, I running trunk, I can test your changes tonight.

If anybody else can test it before, no problem =)

Tests done and it seems to work here =)

The only wrong thing I noticed is that if I put a panel on the second screen, after this screen removal an area equivalent to that panel appears in the first screen - looks like a transparent panel. Plasmoids and windows are covered by this area, but the panel itself is not there.

I can confirm comment #36, when external monitor is disconnected the windows can't be moved to area of panels that moved out from the screen (primary screen moved to the internal monitor, works nice). And when the external monitor is reconnected on the primary screen (that moved back to the external monitor) appears area in shape of panel from secondary screen where the windows cropped.

Snapshot of primary screen after disconnecting the external monitor:
http://yfrog.com/ne1screenp

Snapshot of both screens after reconnecting the external monitor, (primary is the right):
http://yfrog.com/nb2screensj

@Anselmo: "The only wrong thing I noticed is that if I put a panel on the second screen,
after this screen removal an area equivalent to that panel appears in the first
screen - looks like a transparent panel. Plasmoids and windows are covered by
this area, but the panel itself is not there."

can you click in that area? e.g. if you put a window in this area, does it receive clicks? can you attach a screenshot? thanks :)

@Michal: "when the external monitor is reconnected on the primary screen (that moved back to the external monitor) appears area in shape of panel from secondary screen where the windows cropped."

that looks like a graphics driver and/or a kwin compositing (if it happens when desktop effects are on) bug, but it might not be. can you answer the same questions i asked Anselmo above? thanks ...

SVN commit 1170446 by aseigo:

backport fixes for:
CCBUG:241332


 M  +25 -0     panelview.cpp  
 M  +3 -0      panelview.h  
 M  +30 -11    plasmaapp.cpp  
 M  +6 -1      plasmaapp.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1170446

Created attachment 51158 [details]
screenshot showing empty area

(In reply to comment #38) 
> can you click in that area? e.g. if you put a window in this area, does it
> receive clicks? can you attach a screenshot? thanks :)

Windows in this area don't receive clicks, however I can open the desktop context menu with a right mouse button click there.

In the attachment you can see that part of the left panel is covered by the area, the top of dolphin window as well. KRunner and the batery plasmoid are not covered.

(In reply to comment #38)
> that looks like a graphics driver and/or a kwin compositing (if it happens when
> desktop effects are on) bug, but it might not be. can you answer the same
> questions i asked Anselmo above? thanks ...

With compositing on it is still the same. It behaves exactly as Anselmo wrote. 

@Anselmo: Do you get the same problem if you reconnect the external screen back ? Can you try configuration of panels like in the snapshot http://yfrog.com/nb2screensj ?

(In reply to comment #41)
> @Anselmo: Do you get the same problem if you reconnect the external screen back
> ?

Yes, if I reconnect the external screen the empty area remains in the first screen - I have to remove the panel to fix the first screen.

Can you try configuration of panels like in the snapshot
> http://yfrog.com/nb2screensj ?

I tested this configuration, the problem happens only if the the external screen is the one with the panel placed on the top.

After that, I made another tests and found that the problem *does not happen* if the 2nd screen panel is on the bottom. However, the issue reappears when this panel is in any other position (top, left, right).

Also, I can't reproduce this behavior when both screen's panels are placed at the same position (top x top, bottom x bottom, right x right, left x left)

*** This bug has been marked as a duplicate of bug 259183 ***