WM: grouping applications (TAI)

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Monday 09 March 2009 23:54:56 Matthew Woehlke wrote:
>> Apologies for the previously-insufficient explanation. Is the above
>> better?
> 
> Yes thank you. The term last-active is a misleading one though :-).

Whew! ;-)

>> 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 :-). 
> 
> They are not better or worse, they are different -- cltr+left would go 
> to next left window, while cltr+backspace would go the previous 
> window (previous in the sense of focus sequence). And those windows 
> can be the same, but they don't have to be.

Ah, I see. That actually brings up several interesting questions.

I'm going to start writing some stuff, jump in where you disagree or 
wish to add.

We need several child-switching keys; defaults in ():
"go to parent"      (ctrl-up)
"enter child"       (ctrl-down, ctrl-space?)
"previous sibling"  (ctrl-backspace)
"next sibling"      (ctrl-shift-backspace)
"left sibling"      (ctrl-left, ctrl-shift-tab)
"right sibling"     (ctrl-right, ctrl-tab)
"activate switcher" (?)
"left top-level"    (alt-shift-tab)
"right top-level"   (alt-tab)

I think the normal management mode should be "spatial", i.e. only 
previous/next would start a switcher in "historic" mode. Floating 
windows would copy historic to spatial mode, all others would operate 
left-to-right and top-to-bottom, possibly with order of precedence 
configurable (i.e. so users that read top-to-bottom, left-to-right could 
make vertical precedent; latin language users would use left-to-right, 
top-to-bottom). For RTL language users we might want to switch the 
ctrl[-shift]-tab defaults. The "enter child" shortcut would just start a 
switcher when not already in a switcher.

So, my cover-switch example would, once started, treat tab/arrows 
visually, but depending on how it was started (historic or spatial 
modes) would present the windows in different order. Similar with e.g. a 
list switcher (i.e. something like the non-composite task list we have 
now except either a tree or probably like dolphin columns). In fact it 
makes sense that the switcher should handle arrows directly, even if 
they otherwise aren't bound to global shortcuts. Otherwise the bound 
shortcuts would start a switcher.

Another good example switcher would be expose-like, with the parent off 
in a corner and siblings spread across the screen; arrows would jump 
around according to how the windows are displayed (this would be 
especially useful for tile containers since you can duplicate the layout).

Okay, done rambling. It's late, I'm not going to re-read that too 
carefully and so I may have missed (or seriously messed up) something :-).

> Don't dock would mean detach entirely from the container then -- i.e. 
> make a standalone window. But this is not going to root container, is 
> it?

I would assume it goes to root; why wouldn't it?

> Btw. making it standalone with ctrl make sense, because the root 
> container could be maximized, so you cannot physically move it 
> somewhere else, because "else" is taken by the root container.

I think I am confused. The root container, by definition, takes up the 
entire virtual screen, minus e.g. panels. IOW floating root with no 
child containers is what we have now. Tiled/tabbed root would be, well, 
interesting :-). Maybe even not allowed if there is more than one head.

I don't want to go as far as saying it isn't allowed /at all/ because a 
full-screen child-of-root container would still cover panels, but a 
maximized container still has borders. Although... you can also turn 
borders off. So maybe non-floating root /should/ just be not allowed. 
 From a technical standpoint I think it would be easier if only floating 
has to worry about panels and weird screen geometries. (Heh. So now I've 
changed my mind about root being identical to other containers :P. Okay, 
but it should still be a subclass of floating.)

> I see, that we covered everything I think, so what next -- mockups? Or 
> more detailed UI cases -- detach, dock, TAI<->GAI switch, etc? Spec 
> is cheaper than code.

Either, I think. Or start writing a wiki page with summaries :-). But 
yes, I feel like we have made excellent progress and have a lot of the 
basics in great shape.

If we're feeling the need to start another avalanche, we could try UI 
design for creating containers :-). (I need to go dig out what we'd said 
about tiled, first. Maybe the wiki is the best idea ATM, to write down 
what we've decided so far so we can reference it.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Still the prettiest." -- Legolas
(as quoted in The Very Secret Diaries by Cassandra Claire)
http://www.ealasaid.com/misc/vsd/