multi-screen management

[Aaron J. Seigo]

On Wednesday, August 18, 2010, Chani wrote:
> On August 18, 2010 10:05:22 Aaron J. Seigo 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".
> 
> somewhere in there I had something not entirely unlike use cases... ;)
> 
> 1) user unplugs their external monitor and takes their laptop home. at home
> they remember there was a note on the other monitor that they need to read,
> so they open up the manager tool, swap the containments, read the note,
> then swap back.
> 
> 2) user wants their laptop screen's containment to stay where it is, but
> something in the multiscreen stack keeps telling plasma to move it to the
> external monitor. user uses this tool to swap containments every time they
> connect or disconnect the screen [how realistic is this?]

unfortunately, rather realistic *sigh*

ok .. so given that these are use cases ... how about this as an idea:

in the Activity Manager panel, if there is more than one containment in the 
current activity, it is shown expanded with a snapshot of each containment. 
so, in a two screen system, the current activity would be represented by two 
screenshots next to each other instead of the one icon. click on one or the 
other would switch the current screen to be using that containment.

this doesn't touch the "bring that containment from Activity 1 over to 
Activity 3" issue, but that seems like more of an edge case, one that is 
harder to solve nicely and which probably requires a whole big "arrange stuff 
around" tool like in your proposal.

if we just try and solve the above 2 use cases, though, we could perhaps do it 
right from inside the existing activity manager UI. thoughts?

> 3) user tried out the PDV feature, but didn't like it and turned it off.
> now their system is slow, and someone on irc tells them it's because all
> those other desktops are still running. they use the tool to delete all
> those extra containments that aren't being used.

should turning off PDV just automatically remove all those other containments, 
or offer the option to do so when it is turned off? "Per-desktop views have 
been turned off and there are now several unused widget layouts. Would you 
like them to be removed automatically for you? This can result in a 
significant performance improvements. <Remove Unused Layouts> <Keep The Unused 
Layouts>"

> > > 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.
> 
> except that I'm not sure how many users will realise they might have stuff
> running still and check this tool. they'll just think their system got
> slower because it's "bloated" or something :P
> 
> me, I plug in an external monitor (actually a tv) a couple of times a week
> to watch movies. I don't want the containment for it running for the rest
> of the week, and I don't really want to manually delete or close it every
> time. and the multiscreen tool would then need a feature to manually close
> things instead of deleting them, too.

how much weight (start up time, memory usage) does this use case incur right 
now? wallpapers on loaded on first-paint only, if there are no widgets then 
none are loaded or set up ... it might be very negligable and not work 
worrying about.

> > > * 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.
> 
> ?
> what two kinds of issues?

0) physical screen availability
1) which is the current Activity.

> the way I see it, it's a bit of awkward design that has led to bugs, and
> may well lead to more bugs if it's not cleaned up before this multiscreen
> stuff is implemented.

yes, as i said i think it could be centralized into one place (limiting 
interaction-between-implementations-spread-out-across-the-code-base related 
bugs) ... but it's still two sets of decisions and data to track.

> > > * 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.
> 
> true. it'll annoy *some* group either way, I think.

it's annoying to get your panel back if there is room for it on the remaining 
screen(s)?

> > 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.
> 
> yeah, it's just that we've now got two different ways of addressing the
> issue of a screen going away :)

for two rather different kinds of elements: the singular item that is stuck to 
the "background" of each screen, and the zero-or-more items that hang out on 
the edges of screens. i don't see enough similarity in form or function to get 
even close to 100% similarity in handling. :/

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100818/9cae7e97/attachment-0001.sig