multi-screen management

[Diego Moya]

On 18 August 2010 08:42, Chani <chanika at 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 at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20100830/f5d0618b/attachment.htm