WM: grouping applications (TAI)

[Maciej Pilichowski]

On Wednesday 11 March 2009 22:48:59 Matthew Woehlke wrote:

Ok, since now I differently imagine the switching I put the summarized 
view of it at top, and below part of the reply after which I came up 
to this idea. A little odd, but I believe it would make more sense 
when reading.

And btw. sorry again for late reply, a little ordeal I have here and a 
lot of bug hunting too ;-) So sorry!

Summary:
===============================================================
My new seeing things. Except for switching first-class windows only 
(alt-tab) user could:

a) switch locally windows within container
b) switch windows globally -- to do this, run switcher and than manage 
switching

a) this means by definition that you cannot switch with this methods 
windows like alt-tab; this also means this method does not have to 
care about mixed TAI/GAI modes because for this method there is no 
mixes, only one kind of container. Each shortcut stands on its own, 
those shortcuts could be:
left window -- win+left
right window -- win+right
up window -- win+up
down window -- win+down
next window -- win+tab ?
prev. window -- win+shift+tab

Unlike next-task (alt+tab) those last two do not change the order of 
the sequence (?).

b) within switcher it would be up to switcher to bind the keys, but it 
would be nice to pick up simple shortcuts per default and keep the 
basic meaning of them

(I am reading NWI here) -- I don't see the need for mod at all, simple 
keys would suffice
tab, left, right, 

Besides -- it would be good to have the same default keys as with 
local settings but without the mod key (win in this example). However 
two shortcurts additionally should/could be provided:
go to parent -- p
go inside (to first child) -- i (just example)


What you think, I personally like the idea of two levels of 
switching -- local and global, and default keys consistency (stripped 
mod) between those two modes.

Reply
=============================================================

> I'm not convinced general spatial switching is practical.

IMHO it is, because it is very intuitive.

> Both 
> because it is a hard problem technically and because I don't
> imagine it working out well in practice. 

Correction Matthew, it works well in practice, only the computer 
analogy is not 100% match to the real-world original.

> Say I have this, with the 
> lower window active:
>
> +---+ +---+
>
> | +-----+ |
>
> +-|     |-+
>    +-----+
>
> Which window would "move spatially up" make active?

You have to set priority, left/right, and down/up. For example with 
right+down, it would be the window on the right.

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

Btw. I thought previously that if user explicitly won't say "activate 
container" simple switching should activate only basic windows. And 
maybe that is why my proposal looked like it looked :-)

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

? Look above, once you wrote alt, then ctrl -- that is incosistency.

> Also: ...oops. So much for using ctrl as the mod. Breaking editors
> is a no-no.

It is using the same keys, yes, but it is not possible for conflict. 
You cannot switch windows and edit text in the same time. Remember, 
to switch windows, you have to call switcher -- ctrl+tab.

Only when the switcher kicks in, the rest of the keys are functional.

Why? Because having shorcuts for "this level container" only is very 
useful. I wouldn't like to trigger "global" meaning of 
shortcut "activate left" each time I want to go to the left tab. 
Because in more complex container I would eventually "fall off" the 
container.

In other words in my opinion, there should be navigation:
* direct -- this container only
* indirect -- trigger switcher first, then navigate wherever you want

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

Ok, so here why we couldn't understand each other before :-)).

But then, you would have:
a) either drop direct switching (within container)
b) provide double shortcuts -- for local changing and global changing

ad.a) I, as user, would feel very unsage, because I would have to pay 
much more attention than now 
ad.b) this would be hard to remember

> An "activate switcher" key would activate the switcher without
> changing the active window.

Oh, right, this should be true no matter what is decided of the above 
problems (paragraph above).

But wait, if the switcher does not change active window it means it is 
not possible to do quick-switch (as today with alt-tab). With my 
proposal (global vs. local) it would make perfect sense, and...

> Possibly this would not need to keep 
> holding a modifier key;

Right!

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

Right! 

And you would not need any cltr+up, etc. shortcuts. Just pure and 
simple tab, left, right, backspace, etc.

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

Like point and click, hmm, too easy ;-DDD

I cut it here, because I would like to sum up the above ideas, so 
answering to my old ideas would make only confusion.

I don't want to ruin your NWI mail, so here I summarize the above.

Actually I put the summary at top :-)

Cheers,