Il 2007-10-27, Anselm R. Garbe <[EMAIL PROTECTED]> 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/
