"Anselm R. Garbe" <[EMAIL PROTECTED]> writes: > it won't last long that the need arises to also configure the key > bindings, and the terminal command, and the dmenu command, and what not > using such capabilities.
Actually... :-) What wasn't in that patch, but is in my tree, is a little convenience function that lets you define commands by name in .Xresources: Dwm.command.xterm: urxvt -bg red Dwm.command.browser: opera and then bind them in config.h Key keys[] = { [...] { MODKEY, XK_Return, spawn_command, "xterm" } { MODKEY | ShiftMask, XK_Return, spawn_command, "browser" } [...] } At present, my spawn_command is a no-op if the corresponding Dwm.command.* X resource isn't defined. Unfortunately, to do this requires that xrdb doesn't get freed at the end of setup(), so I need to rethink this a bit before I'll be happy with it. I also now configure my mwfact, nmaster, nrows and ncols parameters for my 'supertile()' through X resources. For me, this gives a sweet spot between runtime configurability and keeping code complexity low, with compiled-in key bindings which are constant across all the systems I use, but runtime configurable colours, rules, tag names and commands, which vary from system to system. I used X resources not because I think they're a nice system per se, but rather because I end up having to use them for other X apps anyway. I didn't fancy trying to express a rules table as a command line argument or environment variable! > Besides this, the X resource file format always seemed insane to me. Yes, I agree. Many of the design choices in Xlib are baroque to the point of insanity. Cheers, Chris.