On August 18, 2010 03:15:13 Marco Martin wrote: > On Wednesday 18 August 2010, Chani 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. > > needed -when- the activity manager isn't enough, but still reachable from > there i think
it's not about the activity manager. it's needed when people have had multiple screens or PVD. > > > 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. > > thinking a bit about about the ui i think it should be: > * display a single activity at a time > > *it should try to follow that geometry if possible > > - for monitors should be a grid, line or whatever is configured of the > active screens, the inactive ones could be in a line slightly separed with > the active ones > - each monitor box tries to represent directly a containment, if there are > containments assigned to oter desktops, they will have a layout > representing the pager, also here with a second line of ones that are > assigned to a desktop grids within grids? erg.. I kinda doubt that can look good. maybe draw some mockups? and consider panels too... > > > the total number > > *all things should be reordered by drag and drop naturally. :) > > > 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. > > uhm, so actual qgraphicsviews? this assumes all containments are running no... "previews" was the wrong word there. I meant instantly applying the settings, so you drag in one of the inactive containments and on your desktop you see it immediately. of course, that's different behaviour from 90% of kde config dialogs, so it's not ideal either... > > > 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? > > i think should be reachable from the activity manager (either right click, > another action icon, whatever) it's not related to activities, though. it's just made necessary by the way I did the activities. > > > 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). > > agree (i'm still not very happy of the current panel migration thing) > > > * 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. > > uhm, i think the authority shuld just be corona, but in case of > plasma-desktop corona use the Activity to make the decision... well, right now the corona isn't the authority on anything. and for non- running activities, the containments' settings are the only authority. > > > * Might it be easier to leave the config in plasma-desktop-appletsrc, and > > have the startup loading skip containments assigned to nonexistant > > screens/desktops? > > in the end, where you have the configuration is the same thing, depends if > it's ever wanted having running containments not associated with screens. > the exceptions are the mobile and netbook launchers, but they could have -1 > (instead of a number > than available screens) no, any containment that was never associated with a screen will be completely ignored by all of this code. :) also... at the moment, code that wants to work with desktop containments checks whether a containment is in offscreenwidgets in order to skip any dashboards. > > > * Once this is implemented, I believe panels should behave the same way, > > instead of migrating. It's more consistent that way. thoughts? > > agree > > > * 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. > > yes, two things likely to happen do we have any evidence for this, though? do you *think* it's likely or *know* it's likely? :) _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
