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 UI==
+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.
-TODO
+== Use cases ==
+These are some use cases for multiscreen management of activities. They are paraphrased from conversations at plasma-devel.
-==Other Tasks==
+* 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".
-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).
+* 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."
-- When implementing this, be careful to check how it interacts with stopping and starting activities. it'd suck to lose containments.
+* 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."
-- 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 the Applet 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?
+* 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."
--Once this is implemented, I believe panels should behave the same way, instead of migrating. It's more consistent that way. thoughts?