Switchers as arrangement managers

[Matthew Woehlke]

Maciej Pilichowski wrote:
> On Saturday 02 May 2009 02:09:13 Matthew Woehlke wrote:
>> But I don't think that level of integration should be a priority.
>> As currently defined, we have "keys which will start a switcher",
>> and "keys used in a switcher" (which are supposed to be the same,
>> but may have semantic differences*).
> 
> Errm, for primary switcher? Besides mod+escape I don't see difference.

My thought for a cover switcher was that spatial-up would be "go to 
parent" (which is really still a "spatial up", in terms of how the 
switcher is displaying the windows).

>> (*This makes me think maybe spatial u/d/l/r shouldn't start
>> switchers, those being the ones I would see as behaving different,
>> and also because I don't see the advantage to those invoking the
>> switcher.)
> 
> What it is switcher really? It's lets change the focus, right? -- this 
> has to be done in every switcher. The visual appearance it is up to 
> switcher.

See above; the reason I am thinking to not have u/d/l/r start a switcher 
is because spatial-up outside the switcher is not necessarily the same 
thing as spatial-up /inside/ the switcher. However previous/next should 
always be the same.

>> Oh, and, an example:
>>
>> +-+-+
>> |A|B|
>> +-+-+
>> |C|D|
>> +-+-+
>>
>> If I start at A, and rearrange next twice, then without a switcher
>> I would expect A->B, B->C, C->A (that is, B winds up where A was, C
>> where B was, and A where C was). But with a switcher (assuming a
>> switch left then down follows the same order), I might expect A and
>> C to switch, and B to stay put. 
> 
> Rearrange = exchange? What it is "with/without" switcher?

Basically, yes. "Rearrange" = change position of windows. Exchange is a 
subset of that (but I don't think of any one action right now that isn't 
an exchange).

>> I think what I would argue here is
>> that normal rearranging should always be "instant" (first result,
>> i.e. everything gets shuffled around), and aux-switcher rearranging
>> should always result in exactly two windows changing places, and
>> everything else staying put.
> 
> I agree on aux-switcher, I don't understand the primary.
> 
> Let's say I would like to exchange A + D. I would say it it natural to 
> get
> DB
> CA
> 
> what shuffle here means? I mean what is the effect of the shuffle?

If you think about it, if you are applying actions instantly, then w/o a 
switcher, you get:

+-+-+         +-+-+        +-+-+
|A|B| (right) |B|A| (down) |B|D|
+-+-+  ---->  +-+-+  --->  +-+-+
|C|D|         |C|D|        |C|A|
+-+-+         +-+-+        +-+-+

"Shuffle" just means a bunch of windows are moving around.

So one option - my original thought - was you would have actions that 
immediately exchange adjacent windows. But this moves around a lot of 
windows if what you really want to do is exchange.

Always-use-switcher is probably better for GAI; as you say you can do 
many at once, and you can still get "shuffle" behavior by just 
exchanging after every navigation action. But for TAI people are used to 
"shuffle". Hmm...

>> Thinking about switchers brings up another point; spatial
>> next/previous *does* need to stay at least for switchers that don't
>> have a concept of up/down/left/right :-). 
> 
> All of them have such concept -- TAI for example has left when it is 
> horizontal tabbar, but has down with vertical tabbar.

Switchers, not containers. A switcher can present windows as either an 
irregular grid ("expose"), where u/d/l/r do what they would outside the 
switcher, or it can present the windows in a list, where previous/next 
are the primary navigation means and u/d/l/r might mean something else. 
For instance, my example "cover" switcher, left/right are synonymous 
with previous/next, but up/down would jump to parent/child. (And because 
the windows are in a list, previous/next - meaning also left/right - 
won't correspond exactly with what they would do outside the switcher.)

> Besides, I really don't see benefit of executing action "spatial-next" 
> when I can use "spatial-right". What do I need spatial-next for?

+-+-+
|A|B|
+-+-+
|C|D|
+-+-+

Starting at A:
spatial-right: A -> B ( -> A ? )
spatial-next: A -> B -> C -> D

But as I said, it's more important for the picker, because the picker 
may present the windows in a one-dimensional list. So the WM needs to be 
able to provide an order for that list. Since you have the list anyway, 
the question is just if you expose actions to navigate using that list, 
in addition to the 2D spatial navigation.

Maybe the answer is "no" :-). I was just saying that - regardless of the 
answer - the WM will have to have such a list internally.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Any customer can have a car painted any color that he wants...
...so long as it is black." -- Henry Ford