[Michael ROGERS <M.Rogers@cs.ucl.ac.uk>] Re: [wmx] Why I use wmx (fwd)

Subject: Re: [wmx] Why I use wmx (fwd)
Date: Fri, 23 Apr 1999 16:25:21 +0100
From: Michael ROGERS <M.Rogers@cs.ucl.ac.uk>


>The other thing I think would be nice, as discussed, is to allow
>right-clicks `through' to the root window.  That way some other random
>program (gmc, whatever) can catch them & provide menus.  wmg could
>then restrict itself to providing the basics:
>
>        window list
>        new xterm
>        exit

 I've implemented this if anyone wants the patch. It's only a few lines and it 
shouldn't cause any problems if you run an X session without Gnome. It means 
the right-click circulating behaviour doesn't work anymore, though.
The patch is for wm2... I'll have a look at wmx tonight and see if I can paste
it in.

>Another thing: currently there's a single codebase.  Is splintering it
>such a good idea?  I feel it's getting sort of fractured internally
>already, what with the dynamic config stuff, and all those other
>#ifdefs, and at some point it's going to become just insanely
>complicated & fall apart.  Is there a better way of doing this, and
>yet still adding features?  Something other than the C preprocessor,
>perhaps?

 I guess (although my knowledge of compilers is very scant) that using the
preprocessor is the most efficient possible method, since unselected options 
never even make it to the compiler. I don't know what practical difference it 
would make to performance or binary size to use command line options or X
resources to select your options. This would allow the code to be tidied up
and unified a bit (not that I'm volunteering!).

 I decided to make a clean break from the wm2/wmx source with my Gnome 
compliance project because initially I thought it would be dependent on Gnome
and GTK to run. It now looks like I might be able to implement everything
except the gnome-session interface using Xlib, which raises the possibility of
submitting yet more #ifdef-ed patches to be merged back into wmx (for MWM
window hints, a different border appearance, and shaped window support). In 
light of the number of options already present in Config.h (and those 
suggested recently on this list), it seems that wmx has moved beyond wm2's 
anti-configurability position. Maybe it's worth admitting this and abandoning 
the "To reconfigure, simply edit and recompile" stance. Anyone who is hardline
opposed to this can always stick with the current version of wmx.


 - Michael Rogers


A smile, a song, and an unfounded generalisation