Plasma/Multiscreen: Difference between revisions

From KDE Community Wiki
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 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 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.