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

From: Riccardo Murri <>
Date: Sat, 27 Oct 2007 20:02:38 +0000 (UTC)

Il 2007-10-27, Anselm R. Garbe <> ha scritto:
> I could imagine a proceed() function which each layout
> should implement a la:
> Bool
> proceed(void (*func)(const char *)) {
> if(isarrange(tile))
> return func == setmwfact
> || func == zoom
> || func == togglefloating;
> return False;
> }
> Then, instead of ISTILE, we could perform in zoom() for example:
> if(!layouts[ltidx].proceed(zoom))
> return;
> But this will make it necessary that the proceed-check function
> is set in the Layout's definition in config.h (however not every
> layout would need to reinvent the proceed function!).

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;

  The prototypical `init` function would be::

    void tile_init(LayoutOps* lops) {
      lops->arrange = arrange;
      lops->proceed = proceed;

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.


P.S. I think `supports()` would be a better name than `proceed()`.

Riccardo Murri, via Galeazzo Alessi 61, 00176 Roma
Received on Sat Oct 27 2007 - 22:05:04 UTC

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