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

[Martin Klapetek]

> 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.

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


-----------------------------------------------------------
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/2745eafe/attachment.html>