<br><br><div class="gmail_quote">On 18 August 2010 08:42, Chani <span dir="ltr"><<a href="mailto:chanika@gmail.com">chanika@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
so... we had planned to have a little tool for managing the containments of<br>
multiple screens, in 4.5 - but there wasn't time. multiscreen has<br>
improvements, but also regressions - well, *a* regression - you can't access<br>
the containment of a screen that's not plugged in. the same applies to the<br>
per-desktop view stuff (they have a lot in common).<br>
<br>
anyways, jpwhiting said he might be willing to implement such a tool, and<br>
yesterday I was inspired (compelled?) and found myself writing about how such<br>
a tool may look and act: <a href="http://community.kde.org/Plasma/Multiscreen" target="_blank">http://community.kde.org/Plasma/Multiscreen</a><br>
<br>
feedback would be very welcome. :) and since I know many of us hate clicking<br>
links, here's the current text copy&pasted:<br>
<br>
Plasma/Multiscreen<br>
<br>
With the death of the ZUI, managing multiple screens (or per-desktop views)<br>
becomes... a little trickier. A UI for managing the containments ("widget<br>
groups" in user-speak?) is needed.<br>
Contents<br>
[hide]<br>
1 Manager Tool<br>
1.1 UI<br>
1.2 Under the Hood<br>
2 Inactive Screens<br>
[edit]Manager Tool<br>
[edit]UI<br>
<br>
I have a few ideas here, and would like feedback.<br>
<br>
The general concept I've got is a grid of containments, with screens left to<br>
right and (if PVD was ever enabled) desktops going top to bottom. If panels<br>
are to be managed here too, they could be along the edges of the cells. Only<br>
the current activity's containments would be used (no hypercubes plskthx).<br>
There would be a visible difference between the rectangle of active views and<br>
the inactive 'outside' ones. Containments could be dragged to other cells<br>
(causing a swap with the containment they're dropped on) and ones outside the<br>
active area could be deleted. Desktop containments would not be draggable to<br>
empty cells, because that could leave a view without a containment (panels, on<br>
the other hand, might have less restrictions).<br>
<br>
Usual case mockup <a href="http://chani.ca/images/screenmanager-bestcase.png" target="_blank">http://chani.ca/images/screenmanager-bestcase.png</a><br>
Bad case mockup (it could be worse...)<br>
<a href="http://chani.ca/images/screenmanager-worstcase.png" target="_blank">http://chani.ca/images/screenmanager-worstcase.png</a><br>
<br>
The UI ought to be something a user only needs occasionally, but it should<br>
still be easy to use.<br>
<br>
I considered doing just screens or just desktops, and trying to follow the<br>
geometry those are displayed in in other places (pager, krandr) but when you<br>
consider there will likely be leftover containments from old screenns and<br>
desktops that gets awkward.<br>
<br>
On the other hand, if there are both panels and PVD, that's also awkward:<br>
would users understand that even if panels only appeared and were draggable<br>
within the first row, that they still show up on all desktops? perhaps panels<br>
could have their own special row in that case..?<br>
<br>
Another tricky issue: how to represent the containments? If someone can get<br>
thumbnails of containments working properly I will give them lots of beer and<br>
hugs. :) Im the meantime... well, a grid of identical icons isn't very useful.<br>
there probably ought to be something thing-like for the dragging... I'm not<br>
sure how much trouble the user will have remembering which containment they<br>
left where. if fact, if they drag one icon to another identical icon, what is<br>
there to tell them the two containments were swapped at all?<br>
<br>
I think that, assuming there are no thumbnails, live previews will be<br>
important. The user will end up dragging an inactive containment to their<br>
current screen/desktop just to remind themselves what containment it was. If<br>
they have to hit apply every time that could get rather tedious.<br>
<br>
On the other hand, it might be good to keep in mind that the *normal* case is<br>
for a user to have PDV off, disconnect their one external monitor, and then<br>
want to go check on a widget it had - or swap its containment over to the<br>
remaining screen if they don't like which one their driver thinks belongs<br>
there.<br>
<br>
The (hopefully) less common, icky case is someone who has multiple screens and<br>
lots of desktops, then turned on PVD and wants to purge all the old<br>
containments (even though they ideally would be mere config data, not actually<br>
*running*).<br>
<br>
Oh, and as for where to go to open this UI: well, it has to run in-process,<br>
but it's not common enough to warrant a toolbox entry, so I had a crazy idea:<br>
what if whatever kcm is relevant to this stuff (plasma settings + wherever the<br>
PDV setting lives?) had a button that sent a dbus signal to plasma-desktop to<br>
show the UI?<br>
<br>
TODO: clean up the above rambling into a more structured document. :)<br>
<br>
[edit]Under the Hood<br>
<br>
The UI would have to talk to plasma-desktop's current Activity (you can get<br>
them via DesktopCorona), to ensure that the containment swaps happen smoothly.<br>
Also because one or both containments involved may not be running, once that<br>
stuff's implemented, so swapContainment might not be doable at all :)<br>
<br>
[edit]Inactive Screens<br>
<br>
When a screen is disconnected (or in PDV, a desktop removed) the associated<br>
containment and view (for each running activity) should be automatically<br>
stopped - and resumed again when the screen/desktop returns. We can migrate<br>
panels, but not desktops, and it doesn't make sense to leave something running<br>
and inaccessible (having to manually stop it would also be Wrong).<br>
* When implementing this, be careful to check how it interacts with stopping<br>
and starting activities. it'd suck to lose containments.<br>
* I don't like how I ended up with two authorities on where a containment<br>
belongs: there's both the lastScreen/lastDesktop settings in the containment,<br>
and the place that running containment has in plasma-desktop's Activity class.<br>
that ought to be rethought.<br>
* Might it be easier to leave the config in plasma-desktop-appletsrc, and have<br>
the startup loading skip containments assigned to nonexistant<br>
screens/desktops?<br>
* Once this is implemented, I believe panels should behave the same way,<br>
instead of migrating. It's more consistent that way. thoughts?<br>
* It'd be nice to investigate whether any delay would be helpful - is it<br>
likely for several screen changes to happen within a few seconds? either from<br>
drivers being fidgety or from a loose cable or something? I don't know enough<br>
to be sure.<br>
_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
</blockquote></div><br>