zui, windows, desktops

[Casper Clemence]

I'm a bit hesitant about butting-in on a developer discussion because
I'm aware I've become someone who makes more noise than contribution
around KDE  :¬(    I truly intend that that will not last.

Apologies aside, I've been thinking for some months about desktop-wide
project management. By which I mean that, for example a KDevelop
project might be extended to include an instance of Oketa.

It may be relevant to your ideas because it could allow users to use
applications together in a way that is discoverable and a simple
extension from the familiar concept of projects management and
provides to the desktop valuable information about what tasks the user
is working on.

Anyway there is an open invitation to a Google document in which I
have been trying to sketch-up some ideas, it is still a mess at the
moment but reading this email I thought I would share it anyway.

Feel free to edit it and treat it as a wiki if any of you are
interested in the idea

http://docs.google.com/Doc?id=dpsz6mj_2g3k8dqc5&invite=422561605

Casper

2009/7/16 Aaron J. Seigo <aseigo at kde.org>:
> 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
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>