Breakout: * multiscreen behaviour: how should Plasma exactly behave in different scenarios?

[Marco Martin]

On Monday 17 October 2016, Jonathan Riddell wrote:
>     <d_ed> biggest pain point from bugzilla is mostly still
> multiscreen. I'm not sure we have a solid plan of what /should/ happen
> in each situation.

there are now 18 bugs marked as multiscreen, which a good part of them i'm 
almost sure they should be fixed by 5.8.1/5.8.2, waiting for confirmation on 
them tough

>     <d_ed> panel gets added to screen 1 and 2, you disconnect screen
> 2. How many panels do you have on screen 1

on screen 1 you should have the panel you added on screen 1, nothing of what 
you added on the screen 2

>     <Sho_> btw, this is meta, but I feel the amount of feedback we get
> on multiscreen is really telling about our audience - many people who
> use KDE have multiple screens it seems, and only certain kinds of
> people and usage scenarios involve multiple screens (enthusiast home
> users, office professionals ..)
>     <Markus_KMi_[m]> Multiscreen is also connecting to a projector for
> a movie, not only multiple displazs on the desk
>     <Fuchs> d_ed: multiscreen on sddm on X11 is something I reported,
> it doesn't work terribly well as in: you get overlapping sddms if you
> have overlapping screens etc.

this is what is supposed to happen in plasmashell 5.8 right now (and in tests 
so far right now it happens, if not, s a bug):

* the way in which screen are identified is connector names, is the most 
unique way to identify whatever is connected to a particular port (that may 
change a lot of times, while the connector doesn't)
* every desktop containment is linked to a particular screen and stays forever 
with it, exept a single case [1]
* every panel  is linked to a particular screen and stays forever with it, 
exept a single case [1]
* so every screen has a set of panels and a desktop that are forever linked 
with each oter
* when you remove a screen, its desktop/panels must become unreachable (and 
their views destroyed), panels are *not* moved to the visible screens (if it 
happens in 5.8, please show me how to reproduce, because would be a bug)
* when you add a screen there may be 2 cases:
a) it's the first time, so create a new desktop containment for it, and no 
panels
b) if it's not the first time, restore whatever was created for it in the 
past, the desktop and any eventual panels, in the exact same positions (panel 
geometries as usual have a config per screen resolution, so if you go from an 
high resolution screen to a low resolution projector they are managed 
separatedly, so one doesn't screw with the other too much)

[1] now, the one and only case when the association connector-
>containment/panels set changes: change of the primary screen.
* when you change the primary screen, the containment/panels set gets swapped 
between the new primary screen and the one that used to be the primary screen: 
that seems the behavior that was expected by users
*slightly special case, when the system is configured to have one and only 
enabled primary screen and in the same transaction the old one is disabled and 
the new one enabled, in that case all the existing views are simply moved on 
the new screen (this happens when laptop users configure only the external 
monitor enabled upon connection with the internal display automatically 
reenabling when pulling the cable, quite popular setup and works surprisingly 
well after 5.8.1)

-- 
Marco Martin