WM: grouping applications (TAI)

[Maciej Pilichowski]

On Wednesday 11 March 2009 02:09:15 Matthew Woehlke wrote:

> 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?)
> "left sibling"      (ctrl-left, ctrl-shift-tab)
> "right sibling"     (ctrl-right, ctrl-tab)

a) his is counter-intuitive -- I can go left, but I cannot go up
b) enter child can be done really easily by navigating 
left/right/down/up, we don't need separate shortcut for this.

> "previous sibling"  (ctrl-backspace)
> "next sibling"      (ctrl-shift-backspace)

3-keys shortcuts are hard to press, besides lack of consistency, tab 
is usually used for next, not for right.

> "activate switcher" (?) 

ctrl+tab

> "left top-level"    (alt-shift-tab)
> "right top-level"   (alt-tab)

I really doubt we need those. Besides, alt-tab, +shift, is taken.

I think the more minimal set could be done, yet be as useful (i.e. you 
can do the same without having so many various actions)

> "activate switcher" (ctrl-tab) 
> "go to parent"      (ctrl-pgup)
> "left sibling"      (ctrl-left)
> "right sibling"     (ctrl-right)
> "upper sibling"     (ctrl-up)
> "lower sibling"     (ctrl-down)
> "previous sibling"  (ctrl-shift-tab, ctrl-backspace)
> "next sibling"      (ctrl-tab, ctrl-shift-backspace) 
I like symmetries :-)

You don't have to learn anything, if you use KDE you already know 
those shortcuts.

> I think the normal management mode should be "spatial", i.e. only
> previous/next would start a switcher in "historic" mode. 

Yes.

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

I opt for having both modes at the same time, and what is activated on 
next shortcut depends solely on that shortcut.

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

Yes, but this switcher changes the layout of the container, and above 
we talk about most basic switcher -- which only switches.

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

Ok, so it is a desktop from user POV?

If yes, then I agree with what you wrote before :-).

> Maybe the wiki is the best idea ATM,
> to write down what we've decided so far so we can reference it.)

Ok, any particular address? 

Cheers,