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.

Manager Tool

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

Bad case mockup (it could be worse...)

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

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

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.