Plasma/Multiscreen: Difference between revisions

Latest revision as of 13:53, 14 September 2010

without the ZUI, we need an alternate way to access the containments of screens that aren't connected...

the latest plan:

when PVD is deactivated, we offer to purge the unused containments (but, in user-speak of course). other than that, we ignore PVD, because a virtual desktop can always be readded (whereas a screen may be physically unavailable).
the activity manager UI will use thumbnails generated from the view (look at the code in kdelibs/plasma/animations/widgetsnapshot.cpp to see

how to do this). hopefully we can save these thumbnails out when closing an activity..

when the current activity has >1 screen, it'll have a thumbnail for each screen. you can click to bring a containment to the current screen, and there'll be delete buttons for ones not in use.
when a screen is detached its containment is left running as it is now; the performance impact of this should be negligible.

Use cases

These are some use cases for multiscreen management of activities. They are paraphrased from conversations at plasma-devel.

Jerry: "I usually use two screens, but pulled one screen off my desktop to use for a separate machine for longer-than-short-term. Now my main desktop has one screen, with the panel on it. I want to see in my only screen what was available in the removed screen".

Chuk: "I'm working at the office with my laptop attached to a desktop monitor, with a 'Working' activity. I unplug the external monitor and take the laptop home where I use a 'Leisure' activity. Then I remember there was one important note in my office my monitor, and I need to read it in my laptop."

Bugged Boy #1: "I have set a wallpaper with some plasmoids in my laptop, but every time I plug an external monitor KDE moves them to the monitor. I want to tell KDE to keep those plasmoids and wallpaper in the laptop."

Bugged Boy #2: "I tried to set up a different wallpaper at each virtual desktop, but I didn't like it and disabled this feature. Now my system is slow, and someone on irc told me it's because all those other desktops are still running. I don't want to remove by hand all those extra desktops, the 'disable' button should have removed them."

@@ Line 1: / Line 1: @@
-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.
+without the ZUI, we need an alternate way to access the containments of screens that aren't connected...
-==Manager Tool==
+the latest plan:
+* when PVD is deactivated, we offer to purge the unused containments (but, in user-speak of course). other than that, we ignore PVD, because a virtual desktop can always be readded (whereas a screen may be physically unavailable).
+* the activity manager UI will use thumbnails generated from the view (look at the code in kdelibs/plasma/animations/widgetsnapshot.cpp to see
+how to do this). hopefully we can save these thumbnails out when closing an activity..
+* when the current activity has >1 screen, it'll have a thumbnail for each screen. you can click to bring a containment to the current screen, and there'll be delete buttons for ones not in use.
+* when a screen is detached its containment is left running as it is now; the performance impact of this should be negligible.
-===UI===
+== Use cases ==
+These are some use cases for multiscreen management of activities. They are paraphrased from conversations at plasma-devel.
-I have a few ideas here, and would like feedback.
+* Jerry: "I usually use two screens, but pulled one screen off my desktop to use for a separate machine for longer-than-short-term.  Now my main desktop has one screen, with the panel on it. I want to see in my only screen what was available in the removed screen".
-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).
+* Chuk: "I'm working at the office with my laptop attached to a desktop monitor, with a 'Working' activity. I unplug the external monitor and take the laptop home where I use a 'Leisure' activity. Then I remember there was one important note in my office my monitor, and I need to read it in my laptop."
-[http://chani.ca/images/screenmanager-bestcase.png Usual case mockup]
+* Bugged Boy #1: "I have set a wallpaper with some plasmoids in my laptop, but every time I plug an external monitor KDE moves them to the monitor. I want to tell KDE to keep those plasmoids and wallpaper in the laptop."
-[http://chani.ca/images/screenmanager-worstcase.png Bad case mockup] (it could be worse...)
+* Bugged Boy #2: "I tried to set up a different wallpaper at each virtual desktop, but I didn't like it and disabled this feature. Now my system is slow, and someone on irc told me it's because all those other desktops are still running. I don't want to remove by hand all those extra desktops, the 'disable' button should have removed them."
-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.