WM: grouping applications (TAI)

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Monday 09 March 2009 16:13:29 Matthew Woehlke wrote:
> 
>> Let me try again. Let's say you have (easy example):
>>
>> (a) tile container +
>>    (b) tab container
>>      (c-f) konq's (with qt doc)
>>      (g-i) konsole (h+)
>>    (k) kate sidebar +
>>    (l) tab container
>>     (m-p) kate documents (with various source files) (n+)
>> (q) kpat
> 
> Wait here please.
> 
>> Now, each parent (including root) has a last-active child, right?
>> The '+' mark active children, above. 
> 
> I don't uderstand both of them. What is "last-active" term at all?

First, let me be clear that there is already a lot of "last active". 
Every window has a "last active" widget (actually from the window's 
perspective it's just "active", but the entire window is "inactive"). 
The same applies to windows on virtual desktops.

> And if + are active children, it means there are 3 active "windows"?
> How is this possible?

There is one active window, determined by following the active container 
chain from root. "Last active" is the window that will become active if 
a container becomes active. Again, same thing with windows on virtual 
desktops, and widgets in windows. When you switch from window A to 
window B and back to window A, window A remembers what widget was active.

Apologies for the previously-insufficient explanation. Is the above better?

>>> Here I am lost. Let's back to your example, I am writing
>>> something in any doc within Kate, Konq. is visible, I would like
>>> to make a switch to Konsole. How we do this.
>> Assuming you have the awesome plug-in :-). You press ctrl-tab. Up
>> pops something with these preview images:
> 
> Hmm, I am just thinking -- maybe we should not show anything extra? 
> Just gray out the whole container, and preserve colors + add frame 
> (a11y people) to the window which should get focus. User than see 
> exactly not altered layout at all, and can use 
> ctrl+tab/shift+ctrl+tab to go next/prev window, or just user arrow 
> keys to navigate trough layout in geometric sense, arrow-down would 
> mean go activate the window below.

You could do that I suppose. I think I would have to think about it more 
and/or see mock-ups, but maybe for the non-composite switching. What I 
was illustrating is an example switcher effect along the lines of cover 
switch.

I think we're roughly on the same page; anyway it's a little more 
important to have the concept of "this is possible" worked out, since I 
envision the actual switcher being pluggable with multiple options, just 
like we have today.

>> Until you do, you can move around with arrows/etc. (I think I would
>> want to use mainly arrows, not so much space/whatever, though
>> tab/shift-tab is okay.)
> 
> Tab-shift would be a killer in case when the switch mode is triggered 
> i think, the better would be ctrl+backspace as going previous. In 
> other words ctrl+shift+tab or ctrl+tab to trigger switching, but once 
> trigger handle ctrl+backspace as well (as ctrl+shift+backspace). 
> 
> Detail of course.

Yes. Btw, what keyboard layout do you have? For me it seems arrows would 
be much better (all in one spot); tab and backspace are opposite ends of 
the keyboard :-). Of course, as you say, this is all details since I 
assume the keys are configurable anyway. Arguing defaults isn't 
important right now :-).

>> I think my earlier suggestion was it tries to go in the deepest 
>> container possible,
> 
> Ok.
> 
>> unless you do something that makes it go to root  
>> instead (or vice-versa), where "something" is e.g. hold ctrl.
> 
> I think it is not necessary -- if it is possible to just drag the 
> window you can drag as sibling of the top level window.

...unless the root container is totally obscured? My experience is that 
a "don't dock" key will be needed.

>> That... might be interesting :-). Again I'm more inclined to copy
>> chrome 'tabs above everything' since it fits more with the tab as a
>> WM object concept (and is less technically challenging).
> 
> After rethinking I have to give up my personal preferences and goes 
> with what logic dictates.
> 
> The most important is application "decoration" to inform user what 
> she/he is looking about, thus tab (not that ugly as in chrome 
> though ;-))) ). 

Hopefully not ugly, yes :-D.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"You know what Microsoft's problem really is? They've lost the ability 
to feel ashamed." -- Pamela Jones (Groklaw)