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

sounds like a good proposal to me. What do you think Aleix?


- 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