multi-screen management

[Chani]

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. 
Contents
[hide]
1 Manager Tool 
1.1 UI
1.2 Under the Hood
2 Inactive Screens
  [edit]Manager Tool
[edit]UI

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. 

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. 

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? 

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). 
* 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. 
* Might it be easier to leave the config in plasma-desktop-appletsrc, and have 
the startup loading skip containments assigned to nonexistant 
screens/desktops? 
* Once this is implemented, I believe panels should behave the same way, 
instead of migrating. It's more consistent that way. thoughts? 
* 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.