multi-screen management

[Chani]

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? :)