Switchers as arrangement managers

[Maciej Pilichowski]

On Saturday 02 May 2009 02:09:13 Matthew Woehlke wrote:

> >   And for auxiliary switchers, the same
> > EXCH+[aux.keyboard.shortcut] runs auxiliary switcher in exchange
> > mode.
>
> Um... Okay, I think I see how this would work, in this mode you
> would pick a window, and the currently active window would be
> switched with the picked window (which need not have the same
> parent!).

Yes.

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

> Tapping one of the former is 
> effectively "quick switch without a switcher"; I'd envision
> rearrangement to be more like that than 'use the switcher'.

It can be done for any key, all it takes is to check if there is 
a "tap" or really key pressing.

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

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

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

>  do you mean that you
> would rearrange by using a switcher, always in 'exchange two
> windows' mode, by doing like you are going to switch, then using a
> 'swap this and currently-active window' button?

Yes. This way we could use one shortcut only, plus you could exchange 
several windows in one pass.

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

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?

And from what I see already, well, intuition rather, I would rather 
use smart-switch most of the time. 

> (Which is to say, the WM 
> will need to have a concept of all windows of a given parent in two
> ordered one-dimensional lists; one for spatial,

It is an implementation part, if it is a list or array it should not 
be discussed at the UI level (not that I don't want to discuss it, 
but I think it is too premature, let's finish the UI first). IMHO.

Cheers,