windowgroups / pager / ZUI

[Aaron J. Seigo]

On Friday 10 July 2009, Sebastian Kügler wrote:
> So today during lunch, Chani, Marco, Rich and I were talking about the ZUI
> and the confusion between the ZUI and  virtual desktops. We came up with a

i really do like the idea of orchestrating windows and activities and hiding 
virtual desktops from the user as a non-relevant detail. however:

> = Example: Work Activity =
>
> The email client is started, an office application is started, the desktop
> contains a folderview with my current project's work document, and some RSS
> feeds that are relevant to my work.

how do i keep my windows separated, but keep affinity to the same activity? i 
want my email windows separate from my web browsing separate from my konsole 
window with it's N tabs open. i am still working on the SAME thing when 
working with all of them, however.

how do i switch quickly to my social networking activity without dumping all 
my windows? i mean, i do want my email client there always, for instance. for 
a web browser viewing a new website it's not such a big issue (open another 
browser window), but for an email or IM client or a web browser viewing a site 
that can only be viewed in one tab/window at a time this is useless.

confusing "activity" with "virtual desktop" feels like a real mistake. i know 
it fits some people's work flow, but it feels like a very limiting and, tbh, 
artificial one. and really, any window-centric approach will suffer from 
problems. maybe make it activity centric instead, e.g.:

* new windows that are opened up are not associated with any given activity 
(and so are shown no matter what activity is selected)

* on zooming out one is presented with all activities and can easily switch to 
another, windows staying where they are

* one can also drag-and-tag, or through some other interaction mechanism 
associate a window from the "all windows" grouping to an activity if it 
belongs specifically with that one.

so switching activities and changing windows by default has no correlation, 
but one can associate specific windows with an activity.

even better would be if i could associate certain documents with an activity, 
too, which means we'd need to know which documents are currently being 
viewed/manipulated within an application. we could get there later, however.

still, that doesn't solve the very simple problem of "i'd like to hit ctrl-f2 
and go to my konsole window". under the activity-is-a-window-group model i'm 
stuck with either switching my activity when i switch applications 
(undesirable) or having all applications sharing the same desktop. that's an 
unfortunate compromise to make.

somewhat related, it may make sense to pull into this activity-based panels 
which could follow the same rules as windows (always there, unless associated 
with an activity)

> = How does the ZUI look like =
>
> The ZUI could have the background of a faded to black current activity, or
> black.

if we go this route, it should have a nice background. fading out the current 
activity will just make it all very confusing as to what is happening. either 
zoom out or don't, but don't mix modes with some elements zoomed and some not.

if each activity occurs in its own window, then providing a nice background is 
easy.

even if we don't, i've found a hackish way to draw shadows around the desktop 
containments so we'd be covered there.

but. ... yes, this proposal skips over the technical "how we'd make this 
happen" bit. does plasma export a rendering of each activity for this kwin 
window effect to render on screen? do we create a top level window per 
activity? 

depending on those answers, we'll need to further answer things like: how does 
this work with multiple screens? how do we keep the resources within sanity? 
etc.

> :-) We can also offer a "traditional/simple mode", much like it's now, but
>
> without ZUI at all. That would just mean keeping what we have now and
> removing the zoom-out.

in that case, why don't we just rip out activities as a user facing concept in 
plasma-desktop altogether. there is, at such a point, precisely no point to 
them existing at all within plasma-desktop. instead, just create one window 
per activity (hello, overhead) and let the window manager manage them.

personally, i don't agree with this part at all. it will serve one purpose 
only: to remove this feature from people who can't currently use compositing.

so .. i think this is a good start to the idea but it needs a lot more rigor 
applied to shape it into something that's actually implementable.

right now it feels like someone saw a demo of gnome shell and got caught up in 
the idea of a fancy desktop grid effect. the entire idea of "desktop grid is 
the answer" completely misses the point: it's not really about giving a nice 
visual arrangement of what already exists (which is just papering over a 
static system), but making it easy to switch contexts so that "i was doing A" 
and "now i'm doing B" is reflected in the user interface.

the first principle with activities is that users switch between usage 
contexts (different projects, different social parameters, different 
geographical locations...) and the computer should be able to adjust to those 
contexts.

design from that first principle as the centre point. how windows are arranged 
on-screen comes after that. it's the easy part of the problem, really.

-- 
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/20090714/ec6b5294/attachment.sig