zui, windows, desktops

[Aaron J. Seigo]

hi all ...

spent some time on the train this morning thinking about the 
zui/windows/desktops issues.

i drew some mock ups on paper which i'll try and put into digital format when 
i have some time here and post for comments/thoughts/etc.

in semi-summary:

* the idea of window groups is great, death to virtual desktops

* the window group overview could include an Activities overview as well. the 
visual will help explain this but for now imagine a strip at the top of the 
screen showing the existing Activities: a name above and a shrunken version of 
the Activity below; switching would be moving which activity is in the center, 
e.g. by scrolling through them or clicking on one. so there would be a 
horizontal stripe of activity choices sitting atop a set of horizontal window 
groupings, keeping things visually distinct so they don't become overly 
confusing?

* arrange the desktop containments on the corona in a horizontal strip, one 
row per screen

* one possibility is to do a paint-to-pixmap-and-publish system to generate 
full-size screenshots of the Activities for use in an overview mode would let 
us do this with decent performance and without really caring where on the 
canvas things are. this means no live updates, however, which would sort of 
suck. however, if we put the containment into a "zoomed out" mode and didn't 
show the applet handles when zoomed out, that might help somewhat.

* the centered Activity could have action buttons (remove, save, etc), the 
rest can just be buttonless; this reduces visual clutter and should make 
managing the toolbuttons a lot easier (and, performance-wise, faster)

* when in the "overview" mode, we could replace the normal view with a small 
view at the top for the strip, put the control buttons right on top of it (so 
no scaling issues) and another view below to be populated by the WM groupings

* windows in the groupings could be 'tagged' as per the suggestions from Chani 
et al by pressing a "tag windows" button in the activities selector and then 
clicking on windows in the groups below

* tagged windows would be removed from or shown in the overview when sliding 
through activities, and would have a coloured "halo" border showing they are 
associated with the activity (perhaps by similarly "haloing" the centered 
activity). this would let one keep the benefits of virtual desktops with the 
benefits of activity-association

* keyboard shortcuts for each window group could be painted above the window 
column itself and could be named (just as with current virtual desktops)

* add/remove of both window groups and activities could use an identical 
system of one add button and per-group/activity remove buttons.

* the window preview area could be drawn by kwin itself using the same system 
we do with the taskbar window previews; without kwin-composite (the compiz or 
kwin-without-compositing cases) we could re-use the tasks widget code to paint 
the groups of windows as buttons. when there is no kwin, the windows would 
just show up in one big group? certainly not sexy, but it would retain utility 
regardless of how plasma is run and degrade gracefully in the process. 
essentially this means creating a full-screen version of the tasks widget, 
perhaps with a special grouping strategy in libtaskmanager just for this 
representation? would save a lot of code writing, i think.

* panels should not be shown in the overview mode, i think. later we can 
perhaps add panel<->activity affinity

* we must publish the activity stuff live in nepomuk so that applications can 
adjust their content and play along too

* a widget on the panel should be there by default to swap into overview mode

* the new status codes marco added to Applet should be hooked into the system 
tray so that widgets in other Activities can say "hey, listen to me!" and let 
the user switch quickly to that activity (plasma containment + associated 
windows + nepomuk data)

i _think_ that addresses all the questions i posed, and even gets us a bit 
down the "how do we actually implement this" road.

so, executive summary: integrate activity zooming with the window zooming 
creating a brand new "overview" mode, allowing associating windows with 
activities as well as into groups (orthogonal but complimentary concepts)

what do the authors of the original sets of proposals think? it's really not 
many twists/turns from the original ideas proposed, i don't think?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090715/577c6062/attachment.sig