Re: [wmii] Dynamicness, Window Sizes (again, sorry) and Xinerama.

OK, I had a planned detailed and thoughtful reply, but that
was messy, so let's cut to the chase. I have been using
the new snaps for a few weeks now, and after getting
used to them, I am still dissatisfied. This is because I think
wmii (or at least it's default key bindings?) only works well when

  (a) You are happy with one full screen column or two equal
          columns, AND

  (b) You only want basic operations for moving clients between cols.

When these conditions are met, you just keep yourself
in stacked or max mode and let $MODKEY-j/k do the
rest, occasionally you do something more fancy.
This is similar to the preferred way of using MS-Windows,
which is to maximise everything and cycle with Alt-Tab.

Surprisingly, I find my trouble lies with (a). I want
to manage column sizes from within wmiirc. At
work this is because my screen is small so I always
want the most important column to be big, at home
I want it so I can implement better Xinerama support.

When I started scripting I ran into problems because
could not know when a new column was created,
(well presumably it's after Alt-Shift-n, but is it synchronous?).
Really I don't want to know when a new col is created,
the easiest thing for a script writer is to simply tell
wmii "when columns come up, prefer these boundaries", rather
than catching and redoing every column-shifting event.

Suppose I solve my problems with restriction (a), one way or
another. This brings in restriction (b). When all columns
were equal I am happy to keep clients where they are, most
of the time, but if one column is "better" than the others,
I want easy ways of moving clients in and out of that column.
This is the "old usage pattern" that Alt-Enter and Alt-Tab
gave me in 2.5, they corresponded to powerful operations
over the *whole view*, rather than a single column.

> Anyway, I don't recommend to use the column layout in such old
> usage patterns, instead I recommend to unlearn what you knew and
> try to get used to the column layout. You'll notice after some
> time, once you got familiar especially with the shortcuts:
>
> $MODKEY-h/j/k/l
> $MODKEY-Shift-n (new column)
> $MODKEY-Shift-h/l (move prev/next)
> $MODKEY-Control-h/l (swap prev/next)
> $MODKEY-d
> $MODKEY-s
> $MODKEY-m
>
> You'll notice that column layout is adaptable more efficiently
> to each situation, than the layouts we got before. Not only
> because tiled or grid layout scaled badly, also because the
> basic mechanisms are reduced to a bunch of core key bindings.

I agree the column layout is beautifully expressive, but the
fact is that if we care about the whole view as a single entity,
there are now 12 low level operations which you compose to get
what you want. This composition must take into account the
particular placement of your windows on the screen right now
(you didn't care about that when you just cycled with
$MODKEY-j/k, or Alt-Tab).

For this reason lifting restriction (b) requires higher level
operations, ones that can operate on the whole view. Such
can probably be scripted easily as things stand now. But
that will only be useful after restriction (a) is lifted.

My ramblings about a "fixed landscape" (where fixed means scriptable)
brings in both of these. The "landscape" gives hints to wmii
about where to place future column borders. If such a landscape
is known, the high level (b)-lifting shell routines might also
be easier to write.

P.S. when I get around to putting my time&effort where my mouth
is, what is the preferred development method? Work with
anon-access to the repository and then send a patch to Anselm?
Received on Wed Apr 12 2006 - 22:15:43 UTC