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

Il 2007-10-27, Anselm R. Garbe <arg_AT_suckless.org> 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.

Riccardo

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

-- 
Riccardo Murri, via Galeazzo Alessi 61, 00176 Roma
http://chargen.blogspot.com/