Bug 334502 - Panel positions in multiscreen are not remembered/placed depending on mouse position
Summary: Panel positions in multiscreen are not remembered/placed depending on mouse p...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: generic-multiscreen (show other bugs)
Version: master
Platform: unspecified Linux
: NOR normal
Target Milestone: 1.0
Assignee: Aleix Pol
URL:
Keywords:
Depends on:
Blocks: 328593
  Show dependency treegraph
 
Reported: 2014-05-08 09:36 UTC by Martin Klapetek
Modified: 2014-05-14 15:29 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Klapetek 2014-05-08 09:36:25 UTC
When plasma is starting, it places the containments based on mouse position. 

I have two screen setup - screen1 has panel, screen2 does not. If I end plasma-shell, put mouse over screen2 and restart plasma-shell, screen1 now has what screen2 had (background etc) and screen2 now has the panel and stuff screen1 had before.

The containment locations should be remembered and restored properly.
Comment 1 Aleix Pol 2014-05-08 13:41:54 UTC
Git commit 2052b811403e52bb80d1abdaf87f91ae257e0e9c by Aleix Pol.
Committed on 08/05/2014 at 13:38.
Pushed by apol into branch 'master'.

Remove hack for early initialization of PanelView

This broke screenForContainment because the Panel didn't know where it
would be placed when the panel is being set. This shouldn't be the case
anymore.
Related: bug 334500

M  +3    -22   shell/panelview.cpp
M  +1    -1    shell/panelview.h
M  +4    -3    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/2052b811403e52bb80d1abdaf87f91ae257e0e9c
Comment 2 Aleix Pol 2014-05-08 14:03:49 UTC
I cannot reproduce it here, maybe that commit fixed the problem? Actually it already worked properly before...

Anyway, can you try again maybe?
Comment 3 Martin Klapetek 2014-05-08 15:03:48 UTC
Yup, seems fixed now.
Comment 4 Martin Klapetek 2014-05-09 14:20:15 UTC
After more testing, it's doesn't seem to be fixed yet :/

Here's a video: https://dl.dropboxusercontent.com/u/6761102/plasma_multiscreen.mkv

It shows that the desktops are switching moreless randomly between screens.
Comment 5 Aleix Pol 2014-05-12 11:07:51 UTC
Is this with a set primary screen? You can check this by running "xrandr -q" and seeing whether you have a line such as:
"LVDS1 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm"
Note the "primary" part.
Comment 6 Martin Klapetek 2014-05-12 11:11:22 UTC
No, I don't have primary screen set. Things should still work though, Plasma should simply remember which screen I put the panel on, not switch randomly.
Comment 7 Aleix Pol 2014-05-12 11:23:50 UTC
That's just not how X11/XRandr works.

The only id we're storing for the moment is a numeric id and we'll restore these on every screens set the system is set on.

We can design a new approach to the problem, but that definitely requires a bigger discussion. For the moment, you should be defining your xrandr settings properly, e.g. with KScreen (which I ported to KF5 last week, BTW).
Comment 8 Martin Klapetek 2014-05-12 11:28:09 UTC
The bug itself remains valid, regardless of what we're currently doing or not.

If I have three screens, one primary and two non-primary, the panels will switch randomly there and that's a bug. Panels and shells should stay on the screen I put them on, regardless of my xrandr setting. Having things switching randomly is unacceptable.
Comment 9 Martin Klapetek 2014-05-12 14:01:22 UTC
Additional note: the RandR spec (including xrandr) does *explicitly* allow a configuration with no primary screen (there's xrandr --noprimary for that). 

KScreen also actually honors that by allowing to unselect the primary screen in the KCM. 

Finally, this is the system default configuration (I've never touched it since I've installed it).

Having a setup with no primary screen is very valid and should be properly supported.
Comment 10 Aleix Pol 2014-05-12 14:20:29 UTC
Agreed, your patch that sorts from left to right fixes it. Let's get it rocking, once it honors primary screen and it keeps inserting screens in the correct place.
Comment 11 Aleix Pol 2014-05-13 15:07:17 UTC
Git commit b37948000e3844b85862a3b728447048d36d113f by Aleix Pol.
Committed on 13/05/2014 at 15:04.
Pushed by apol into branch 'master'.

Improve predictability of plasma-shell screen id's

So far we were just enforcing that 0 would be the primary screen. After
this change we will make sure that the rest are layed out horizontally and
then vertically if there's a 2 at the same position.
If a new screen is connected, we'll try to put it in the correct position
following the described situation.

M  +36   -44   shell/shellcorona.cpp
M  +1    -0    shell/shellcorona.h

http://commits.kde.org/plasma-workspace/b37948000e3844b85862a3b728447048d36d113f
Comment 12 Martin Klapetek 2014-05-14 12:45:59 UTC
Unfortunately this is still not fixed, containments still get placed at random during plasma loading.

Here's a video with all code built 10 minutes ago: https://dl.dropboxusercontent.com/u/6761102/screencast-9.mkv

Also Marco reports that the containments are always placed to the opposite screen than they were before.
Comment 13 Aleix Pol 2014-05-14 15:29:05 UTC
Git commit 9f9ba633c1f0525a62fa82e53ec0b68043d91277 by Aleix Pol.
Committed on 14/05/2014 at 15:28.
Pushed by apol into branch 'master'.

Improve how the primary screens are sorted

Only take it into account if the primary value is different in both screens

M  +2    -1    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/9f9ba633c1f0525a62fa82e53ec0b68043d91277