|(9 intermediate revisions by 2 users not shown)|
|−|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. |+|
the ZUI, screens ...
| || |
|−|==Manager UI == |+|
| || |
| || |
|−|==Other Tasks== |+|
| || |
|−|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). |+|
a , a the and activity. , and to it .
| || |
When implementing this, be careful to check how it interacts with stopping and starting activities. it'd suck to lose containments. |+|
* , to . to .
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? |+|
* I up a , 'it and this is , 's . I don't to .
|−|* 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. | |
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.
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."