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

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to