multi-screen management

[Chani]

On August 18, 2010 13:24:43 Aaron J. Seigo wrote:
> 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.

for screens, and assuming you make snapshots work, that might be feasible...
but, what if the user has PVD and 6 VDs? :/ (at least VDs can always be re-
added after they're removed)
and where would you put the delete button? how would you keep it clearly 
separate from the "stop/delete this activity" button?

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

well, my proposal doesn't even address moving anything between activities. 
desktops and screens are two dimensions, I didn't want to add a third.

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

hmm... yes, assuming the annoying-popup factor is minimized this is a good 
idea :)
hopefully users will be smart enough to realise that the 'unused' ones are all 
except the one from deskop #1.

> 
> > > > 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 ought to check again. I know that in january, loading 8 activities took 
something like.. 20-30 seconds..? for every plasma-desktop restart. it was a 
very noticeable loading time.

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

uhm... I was never talking about the current activity. o.0
I was talking about the activity keeping track of which of its containments 
belong on which screen/desktop.

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

*shrug* having not experienced it, I guess I'll leave panels alone :)

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

k.