multi-screen management

[Marco Martin]

On Wednesday 18 August 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).
> 
> anyways, jpwhiting said he might be willing to implement such a tool, and
> yesterday I was inspired (compelled?) and found myself writing about how
> such a tool may look and act: http://community.kde.org/Plasma/Multiscreen
> 
> feedback would be very welcome. :) and since I know many of us hate
> clicking links, here's the current text copy&pasted:
> 
> Plasma/Multiscreen
> 
> With the death of the ZUI, managing multiple screens (or per-desktop views)
> becomes... a little trickier. A UI for managing the containments ("widget
> groups" in user-speak?) is needed.

needed -when- the activity manager isn't enough, but still reachable from 
there i think
 
> I have a few ideas here, and would like feedback.
> 
> The general concept I've got is a grid of containments, with screens left
> to right and (if PVD was ever enabled) desktops going top to bottom. If
> panels are to be managed here too, they could be along the edges of the
> cells. Only the current activity's containments would be used (no
> hypercubes plskthx). There would be a visible difference between the
> rectangle of active views and the inactive 'outside' ones. Containments
> could be dragged to other cells (causing a swap with the containment
> they're dropped on) and ones outside the active area could be deleted.
> Desktop containments would not be draggable to empty cells, because that
> could leave a view without a containment (panels, on the other hand, might
> have less restrictions).
> 
> Usual case mockup http://chani.ca/images/screenmanager-bestcase.png
> Bad case mockup (it could be worse...)
> http://chani.ca/images/screenmanager-worstcase.png
> 
> The UI ought to be something a user only needs occasionally, but it should
> still be easy to use.
> 
> I considered doing just screens or just desktops, and trying to follow the
> geometry those are displayed in in other places (pager, krandr) but when
> you consider there will likely be leftover containments from old screenns
> and desktops that gets awkward.
thinking a bit about about the ui i think it should be:
* display a single activity at a time

*it should try to follow that geometry if possible

- for monitors should be a grid, line or whatever is configured of the active 
screens, the inactive ones could be in a line slightly separed with the active 
ones
- each monitor box tries to represent directly a containment, if there are 
containments assigned to oter desktops, they will have a layout representing 
the pager, also here with a second line of ones that are assigned to a desktop 
> the total number

*all things should be reordered by drag and drop

> On the other hand, if there are both panels and PVD, that's also awkward:
> would users understand that even if panels only appeared and were draggable
> within the first row, that they still show up on all desktops? perhaps
> panels could have their own special row in that case..?
> 
> Another tricky issue: how to represent the containments? If someone can get
> thumbnails of containments working properly I will give them lots of beer
> and hugs. :) Im the meantime... well, a grid of identical icons isn't very
> useful. there probably ought to be something thing-like for the
> dragging... I'm not sure how much trouble the user will have remembering
> which containment they left where. if fact, if they drag one icon to
> another identical icon, what is there to tell them the two containments
> were swapped at all?
> 
> I think that, assuming there are no thumbnails, live previews will be
> important. The user will end up dragging an inactive containment to their
> current screen/desktop just to remind themselves what containment it was.
> If they have to hit apply every time that could get rather tedious.

uhm, so actual qgraphicsviews? this assumes all containments are running

> On the other hand, it might be good to keep in mind that the *normal* case
> is for a user to have PDV off, disconnect their one external monitor, and
> then want to go check on a widget it had - or swap its containment over to
> the remaining screen if they don't like which one their driver thinks
> belongs there.
> 
> The (hopefully) less common, icky case is someone who has multiple screens
> and lots of desktops, then turned on PVD and wants to purge all the old
> containments (even though they ideally would be mere config data, not
> actually *running*).
> 
> Oh, and as for where to go to open this UI: well, it has to run in-process,
> but it's not common enough to warrant a toolbox entry, so I had a crazy
> idea: what if whatever kcm is relevant to this stuff (plasma settings +
> wherever the PDV setting lives?) had a button that sent a dbus signal to
> plasma-desktop to show the UI?

i think should be reachable from the activity manager (either right click, 
another action icon, whatever)

> TODO: clean up the above rambling into a more structured document. :)
> 
> [edit]Under the Hood
> 
> The UI would have to talk to plasma-desktop's current Activity (you can get
> them via DesktopCorona), to ensure that the containment swaps happen
> smoothly. Also because one or both containments involved may not be
> running, once that stuff's implemented, so swapContainment might not be
> doable at all :)
> 
> [edit]Inactive Screens
> 
> 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).

agree (i'm still not very happy of the current panel migration thing)

> * When implementing this, be careful to check how it interacts with
> stopping and starting activities. it'd suck to lose containments.
> * 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.

uhm, i think the authority shuld just be corona, but in case of plasma-desktop 
corona use the Activity to make the decision...

> * Might it be easier to leave the config in plasma-desktop-appletsrc, and
> have the startup loading skip containments assigned to nonexistant
> screens/desktops?

in the end, where you have the configuration is the same thing, depends if 
it's ever wanted having running containments not associated with screens.
the exceptions are the mobile and netbook launchers, but they could have -1 
(instead of a number > than available screens)

> * Once this is implemented, I believe panels should behave the same way,
> instead of migrating. It's more consistent that way. thoughts?

agree

> * It'd be nice to investigate whether any delay would be helpful - is it
> likely for several screen changes to happen within a few seconds? either
> from drivers being fidgety or from a loose cable or something? I don't
> know enough to be sure.

yes, two things likely to happen

heers,
Marco Martin