zui, windows, desktops

[Marco Martin]

On Thursday 16 July 2009, Aaron J. Seigo wrote:
> 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.

a quick and dirty photo will do :p

> 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?

i've read this point several times and still don't have a clear idea, yes a 
photo would be appreciated :)
>
> * arrange the desktop containments on the corona in a horizontal strip, one
> row per screen

hmm, it wouldn't be possible to switch a containment between screen so?
not being able to access an old activity just bcause at the moment i don't 
have a screen around doesn't seem too convenient?
or when a screen is disconnectedeverything is closed, saved and can be loaded 
from everywhere?

>
> * 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.

way faster and not being really live well maybe is not an huge loss...
what sucks a bit is that now in zoomed out mode is possible to drag applets 
from a containment to another, that wouldn't be possible anymore.
i have kind of an idea on mapping mouse events on the pixmap to start a qdrag, 
but would be quite imprecise, ugly and all:)

>
> * 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

question i'm wondering since a bit: does nepomuk has some support of the 
Context concept or is it something still to come?

>
> * 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)

+1 :)

> 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?

still have to figure out the interaction and the look of the thing, for now i 
just have those two little concerns, but i feel something cool could go out of 
it

Cheers