WM: grouping applications (TAI)

[Matthew Woehlke]

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

up/down do nothing in tabbed? do left/right wrap? If yes, then I agree 
with the above.

Are you dropping historic? Maybe there should be three modes: spatial 
(arrows), historic ([shift-]backspace) and "smart" ([shift-]tab, 
historic in floating and tiles, spatial in tabbed)? (Actually, in that 
case I'd say we could drop pure-historic bound by default.)

> 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

Actually, if we do go with spatial up/down, I think the switcher should 
use the global shortcuts, and have an option (default == all but shift, 
just in case users want to do weird bindings) what modifiers to strip 
when in 'activate only' mode. Which makes it easier to start the 
switcher as soon as you switch windows :-) (starting at the window you'd 
get to by tapping instead of holding win).

So the switcher needs also:
- go to parent
- go to child
- confirm (only required for 'activate only' mode)

...and the global keys are:
- spatial n/s/e/w (win+arrows)
- "smart" previous/next (win-[shift-]tab)
- historic previous/next (win-[shift-]backspace? unbound?)
- activate switcher at current window

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

mod is either alt or win. You gave basically the same set above as I 
gave, with mod==win. (I would prefer win if we can get away with it, 
just worrying about a: messing up people that use that for desktop 
switch currently - but they can adapt :-) - and b: if win might not be 
usable on some keyboards.)

Um. Reading your next comment I think I sense a miscommunication here...

If you bring up a switcher with a non-mod key (i.e. so it stays up 
without holding the mod key), there is no mod. 'mod' is for the global 
shortcuts, which obviously need a mod.

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

I think I am lost ;-). Sorry... not following what you mean by global 
and local.

>> I'm not convinced general spatial switching is practical.
> 
> IMHO it is, because it is very intuitive.

If it /works/, sure. I'm not convinced it can be made (at a technical 
level) to work reasonably :-). Let's say that I agree it is desirable, 
but trying to implement it might be "too hard". IOW, let's aim for it, 
but don't depend on it.

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

Well obviously you can click on a container :-) (consider e.g. a 
container frame or title bar). You can also, I would think, "activate" 
one with a switcher. But there will always be a real window active, i.e. 
an "active" container is one along the chain from root to the active window.

We might be miscommunicating again, but I /think/ I am agreeing with you.

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

I was talking about global shortcuts, not in a switcher. In a switcher, 
'mod' is only 'keep holding it if that's how you got here, until you are 
done switching'. Otherwise there is no mod.

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

I disagree, but unless I misunderstood what you wrote above, you agree 
with what I am actually saying, which is global shortcuts to switch 
within children, without having to start a switcher first.

> Because in more complex container I would eventually "fall off" the 
> container.

You can't leave the "active" container (chain) except the switch 
root-children shortcut (i.e. default alt-tab), or inside a switcher. IMO 
win-left should wrap, but you'd certainly stay in the container. 
(Actually... might want to make it an option if it should wrap or not? 
Or is that not needed?)

Hmm, I can see where this might need to change, although I agree as far 
as the initial implementation. Let's throw it at the wall (users) and 
see if it sticks ;-).

That reminds me... win-shift-left: exchange this window with window to 
the left :-). And similar for other shortcuts. Doesn't wrap.

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

Yes, I don't think we were in disagreement here... except that I want 
the switcher to show up as soon as you don't let go of 'win' :-). (That, 
or we should reconsider that current alt-tab works this way?)

> But then, you would have:
> a) either drop direct switching (within container)

Not at all. If you tap the key, you get direct switching. And unless the 
switcher is broken, you get the same effect doing:
hold win, left, left, release win
...as win-left twice.

(Depending on the switcher, that doesn't necessarily carry over to 
spatial switch up; e.g. it would for expose, but not for cover.)

> b) provide double shortcuts -- for local changing and global changing

This I don't follow. As above I think I'm failing to explain such that 
your understanding matches what I'm thinking. Hopefully the above helps 
figure out where we're having the disconnect.

I'm stopping here I'm already repeating, any more would be just more of 
that.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"943. I am not Bjorn of Borg."
  -- from 975 things Mr. Welch can no longer do in an RPG
http://theglen.livejournal.com/16735.html