Review Request 118094: Sort screens in plasma from left to right

Mon May 12 15:36:05 UTC 2014

> On May 12, 2014, 1:04 p.m., Aleix Pol Gonzalez wrote:
> > That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about.
> > 
> > As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now. Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens.
> >
> 
> Martin Klapetek wrote:
>     > That's not correct. Primary, at least, needs to have special treatment and get the 0-named containment assigned always, which is what the current naming is about.
>     
>     Why?
>     
>     > As for the rest of the screens it's probably best to sort them rather than keeping them as they come like now.
>     
>     They are sorted from left to right...or what sorting you have in mind?
>     
>     > Furthermore, you'll want also to insert the new screens in the correct position then, and shift the rest of the screens.
>     
>     Yes.
> 
> Aleix Pol Gonzalez wrote:
>     Because if the user has set up his first containment with all panels, we expect him to have it in the screen he explicitly said it's the primary one.
>     This way he'll be able to put the most attention to the screen he selected and get the notifications, the task manager and whatnot. Assuming all this goes to the left-most screen and disregarding the primary setting is not acceptable, considering the current design.
> 
> Martin Gräßlin wrote:
>     does that need to be 0-based for that? It sounds like two orthogonal things. One is to have a sane ordering by going e.g. left to right, the other is honoring the primary screen for placing the main containment.
> 
> Aleix Pol Gonzalez wrote:
>     Well, what do you think this number is for?
> 
> Aleix Pol Gonzalez wrote:
>     Just re-read and realized my answer is not very helpful there.
>     
>     The internal Corona containment id is what we're sorting here and 0 refers to the first containment, 1 to the second and so forth. This way, when we restore, we match 0 with primary, 1 with the first reported one, and so forth.
>     
>     Having them sorted from left to right (or top to bottom) makes sense because it makes the behavior more predictable but the screen number doesn't indicate where the screen is placed.
> 
> Martin Gräßlin wrote:
>     that's up to us to decide. Numbering screens doesn't make sense (TM). So if we want to use numbering we should use something which makes sense. Ordering by left to right or by available outputs could make sense.
>     
>     My prefered solution were that all numbering get's removed and replaced by a useful metric such as output identifiers.
> 
> Martin Klapetek wrote:
>     As we also export the screen number to the plasmoids, it's useful if it actually corresponds with something the plasmoids can use, like QScreen (even if shit). 
>     
>     So I would propose to let screen numbers be just that - screen numbered in left-to-right order and then match containments with actual screen identifiers, either screen name (from edid) or the xrandr name like "DVI-D-0" and then match those. This actually guarantees things will stay consistent even if you change order of your screens and generally makes things more deterministic.
>     
>     I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run. In case user changes his primary output, I would switch the panel only if there is no other panel/configured stuff on the other screen, but I'm not so sure about this. But either way, even if we switch the screens, we just match the "primary" containment with the new screen identifier, so all will just work.
>     
>     I also volunteer to do all this of course.
> 
> Martin Gräßlin wrote:
>     sounds like a good proposal to me. What do you think Aleix?
> 
> Aleix Pol Gonzalez wrote:
>     Why do plasmoids need to know the order of the screens left-to-right? As far as I understand a plasmoid needs to have the tools to place things around it or even in the same screen, but how things are sorted is not responsible to the plasmoid but to the corona.
>     
>     "I would also propose to take the primary screen into account and make it the default desktop (where panels and notifications and whatnot get placed) after first run."
>     
>     So you just want to remove any multiscreen support in Plasma Shell and squeeze everything in the primary screen?
> 
> David Edmundson wrote:
>     Being ordered from left to right doesn't help anything.
>     
>     I have dual setup (primary is my fixed display)
>      - panels are on my primary
>     
>     I unplug
>      - laptop becomes primary and all my stuff moves there. Stuff on my secondary screen correctly disappears.
>     
>     I plug back in so a new screen[0] exists
>      - my panel is moved to the bigger screen
>      
>     If it was ordered left to right my panel would either end up on the leftmost screen or end up not being on my screen when I unplug.
>     
>     Using outputs won't help either for exactly the same reasons.
>     
>     What /might/ work is having what screen an applet/panel prefers to be on when in a given kscreen profile, but that's future stuff that we shouldn't be trying to do now.

> Why do plasmoids need to know the order of the screens left-to-right?

Because that's how QScreen puts screen and it's the only screen API available in QML at the moment. Otherwise I don't see any point for plasmoid.screen at all. Screen numbers (presumably) exists because of QScreen.

> So you just want to remove any multiscreen support in Plasma Shell and squeeze everything in the primary screen?

Not at all. Your primary screen should be where the panel appears when you first time ever boot plasma/if there's no other config present.

---
> Being ordered from left to right doesn't help anything.

The order is predictable and always stays the same. This solves the problem of fixed screens and plasma putting panels randomly on loading. Granted, it has other issues, but I haven't tried to solve those with this patch.

- Martin

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118094/#review57757
-----------------------------------------------------------

On May 12, 2014, 12:39 p.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118094/
> -----------------------------------------------------------
> 
> (Updated May 12, 2014, 12:39 p.m.)
> 
> 
> Review request for Plasma, Aleix Pol Gonzalez and Martin Gräßlin.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> Even though numbered outputs have their flaws, we still use them pretty much everywhere and everywhere we use outputs numbered from left to right, so let's use the same in Plasma.
> 
> This seems to fix most of my multiscreen issues now, namely bug 334500 and bug 334502.
> 
> Also:
> 
> <mgraesslin> I don't know - having primary as 0 is a bit strange
> <mgraesslin> 1, 2, 3, 0
> <mgraesslin> ?
> <mgraesslin> that was from left to right
> 
> 
> Diffs
> -----
> 
>   shell/shellcorona.cpp b0b139d 
> 
> Diff: https://git.reviewboard.kde.org/r/118094/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140512/3a475689/attachment-0001.html>