Plasma/Multiscreen: Difference between revisions
< Plasma
m (→Other Tasks: formatting) |
(→Other Tasks: another point) |
||
| Line 10: | Line 10: | ||
* When implementing this, be careful to check how it interacts with stopping and starting activities. it'd suck to lose containments. | * 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 | * 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? | * 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? | * 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. | |||
Revision as of 05:34, 18 August 2010
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 UI
TODO
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).
- 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.