WM: grouping applications (TAI)

[Matthew Woehlke]

Maciej Pilichowski wrote:
> 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.

I'm not convinced general spatial switching is practical. Both because 
it is a hard problem technically and because I don't imagine it working 
out well in practice. Say I have this, with the lower window active:

+---+ +---+
|   | |   |
| +-----+ |
+-|     |-+
   +-----+

Which window would "move spatially up" make active?

The *switcher* would be free to handle keys however it wants, so a 
spatial switcher (expose) could treat 'up' as... well, up. A switcher 
like cover (the one I first outlined) would treat 'up' as up, also, but 
since the parent is what is "above" the current window...

(Actually, an expose-like switcher might have the above problems...)

At least for a tab container I think I would expect up to go to the 
parent. So it's a question of consistency. Making it work different in 
different container types I don't think is a good idea. An alternative 
is to not bind ctrl-up by default, which I would probably be okay with 
except that I don't know what I'd want to use instead.

And I do think left/right should do just that, especially in tab 
containers (and because as you mention below, ctrl-left is easier than 
ctrl-shift-tab).

>> "previous sibling"  (ctrl-backspace)
>> "next sibling"      (ctrl-shift-backspace)
> 
> 3-keys shortcuts are hard to press, besides lack of consistency,

shift-alt-tab? ctrl-shift-left? I think it's common for <key> and 
shift-<key> to be complementary actions; I don't see the inconsistency.

Also: ...oops. So much for using ctrl as the mod. Breaking editors is a 
no-no. And tab widgets are going to be fun... (But in fairness, 
shortcuts to switch tabs are already horribly inconsistent, so no huge 
change there...)

> tab is usually used for next, not for right.

(see below)

>> "activate switcher" (?) 
> 
> ctrl+tab

Apparently the previous rambling wasn't clear enough :-). My apologies. 
Let me try again:

*Any* of the above will activate the switcher if you keep ctrl held 
down... they'll just do it with the corresponding window already-active. 
Same as how alt-tab currently works. (Or is supposed to work. For some 
reason I am getting no switcher whatsoever on this machine ATM; probably 
a bad kwin build. Having to deal with no switcher at all, I can say it's 
NOT a state of affairs that makes me happy.)

An "activate switcher" key would activate the switcher without changing 
the active window. Possibly this would not need to keep holding a 
modifier key; you would need to use 'enter' to confirm the switch, and 
'esc' would leave the switcher without changing the active window. (I 
would probably like mod+esc to do likewise.)

Oh, and the mouse should do something useful in switchers ;-).

>> "left top-level"    (alt-shift-tab)
>> "right top-level"   (alt-tab)
> 
> I really doubt we need those. Besides, alt-tab, +shift, is taken.

I'm just stating the actions we have today, for completeness :-). I'm 
not sure about having no key at all to switch between root's children, 
but I would be willing to entertain that.

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

You re-used ctrl-tab below :-).

>> "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 :-)

Dropping "enter child" is actually TRTTD. It is a synonym for "activate 
switcher" outside the switcher, and I'm thinking once in a switcher, the 
switcher should use its own key bindings that make the most sense, esp. 
arrow keys should behave logically. That said, "go to parent" is really 
"activate switcher at parent container", as opposed to "activate 
switcher at current window". I think it's useful, but I wouldn't oppose 
dropping it either, especially if it's still there but unbound by 
default. Mmm, and if tapped, it should make the switcher active and keep 
it that way, since it would otherwise be a no-op.

Otherwise I think I would have only two sets of previous/next; one for 
switching spatially (which would follow form layout order in tiled 
containers), and one for switching historically (again, treating 
floating containers as always-historic). Thus, mod+arrows for spatial, 
mod+[shift-]backspace for historic. That leaves mod+[shift-]tab, which I 
think should be spatial and you think should be historic. Hmm...

I'm going to try to summarize in a new thread.

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

...but then you don't know what spatial-forward/back will do? It would 
be useful, but I'm not convinced. That would mean that the switcher 
always lays the windows out visually in spatial mode... okay. How do you 
know where historic-forward/back will take you?

Maybe you don't, and maybe that's okay?

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

Let me try to explain better. If I use expose-switcher on a tab 
container, sure, I get basically a grid of windows. Once I pick one, 
though, they go back to being tabs. That's not so different from how 
expose works now, is it? So the visual layout changes /in the switcher/, 
but once you pick a window, all that has changed is what is active. (And 
cover/flip is even worse in this respect ;-), expose at least tries to 
keep /some/ resemblance of spatial alignment.)

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

Yes.

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

Your guess is at least as good as mine, and possibly better ;-). 
(Somewhere .kde.org I would hope, but I don't have anything in mind as 
to what category.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Microsoft has become the next IBM; a dinosaur struggling to survive in 
the age of more able-to-adapt mammals (FLOSS). It remains to be seen if 
they'll be able to adapt before they go extinct.