Plasma/Multiscreen: Difference between revisions

From KDE Community Wiki
(WIP: multiscreen page. saving often for fear of intel crashes.)
 
m (→‎Other Tasks: formatting)
Line 9: Line 9:
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 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.
* 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 the Applet class. that ought to be rethought.
* 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?
* 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?

Revision as of 05:30, 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 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?
  • Once this is implemented, I believe panels should behave the same way, instead of migrating. It's more consistent that way. thoughts?