multi-screen management

[Chani]

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

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.

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

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

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

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

heck, I suppose a parallel solution to the desktop side of it would be to 
migrate its *widgets* to the other screen... but undoing that when the screen 
returned could be tricky :)