zui, windows, desktops

[Chani]

On July 15, 2009 17:21:02 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.
>
> 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?

er... you mean switching activites in the same kwin-effect as switching 
windows?
that sounds... confusing. how do you navigate through the two groups? (note: 
I'm only slightly familiar with coverflow and none of the other effects. no 
composite here)

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

+1
now what about arranging inactive containments? what about drag&drop?

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

er... are you talking about kwin effects here, or something else?
...oh, it was... a kwin-effect but not requiring composite. um. in that case 
this sounds kinda bad.

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

uhm.. how do I switch activities?

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

I think I need a mockup.

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

activites selector?
clicking on windows?
:/

how about we start by putting something in the titlebar contextmenu to replace 
the "To Desktop" submenu there?

I suppose there's no harm in adding a tag button to this swiss-army-chainsaw 
effect, but make sure this stuff is also available through normal means.

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

you've lost me.
maybe I should point out that tags aren't necessarily activity names.

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

keyboard shortcuts could be named? huh? or do you mean groups... well, I was 
thinking the groups would *be* tags. so that gives you the name.

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

what happens when you remove a window group? I would assume that the group 
just gets disbanded and the windows stay open.

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

oh... so you want there to be a non-composite version of this effect... huh.

> 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

perhaps.

> 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

no, they shouldn't.
you mean panels that only show up when I'm on a certain activity? huh

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

nepomuk++, but what is "activity stuff"?

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

so... we have show-desktop, show-dashboard, and show-overview?
and, well, we do still have this taskbar that shows all the tasks. for those 
of us without composite, this is just a fullscreen taskbar + activity bar.

>
> * 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... err... if you're planning to *replace* zooming with this overview 
mode... then..

-how do I navigate through this mode?
-how do I switch activity?
-how do I just get an activity to the front to show its controls?
-how do I go between switching activities and switching windows?
-how do I move an applet from one activity to another?
-how do I rearrange activities (if we want to make that possible)?
-where do the inactive activities go?
-how do I move an activity to another screen?

oh, and we should remember to make space for the corona-toolbox somewhere.

----

in general... I'm not sure I like the idea of combining window-switching, 
activity-switching and activity management. maybe it could be done well, but 
I'm not convinced. you've left out mention of several features I don't think 
we should lose.
and I don't think we're on the same page wrt tagging yet.

although this does make me realise that the relation between window tags and 
activites is poorly defined in my head... hrmm...

btw, we already have view-per-virtual-desktop, but did anyone implement the 
code to make it not go insane if you put the same activity on two views?

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- 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/20090718/5273ae2e/attachment.sig