Difference between revisions of "Plasma/Multiscreen"

Jump to: navigation, search
(Other Tasks: another point)
m (Use cases)
 
(9 intermediate revisions by 2 users not shown)
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 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?
+
* 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?
 
* 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.
 

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."

This page was last edited on 14 September 2010, at 13:53. Content is available under Creative Commons License SA 4.0 unless otherwise noted.