Re: [dwm] [PATCH] replacing "#define ISTILE" by "Bool istile"

From: Anselm R. Garbe <>
Date: Sun, 28 Oct 2007 11:00:54 +0100

On Sat, Oct 27, 2007 at 08:02:38PM +0000, Riccardo Murri wrote:
> I like this `proceed` idea, although binding it to a layout in
> config.h seems not the correct way to go -- each layout has its own
> specific `proceed` function, which is not a configurable option.
> I can imagine doing it this way:
> 1. add a `struct LayoutOps`::
> typedef struct {
> void (*arrange)(void);
> void (*proceed)(void (*func)(const char *));
> /* any other func depending on layout? */
> } LayoutOps;
> 2. change `struct Layout` to::
> typedef struct {
> const char *symbol;
> void (*init)(LayoutOps* lops);
> } Layout;

Hmm, that looks a little bit overdesigned in my eyes.

> 3. At DWM start, allocate a LayoutOps[] of the same size as LAYOUTS,
> and, for each entry in LAYOUTS, call Layout->init(corresponding_lops).
> OTOH, this would make the LAYOUTS definition uglier (one has to write
> "tile_init" not "tile", which is less natural) and adds extra
> complexity just to avoid the chance of defining a layout with the
> `proceed`-function not matching the `arrange` one. Not sure it's
> worth the effort.
> Riccardo
> P.S. I think `supports()` would be a better name than `proceed()`.

Let's concentrate on the problem. There is zoom() and setmwfact()
which heavily depend on tile() in vanilla dwm. tile()-similiar
layouts would like to re-use zoom() and setmwfact() in one or
another way. Hence we come down to two Bool's dozoom
and domwfact - from a vanilla dwm point of view, which is
the only one I really care (though making it easy for extensions as well).

So without changing a lot I see the following simple solution
compared to everything else:

- replace ISTILE with

Bool dozoom, domwfact;

- at the beginning of floating():

dozoom = domwfact = False;

- at the beginning of tile():

dozoom = domwfact = True;

(all in all 2 additional lines).

3rd party layouts can check in their specific void foo(const char *arg)
functions if the custom == layout->arrange and depend on this.

I believe that's the most simple and problem-specific solution,
without adding too much complexity/flexibility.

Btw. I plan to drop ltidx, - that is an artifact of the attempt
to separate layouts during 4.4 -> 4.6 development. Instead I
will readd a Layout *layout; pointer again, which points to the
current layout in use. Dunno yet if isarrange() is going to be
removed as well, because one could easily check against
layout->arrange instead.


 Anselm R. Garbe >< >< GPG key: 0D73F361
Received on Sun Oct 28 2007 - 11:00:54 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:03:17 UTC