<html><body><p><tt>"Plasma-devel" <plasma-devel-bounces@kde.org> wrote on 18.10.2016 13:11:29:<br><br>> From: Marco Martin <notmart@gmail.com></tt><br><tt>> To: plasma-devel@kde.org</tt><br><tt>> Date: 18.10.2016 13:11</tt><br><tt>> Subject: Re: Breakout: * multiscreen behaviour: how should Plasma <br>> exactly behave in different scenarios?</tt><br><tt>> Sent by: "Plasma-devel" <plasma-devel-bounces@kde.org></tt><br><tt>> <br>> On Tuesday 18 October 2016, David Edmundson wrote:<br>> > <br>> > With regards to current Plasma behaviour that's not always true: I didn't<br>> > mention if screen 2 was previously the primary screen or not.<br>> > <br>> > At which point the correct behaviour should be to show the containers that<br>> > were previously on screen 2 on screen 1. Right?<br>> <br>> yes, that's the one case where the views get swapped to the other screen<br>> in ShellCorona::primaryOutputChanged()<br></tt><br><br><tt>Hi all</tt><br><br><tt>I've been using KDE since about 15 years and I'm interested a lot</tt><br><tt>in the recent multiscreen improvements and the present discussion.</tt><br><tt>There is quite some complexity in changing multiscreen configs,</tt><br><tt>and I liked Marco Martin's summary of how Containments</tt><br><tt>(Desktop Containments or Panels) are linked to Screens etc.</tt><br><br><tt>Already with <= 2 screens (say, LVDS and one external screen scr1)</tt><br><tt>we can have 4 configurations (with * indicating the Primary Display),</tt><br><tt>namely</tt><br><br><tt> c1 = [*lvds]</tt><br><tt> c2 = [*lvds][scr1]</tt><br><tt> c3 = [lvds][*scr1]</tt><br><tt> c4 = [*scr1]</tt><br><br><tt>Based on the previous discussion, it seems that a Desktop Containment</tt><br><tt>D is configurable on a per-config and per-screen basis, so we have</tt><br><br><tt> D = D(c,s)</tt><br><br><tt>where c is a config in {c1,c2,c3,c4} and s is a screen in {lvds,scr1}.</tt><br><tt>Moreover, a Panel P is apparently configurable on a per-config, per-screen</tt><br><tt>and per-resolution basis, so we have</tt><br><br><tt> P = P(c,s,r,n)</tt><br><br><tt>where c and s are as above, r is a resolution, and n would be a panel index</tt><br><tt>(as there can be multiple panels per screen).</tt><br><br><tt>Using the above definitions and assumptions, we can ask a couple</tt><br><tt>of questions:</tt><br><br><tt>Q1. Among the possible transitions </tt><br><tt> - , c1 -> c2, c1 -> c3, c1 -> c4</tt><br><tt> c2 -> c1, - , c2 -> c3, c2 -> c4</tt><br><tt> c3 -> c1, c3 -> c2, - , c3 -> c4</tt><br><tt> c4 -> c1, c4 -> c2, c4 -> c3, -</tt><br><br><tt>from initial to final config, which ones are actually implemented</tt><br><tt>as atomic transactions in kscreen control? -- I'm asking because</tt><br><tt>for example the transition c1 -> c3 could be implemented</tt><br><tt>atomically as</tt><br><tt> [*lvds] -> [lvds][*scr1]</tt><br><br><tt>or in two steps as</tt><br><tt> [*lvds] -> [*lvds][scr1]</tt><br><tt> [*lvds][scr1] -> [lvds][*scr1]</tt><br><tt>with possibly different outcomes.</tt><br><br><br><tt>Q2. Marco stated that containments never migrate from one screen</tt><br><tt>to another except when there is a "change of the primary screen".</tt><br><tt>But which config changes actually qualify as "change of the primary screen"?</tt><br><tt>I'd say</tt><br><tt> [*lvds][scr1] -> [lvds][*scr1]</tt><br><tt>is such a change, but how about</tt><br><tt> [*lvds] -> [lvds][*scr1]</tt><br><tt>?</tt><br><br><br><tt>Q3. If I understand correctly, a "change of the primary screen"</tt><br><tt>causes ShellCorona::primaryOutputChanged() to swap containments</tt><br><tt>between the old primary screen and the new primary screen,</tt><br><tt>so is it true that a config change</tt><br><br><tt> c1 = [*lvds][scr1] -> c3 = [lvds][*scr1]</tt><br><br><tt>will always result in the swap operations</tt><br><tt> D(c3,scr1) := D(c1,lvds)</tt><br><tt> P(c3,scr1,r,n) := P(c1,lvds,r,n)</tt><br><tt> D(c3,lvds) := D(c1,scr1)</tt><br><tt> P(c3,lvds,r,n) := P(c1,scr1,r,n)</tt><br><br><tt>regardless of whether c3 is created for the first time</tt><br><tt>or recreated some time later?</tt><br><br><br><tt>Q4. For another example, if we consider the direct (atomic) transition</tt><br><tt> c1 = [*lvds] -> c3 = [lvds][*scr1]</tt><br><tt>is this also handled by ShellCorona::primaryOutputChanged() ?</tt><br><tt>Does it cause any containments to be migrated to another screen?</tt><br><tt>(If not, one might end up with c3 having no panel</tt><br><tt> the first time it gets created).</tt><br><br><br><tt>Thanks and regards,</tt><br><tt><br>---</tt><br><tt>Fredy Neeser<br>IBM Zurich Research Laboratory<br></tt><BR>
</body></html>