multi-screen management

[Chani]

On August 18, 2010 20:05:00 Aaron J. Seigo wrote:
> On Wednesday, August 18, 2010, Chani wrote:
> > 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:
> > > 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,
> 
> for running containments, it turns out that its not a big deal.

:)

> 
> > 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)
> 
> have i mentioned recently how much i regret PVD? :)

hehe :)
we *might* have had a window to kill it in 4.5 when activities came in... 
but... oh well.
this feature is more important for screens than VDs, though: you can be 
physically unable to get a screen back, but you can always re-add a VD.
so maaaybe we could ignore VDs there and implement the offer to purge them you 
mentioned below?

> 
> i don't have a good answer for this one right now; maybe we just show the
> screens currently visible, so when you switch desktop the snapshots show
> that desktop's contents?

yes, if we "ignore" VDs we should still remember to update the snapshots.

> 
> > and where would you put the delete button? how would you keep it clearly
> > separate from the "stop/delete this activity" button?
> 
> don't need to; it would only be for the current activity and that has no
> buttons on it :)

actually, it does have a button atm.
and hopefully it'll get some sort of edit button in 4.6 so that we can drag 
the activity-name setting out of the containment config (somuchtodo!)

and, er, hmm. right, it makes sense to do it for only the current one. so the 
current activity would be rendered completely differently from the others? 
iinteresting. I wonder how the activity manager will look then...
/me still wishes they were sorted by most-recent instead of by creation-order.

> 
> > > 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 :)
> 
> it should only happen when the setting is turned off; which should be a
> rare occurance.
> 
> > hopefully users will be smart enough to realise that the 'unused' ones
> > are all except the one from deskop #1.
> 
> we can explain it in the text, perhaps even include a little helpful
> picture.

:)

> 
> > > > 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.
> 
> in the use case you noted, it's one extra containment, and it shouldn't
> even be loading its wallpaper. i also assume there aren't any widgets on
> it since it's a temporary thing in the described work flow.

one extra containment per activity that has been used while that screen was 
plugged in.
in *my* workflow it has no widgets... hm. yeah, I guess most of them will have 
no widgets.
well, I'll try and find time to test it while I still have access to the TV :)
er, how do I measure memory usage anyways? all I remember is Don't Use Top. ;)

> 
> > > > > > * 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.
> 
> right; but that doesn't really have anything to do with the activity, per
> se.

it does, that's the problem. :)

> 
> an activity has containments.
> a containment has a screen (and possible a virtual desktop) affinity.

an Activity instance (the class in plasma-desktop) has its own idea of which 
containments belong where, which is important when activating and closing the 
activity. If something has changed without it knowing (say, two of its 
containments switching places), it may clobber those changes and/or create 
extra containments to fill imaginary holes.

I suppose it really ought to listen to the screenChanged (sp?) signal from the 
containments it thinks it owns, or something. although it still might manage 
to do the wrong thing. the code needs cleaning up.