multi-screen management

[Jeremy Whiting]

On Wed, Aug 18, 2010 at 11:05 AM, Aaron J. Seigo <aseigo at kde.org> wrote:

> On Tuesday, August 17, 2010, Chani wrote:
> > so... we had planned to have a little tool for managing the containments
> of
> > multiple screens, in 4.5 - but there wasn't time. multiscreen has
> > improvements, but also regressions - well, *a* regression - you can't
> > access the containment of a screen that's not plugged in. the same
> applies
> > to the per-desktop view stuff (they have a lot in common).
>
> is there a list of use cases that must be serviced? your email has lots of
> "how to do X" in it, but it seems to skip the "why we want to do X".
>

The usecase I hit last week was that I usually use two screens, but pulled
one screen off my desktop to use for a separate machine for
longer-than-short-term.  Now my main desktop has one screen, with the panel
on it, but there's a separate containment that had some widgets I'd like to
remove or move to this screen.  I'm not sure if they are "running" or
whatever, but in the add widgets dialog there are checkboxes on widgets that
are not on this screen or my panel.


>
> > When a screen is disconnected (or in PDV, a desktop removed) the
> associated
> > containment and view (for each running activity) should be automatically
> > stopped - and resumed again when the screen/desktop returns. We can
> migrate
> > panels, but not desktops, and it doesn't make sense to leave something
> > running and inaccessible (having to manually stop it would also be
> Wrong).
>
> it does make sense to leave something running if one can switch to it,
> though.
> if the switcher UI allows the user to do that, then it's probably fine.
>

Umm, is there a glossary somewhere of plasma terms? I've no clue what PDV,
or such mean.


> > * I don't like how I ended up with two authorities on where a containment
> > belongs: there's both the lastScreen/lastDesktop settings in the
> > containment, and the place that running containment has in
> > plasma-desktop's Activity class. that ought to be rethought.
>
> they are two different kinds of issues, though, and are orthoganal to each
> ther. it may be possible to nicely merge the two, but they would still be
> two
> different sets of data and decisions.
>

I agree, lets tackle these one at a time and decide what to do with each.


>
> > * Might it be easier to leave the config in plasma-desktop-appletsrc, and
> > have the startup loading skip containments assigned to nonexistant
> > screens/desktops?
>
> possibly, yes..
>
> > * Once this is implemented, I believe panels should behave the same way,
> > instead of migrating. It's more consistent that way. thoughts?
>
> i think it will annoy the users who previously sent in bug reports about
> the
> panel not showing up on their laptop screen after being migrated to another
> screen.
>
> panel migration addresses a real world issue people run into regularly.
> there's a bug in it that i will try and track down (i actually finally
> ended
> up with hardware capable of replicating it with.. ), but otherwise i don't
> think much needs to be done with panels. they are already movable between
> screens.
>

thanks,
Jeremy



>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Development Frameworks
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100818/ff3f637a/attachment-0001.htm