On 18 August 2010 08:42, Chani <chan...@gmail.com> wrote:
> so... we had planned to have a little tool for managing the containments of > multiple screens, in 4.5 - but there wasn't time. multiscreen has > improvements, but also regressions - well, *a* regression - you can't > access > the containment of a screen that's not plugged in. the same applies to the > per-desktop view stuff (they have a lot in common). > > anyways, jpwhiting said he might be willing to implement such a tool, and > yesterday I was inspired (compelled?) and found myself writing about how > such > a tool may look and act: http://community.kde.org/Plasma/Multiscreen > > feedback would be very welcome. :) and since I know many of us hate > clicking > links, here's the current text copy&pasted: > > Plasma/Multiscreen > > 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. > Contents > [hide] > 1 Manager Tool > 1.1 UI > 1.2 Under the Hood > 2 Inactive Screens > [edit]Manager Tool > [edit]UI > > I have a few ideas here, and would like feedback. > > The general concept I've got is a grid of containments, with screens left > to > right and (if PVD was ever enabled) desktops going top to bottom. If panels > are to be managed here too, they could be along the edges of the cells. > Only > the current activity's containments would be used (no hypercubes plskthx). > There would be a visible difference between the rectangle of active views > and > the inactive 'outside' ones. Containments could be dragged to other cells > (causing a swap with the containment they're dropped on) and ones outside > the > active area could be deleted. Desktop containments would not be draggable > to > empty cells, because that could leave a view without a containment (panels, > on > the other hand, might have less restrictions). > > Usual case mockup http://chani.ca/images/screenmanager-bestcase.png > Bad case mockup (it could be worse...) > http://chani.ca/images/screenmanager-worstcase.png > > The UI ought to be something a user only needs occasionally, but it should > still be easy to use. > > I considered doing just screens or just desktops, and trying to follow the > geometry those are displayed in in other places (pager, krandr) but when > you > consider there will likely be leftover containments from old screenns and > desktops that gets awkward. > > On the other hand, if there are both panels and PVD, that's also awkward: > would users understand that even if panels only appeared and were draggable > within the first row, that they still show up on all desktops? perhaps > panels > could have their own special row in that case..? > > Another tricky issue: how to represent the containments? If someone can get > thumbnails of containments working properly I will give them lots of beer > and > hugs. :) Im the meantime... well, a grid of identical icons isn't very > useful. > there probably ought to be something thing-like for the dragging... I'm not > sure how much trouble the user will have remembering which containment they > left where. if fact, if they drag one icon to another identical icon, what > is > there to tell them the two containments were swapped at all? > > I think that, assuming there are no thumbnails, live previews will be > important. The user will end up dragging an inactive containment to their > current screen/desktop just to remind themselves what containment it was. > If > they have to hit apply every time that could get rather tedious. > > On the other hand, it might be good to keep in mind that the *normal* case > is > for a user to have PDV off, disconnect their one external monitor, and then > want to go check on a widget it had - or swap its containment over to the > remaining screen if they don't like which one their driver thinks belongs > there. > > The (hopefully) less common, icky case is someone who has multiple screens > and > lots of desktops, then turned on PVD and wants to purge all the old > containments (even though they ideally would be mere config data, not > actually > *running*). > > Oh, and as for where to go to open this UI: well, it has to run in-process, > but it's not common enough to warrant a toolbox entry, so I had a crazy > idea: > what if whatever kcm is relevant to this stuff (plasma settings + wherever > the > PDV setting lives?) had a button that sent a dbus signal to plasma-desktop > to > show the UI? > > TODO: clean up the above rambling into a more structured document. :) > > [edit]Under the Hood > > The UI would have to talk to plasma-desktop's current Activity (you can get > them via DesktopCorona), to ensure that the containment swaps happen > smoothly. > Also because one or both containments involved may not be running, once > that > stuff's implemented, so swapContainment might not be doable at all :) > > [edit]Inactive Screens > > 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. > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel