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

[Martin Gräßlin]

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

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


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