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

[Fredy Neeser]

"Plasma-devel" <plasma-devel-bounces at kde.org> wrote on 18.10.2016 13:11:29:

> From: Marco Martin <notmart at gmail.com>
> To: plasma-devel at kde.org
> Date: 18.10.2016 13:11
> Subject: Re: Breakout: * multiscreen behaviour: how should Plasma
> exactly behave in different scenarios?
> Sent by: "Plasma-devel" <plasma-devel-bounces at kde.org>
>
> On Tuesday 18 October 2016, David Edmundson wrote:
> >
> > With regards to current Plasma behaviour that's not always true: I
didn't
> > mention if screen 2 was previously the primary screen or not.
> >
> > At which point the correct behaviour should be to show the containers
that
> > were previously on screen 2 on screen 1. Right?
>
> yes, that's the one case where the views get swapped to the other screen
> in ShellCorona::primaryOutputChanged()


Hi all

I've been using KDE since about 15 years and I'm interested a lot
in the recent multiscreen improvements and the present discussion.
There is quite some complexity in changing multiscreen configs,
and I liked Marco Martin's summary of how Containments
(Desktop Containments or Panels) are linked to Screens etc.

Already with <= 2 screens (say, LVDS and one external screen scr1)
we can have 4 configurations (with * indicating the Primary Display),
namely

  c1 = [*lvds]
  c2 = [*lvds][scr1]
  c3 = [lvds][*scr1]
  c4 = [*scr1]

Based on the previous discussion, it seems that a Desktop Containment
D is configurable on a per-config and per-screen basis, so we have

  D = D(c,s)

where c is a config in {c1,c2,c3,c4} and s is a screen in {lvds,scr1}.
Moreover, a Panel P is apparently configurable on a per-config, per-screen
and per-resolution basis, so we have

  P = P(c,s,r,n)

where c and s are as above, r is a resolution, and n would be a panel index
(as there can be multiple panels per screen).

Using the above definitions and assumptions, we can ask a couple
of questions:

Q1. Among the possible transitions
       -    , c1 -> c2, c1 -> c3, c1 -> c4
    c2 -> c1,    -    , c2 -> c3, c2 -> c4
    c3 -> c1, c3 -> c2,    -    , c3 -> c4
    c4 -> c1, c4 -> c2, c4 -> c3,    -

from initial to final config, which ones are actually implemented
as atomic transactions in kscreen control?  -- I'm asking because
for example the transition  c1 -> c3 could be implemented
atomically as
    [*lvds] -> [lvds][*scr1]

or in two steps as
    [*lvds]       -> [*lvds][scr1]
    [*lvds][scr1] -> [lvds][*scr1]
with possibly different outcomes.


Q2. Marco stated that containments never migrate from one screen
to another except when there is a "change of the primary screen".
But which config changes actually qualify as "change of the primary
screen"?
I'd say
    [*lvds][scr1] -> [lvds][*scr1]
is such a change, but how about
    [*lvds] -> [lvds][*scr1]
?


Q3.  If I understand correctly, a "change of the primary screen"
causes ShellCorona::primaryOutputChanged() to swap containments
between the old primary screen and the new primary screen,
so is it true that a config change

  c1 = [*lvds][scr1] -> c3 = [lvds][*scr1]

will always result in the swap operations
  D(c3,scr1)     := D(c1,lvds)
  P(c3,scr1,r,n) := P(c1,lvds,r,n)
  D(c3,lvds)     := D(c1,scr1)
  P(c3,lvds,r,n) := P(c1,scr1,r,n)

regardless of whether c3 is created for the first time
or recreated some time later?


Q4.  For another example, if we consider the direct (atomic) transition
  c1 = [*lvds] -> c3 = [lvds][*scr1]
is this also handled by ShellCorona::primaryOutputChanged() ?
Does it cause any containments to be migrated to another screen?
(If not, one might end up with c3 having no panel
 the first time it gets created).


Thanks and regards,

---
Fredy Neeser
IBM Zurich Research Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20161018/f787a41b/attachment.html>