"Anselm R. Garbe" <arg_AT_suckless.org> 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.
Received on Mon Sep 24 2007 - 21:50:56 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 14:55:24 UTC