Re: [dwm] way towards 5.0

On Sat, May 17, 2008 at 04:05:16PM +0200, Anselm R. Garbe wrote:
> Here are the most recent changes I did to the codebase today
> (most stuff towards 5.0 is done now).
>
> - DEFGEOM is replaced by a function updategeom(), and a function
> pointer updategeom in each layout definition
>
> - removed Client->{fx,fy,fw,fh}
>
> - removed reapply()
>
> - removed tileh*, counttiled(), etc stuff
>
> - moved all tile-related stuff to tile.c, which is included in
> config.h. tile.c contains tile(), setmfact(), zoom() and a new
> updatetilegeom() function. tile.c also includes the definition
> of mfact, m{x,y,w,h} and t{x,y,w,h}
>
> - renamed nexttiled() into nextunfloating()
>
> - removed monocle (temporarily until I write this monocle
> meta-layout which will be toggled when Mod1-m is pressed)

I vote for essentially keeping current (4.9) monocle functionality as a
poor men's appoximation to tabbing. It's _much_ better than
maximization on a per-window basis. consider, e.g., the following
scenario: use of numerical software producing a modest number (say 3-4)
of 2D-plots in separarte windows (think `octave' or `R'). inspecting
such output sensibly is at the very least tedious in tiled layout (what
with moving back and forth to the master area). `monocle' is just fine
for such tasks: cycling through a number of "equally important" windows
rapidly and with ease.

I generally would argue for a middle way between "support every
imaginable fancy layout" and "support only one layout which is THE LAW
and optimal by definition". currently I feel `standard tiling', 'floating',
`monocle' are important, but multi-column tiling does not make much
sense to me (but it's availability does'nt harm either). being to
restrictive w.r.t. layouts is, for me, definitely as bad as making it
"infinitely" configurable.

I further think switching back and forth between floating and tiling
should be "conservative" in the sense that the floating configuration
which has been arranged manually should be restored as far as possible
on the next "visit" to floating layout. alternatively, the switch
between layouts should (optitionally?) occur on a per-tag basis instead
globally in order to avoid unintentional destroy of a manually optimized
floating layout in another tag.

>
> - renamed setlayout() into togglelayout()
>
> This means, that if tile.c isn't included in config.def.h, dwm
> can be used as a floating wm, which provides all core
> functionality and our tagging approach.
>
> This also means, that for people like me, who use a multihead
> setup sometimes, can include a hacked version of tile.c which
> provides a different updatetilegeom() and maybe a slightly
> different tile() algorithm itself.
>
> Conceptually this is now rather clean, because we also get rid
> of Bool dozoom/domfact due to the code organization, that all
> tile-related functions are in tile.c now and can check if
> lt->arrange == tile, and then perform the necessary function or
> decline.
>
> The Layout interface hasn't changed much in this regard.
>
> I plan to add some more convenience toggles to config.def.h to
> influence the default updategeom() function a little bit for the
> bar geometry/position.
>
> Do people prefer having a fine-grain bar positioning setup or is
> it more preferred to have a bar setup in the sense "top or
> bottom"? I still believe the latter idea is nicer, if someone
> wants to use dzen, patch updategeom on you own.
>
> Let me know how welcome do you feel about those changes. Bug
> reports are also welcome.
>
> Kind regards,
> --
> Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
>
Received on Mon May 19 2008 - 13:24:46 UTC