WM: grouping applications (TAI)

[Maciej Pilichowski]

On Saturday 14 March 2009 00:56:25 Matthew Woehlke wrote:

System crashed while writing the summary so I am sorry if there is 
some inconsistency -- the numbering is my fault only ;-)

Ok, the most important things go up:

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

Bad wording, propably I should say:
* local -> limited scope
* global -> global scope

I think it is best to show it by example -- two apps Konqueror and 
Konqueror side by side inside GAI container. Each Konqueror has 2
tabs. The active tab is first in the left Konq.

With local switching you can activate whatever tab you want inside the 
first Konq. only. You cannot switch to the second Konq. using local 
shortcuts. Local here does not mean they are defined in the Konq. -- 
no, they are common within KDE, but they see only what is available 
within current container --> here, one Konq. instance.

The switcher however works in global mode, it sees all windows, so it 
is possible to go from the first tab in Konq.#1, to the last tab in 
Konq.#2.

Let's introduce such notation, K1, K2 (konq), K1_1 (tabs within konq). 
K1_1 is active. And plus Kate as standalone app, on the right.

So, after reading the whole mail, again, the summary:
====================================================

Limited scope (cannot go outside current container)
a) left window -- win+left
b) right window -- win+right
c) up window -- win+up
d) down window -- win+down
e) next window -- win+tab 
f) prev. window -- win+shift+tab
m) parent -- win+pgup (?)
n) child -- win+pgdn (?)

Global scope:
i) left win -- win+shift+left
j) right window -- win+shift+right
k) up window -- win+shift+up
l) down window -- win+shift+down

History (global):
g) next.hist -- win+backspace
h) prev.hist -- win+shift+backspace
o) cancel -- win+escape

In my opinion history is special case, it works differently also, like 
alt-tab today. In case of all other shortcuts, lim.scope and global, 
each keystrokes has immediate effect. History on the other 
hand "waits" until user either cancel switching or release shortcut 
for accept switch.

I am not sure if (e) and (f) should be global or local scope.

Examples (for the sake of clarity, no wrapping _here_)

K1_1 (starting point)
a K1_2 
a K1_2 (no fall off)
e K1_1
e K1_2
i K2_1 (K2 is activated and it passes (?) focus to its child)
g K1_2 (single keystroke, i.e. quick-switch)
m K1

So this is just a polishing of my previous idea -- ability to switch 
right away without switcher to any window you would like.

However, switcher of course it is also available -- by it should be 
(in my concept) launched as any other program, like F7, and then user 
could use simpler key bindings (could! no forcing though). Direct 
shortcuts have to use such elaborate combinations, because of 
possible conflicts -- but switcher does not conflict with anything. 
Besides switcher could honour both mappings. But allowing to use 
simple keys, we also flats out the learning curve -- first try the 
switcher, learn shortcuts, then try to switch without switcher at 
all -- faster, but not for everybody.

Switcher would require canceling (esc) or accepting switch (enter).

As you can see for me switcher (easy way) should be distinct from 
direct switching (power-user way) -- with switcher you can let your 
hands rest a bit, note TAI/GAI could be complex, so you can do it 
everything it your own pace, think, no rush. With direct switching it 
is different, each actions count, each keystroke has immediate 
meaning.

=====================================================

The reply:

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

Yes.

> do left/right wrap? 

Ok. However this could be perfectly optional.

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

Sorry, forgot about them:
hist.next -- win+backspace
hist.prev -- win+shift+backspace

Btw. all those above are lim.scope shortcuts. So using them it is 
impossible to switch outside the current container ("fall off").

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

Here I cannot agree or disagree, because I have different concept of 
lim. vs. global scope (i.e.switcher).

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

Yes.

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

With difference about dropping the mod, here yes.

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

When you call switcher you cannot edit files, copy files, launch new 
programs, right? So extra mod in this mode is not needed, switcher 
could behave just like normal program.

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

Exactly. Like F7 -- bring in expose switcher, F6 -- bring in basic 
switcher, F5 -- bring in XYZ switcher.

> 'mod' is for the 
> global shortcuts, which obviously need a mod.

But once switcher is launched it can have simple shortcuts. Because 
they are pressed within it and interpreted only by this switcher.

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

Ok, if any problems occur -- I will try to help, ok? I think the only 
tricky part is algorithm that picks up the target window.

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

Actually, after rethinking this would be a bad idea, because after 
making layout user would always have to remember what is what. And 
besides, I found a "proof" of failing -- is Konqueror with TDI a 
container or not in sense, should be activated in a way described 
above or not?

So -- everything should be taken into account when switching.

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

Oh, ok.

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

Yes! :-)

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

Wait, wait -- it cannot be alt-tab because this is too well know for 
switching first-class windows.

> or inside a 
> switcher. 

Yes.

> IMO win-left should wrap, but you'd certainly stay in the 
> container. 

Great!

> (Actually... might want to make it an option if it 
> should wrap or not? Or is that not needed?)

:-).

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

And this shortcut would be of global scope? I am having thoughts 
here -- it is good in general, but:
* if you are in the middle of Konq. (the opening example) there is no 
use of this shortcut really, unless it switches whole Konquerors.
* but then I see the natural limitation of mixing GAI/TAI (nested 
structure) -- because we would have shortcuts for top-level, the 
lowest-level, the above-lowest-level, but nothing (except switcher) 
covers up the middle levels (if any). Nothing that would stop us, but 
just a fact

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

Yes, alt-tab works this way, but I think we should make an exception 
for it for historical reasons and common sense. But such beast as 
mixed GAI/TAI should have another logic -- show switcher on demand, 
otherwise don't show switcher at all. Ability to "just" switch using 
special shortcuts.

Btw. this is already happening today. I switch tabs in Konq. by 
ctrl+tab and I don't see any switcher.

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

I cut a bit earlier, to summarize :-).

Cheers,