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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel