Re: [dwm] [PATCH] An experiment with X resources
On Mon, Sep 24, 2007 at 08:50:53PM +0100, Chris Webb wrote:
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 }
[...]
}
I don't see much benefit in this design, because you have to
edit config.h anyways. And in my opinion key bindings don't
change frequently, same with appearance stuff. Hell, if
dwm configuration is such an issue, what's the problem in
extracting the dwm tarball to $HOME/.dwm and writing a dwm
wrapper script instead which calls make before starting dwm?
So you can configure dwm easily through editing
$HOME/.dwm/config.h, and you won't notice a big difference (X
usually takes longer to start up than dwm to compile)...
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] [PATCH] An experiment with X resources
On Tue, Sep 25, 2007 at 08:04:54AM +0200, Anselm R. Garbe wrote:
On Mon, Sep 24, 2007 at 08:50:53PM +0100, Chris Webb wrote:
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 }
[...]
}
I don't see much benefit in this design, because you have to
edit config.h anyways. And in my opinion key bindings don't
change frequently, same with appearance stuff. Hell, if
dwm configuration is such an issue, what's the problem in
extracting the dwm tarball to $HOME/.dwm and writing a dwm
wrapper script instead which calls make before starting dwm?
So you can configure dwm easily through editing
$HOME/.dwm/config.h, and you won't notice a big difference (X
usually takes longer to start up than dwm to compile)...
Besides this there are chances that some more tiny C compiler
might have chances for further adaption, esp. pcc (in contrast
to 8c and tcc).
Regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] [PATCH] An experiment with X resources
On Tue 25-09-2007 11:41, WyrmSkull wrote: What about having some default bash scripts keybinding? MODKEY | ShiftMask, XK_(F1 to F10), spawn, exec bash_script_(01 to 10).sh 0 byte files don't take too much space, 0 LOC, and can be edited runtime. You can add edit_keybind_(F1 to F10) dmenu entries and a change theme one. I think that DWM is ready to face those problems. You just need the right external tools. I use dwm the same way. An external script gives enough flexibility to quickly adjust the executed commands. Every other setting can just be changed by restarting dwm. The bad thing about it is that all windows lose their tag, maximized state and floating/tiled mode :-/ Instead of using Xresources, dwm could solve this issue by saving the state in the window's Xproperty. -- Jan Christoph Ebersbach Fear God and keep his commandments, for this is the whole duty of man. Eccl 12,13 signature.asc Description: Digital signature
Re: [dwm] [PATCH] An experiment with X resources
On Tue, Sep 25, 2007 at 02:20:36PM +0200, Jan Christoph Ebersbach wrote: On Tue 25-09-2007 11:41, WyrmSkull wrote: What about having some default bash scripts keybinding? MODKEY | ShiftMask, XK_(F1 to F10), spawn, exec bash_script_(01 to 10).sh 0 byte files don't take too much space, 0 LOC, and can be edited runtime. You can add edit_keybind_(F1 to F10) dmenu entries and a change theme one. I think that DWM is ready to face those problems. You just need the right external tools. I use dwm the same way. An external script gives enough flexibility to quickly adjust the executed commands. Every other setting can just be changed by restarting dwm. The bad thing about it is that all windows lose their tag, maximized state and floating/tiled mode :-/ Instead of using Xresources, dwm could solve this issue by saving the state in the window's Xproperty. I implemented tag/floating state preservation as prototype shortly before dwm 4.4 appeared. However it made the code too complex for my taste for a rarely used functionality. I prefer using hibernation technologies instead of restarting dwm. And once your setup settled there is no need to restart dwm anyways. Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] [PATCH] An experiment with X resources
Is there a way to make dwm execute commands at runtime through standard input? Would that be too complex? All functions should be there, it's just a matter of parsing user input. echo set_statusbar string | dwm normal behavior echo tag XTerm,1,2,5 | dwm XTerm gets tags 1,2,5 DWM restart problem would be solved: you could save current state in a .dwmrc, then cat .dwmrc | dwm Wyrmskull
Re: [dwm] [PATCH] An experiment with X resources
Anselm R. Garbe wrote That's exactly the proposal I had sometime ago, but it scares me that it will bring unecessary complexity Rules already have to be written manually - instead of those you could use bash scripts. xterm -- echo tag Xterm,2 | dwm This could cut the rules parts out. Keybindings could be moved to an external program too (xkeybind?). xkeybind --- key --- echo tag focused_client,2 | dwm xkeybind --- key --- exec program Is this too much a radical change? I honestly think so. Nevermind, was just an idea. Wyrmskull
Re: [dwm] [PATCH] An experiment with X resources
On Tue, Sep 25, 2007 at 03:40:04PM +0200, WyrmSkull wrote: Anselm R. Garbe wrote That's exactly the proposal I had sometime ago, but it scares me that it will bring unecessary complexity Rules already have to be written manually - instead of those you could use bash scripts. xterm -- echo tag Xterm,2 | dwm This could cut the rules parts out. Keybindings could be moved to an external program too (xkeybind?). xkeybind --- key --- echo tag focused_client,2 | dwm xkeybind --- key --- exec program Is this too much a radical change? I honestly think so. Nevermind, was just an idea. In the end customizing dwm would become more complicated than before. So I dropped that idea long time ago. (One could make this idea behave similiar than wmiirc in wmii, but then you spend hours for fine-tuning things, whereas you now spend 10 minutes). Regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] [PATCH] An experiment with X resources
On Tue 25-09-2007 14:34, Anselm R. Garbe wrote: I implemented tag/floating state preservation as prototype shortly before dwm 4.4 appeared. However it made the code too complex for my taste for a rarely used functionality. I prefer using hibernation technologies instead of restarting dwm. And once your setup settled there is no need to restart dwm anyways. Yes, you are right, I also use hibernate .. but I'd like to keep up with the dwm development and therefore I have to restart it ~twice a month ;) -- Jan Christoph Ebersbach Fear God and keep his commandments, for this is the whole duty of man. Eccl 12,13 signature.asc Description: Digital signature
Re: [dwm] [PATCH] An experiment with X resources
On 9/25/07, markus schnalke [EMAIL PROTECTED] wrote: That's information I read somewhere. I only tested, that .Xresources on it's own not gets interpreted a X init on my system (debian etch). That's debian's doing, not x.org's. X.org has always had both files; according to the X(7) man page, xdefaults should be read each time an X11 application starts, while xresources should be manually merged into the rdb via x.org init scripts. -- # Kurt H Maier
Re: [dwm] [PATCH] An experiment with X resources
On Tue, Sep 25, 2007 at 10:58:40PM +0200, markus schnalke wrote: .Xresources just want to mention, that this file's name '.Xresources' has changed to '.Xdefaults' in newer versions of X ~/.Xdefaults is read by the client on startup. (This is important for remote clients -- the ~/.Xdefaults file of the machine running the X client, not the machine running the X server, is read.) ~/.Xresources is feed to xrdb during the X session startup phase. The resources are stored by the X server (in main memory, I guess). (In the case of remote clients, the file on the machine running the X server is relevant.) Besides the machine, it is also relevant that xrdb preprocesses the file with ccp. I use that feature a lot. Kai
[dwm] [PATCH] An experiment with X resources
This morning I've been thinking about run time configuration of dwm.
I've never especially liked the compile-time rules table in config.h. The
fact that one or two programs I use happen to be broken and need a rule
with isfloating = 1 doesn't seem like something that the dwm binary
should be cluttered with. Clearly this is a matter of personal taste and
your mileage will probably vary, but it definitely grates for me. I also
have a couple of different screens and I'd like to be able to reconfigure
fonts and colours (depending on the display dwm is managing) without
keeping multiple dwm binaries in my home directory.
As an experiment, I've added support for customisation with X resources
in a branch of my own tree. To avoid growing the code too much, I
completely replaced the hard-coded rules table with a dynamic one
populated from X resources, but all other settings use config.h values as
defaults. Key bindings remain a matter for config.h. As far as I can see,
configuring these at runtime would introduce a big, ugly symbol table
into dwm for little or no gain.
Doing all this grows dwm.c less than I was originally expecting, as can
be seen from the patch. Most of the extra code is involved with
constructing the tag and rule lists rather than just to add simpler
config options like fonts and colours.
I've ported my patch back to upstream dwm (hg tip) and attached it at the
end of this message in case anyone else on the list is interested in
experimenting along the same lines. A sample .Xresources file to merge
(use xrdb -merge/-load) might be:
Dwm.bar: top
Dwm.font: -*-terminus-medium-r-*-*-12-*-*-*-*-*-iso10646-*
Dwm.normal.border: #cc
Dwm.normal.background: #ff
Dwm.normal.background: #00
Dwm.selected.border: #ff
Dwm.selected.background: #ff
Dwm.selected.foreground: #ff
Dwm.tags: 1 2 3 4 5 6 7 8 9
Dwm.rules: scratchpad browser
Dwm.properties.scratchpad: URxvt:scratch
Dwm.floating.scratchpad: True
Dwm.properties.browser: Opera
Dwm.tags.browser: 2
Cheers,
Chris.
diff -r 92c19c929a59 config.def.h
--- a/config.def.h Sun Sep 23 18:50:04 2007 +0200
+++ b/config.def.h Mon Sep 24 14:28:26 2007 +0100
@@ -1,4 +1,8 @@
/* See LICENSE file for copyright and license details. */
+
+/* resources */
+#define RESNAMEdwm
+#define RESCLASS Dwm
/* appearance */
#define BARPOS BarTop /* BarBot, BarOff */
@@ -12,14 +16,7 @@
#define SELFGCOLOR #ff
/* tagging */
-const char *tags[] = { 1, 2, 3, 4, 5, 6, 7, 8, www, NULL };
-Rule rules[] = {
- /* class:instance:title regex tags regex isfloating */
- { Firefox,www, False },
- { Gimp, NULL, True },
- { MPlayer,NULL, True },
- { Acroread, NULL, True },
-};
+#define TAGS 1 2 3 4 5 6 7 8 9
/* layout(s) */
#define ISTILE isarrange(tile) /* || isarrange(custom) */
diff -r 92c19c929a59 dwm.c
--- a/dwm.c Sun Sep 23 18:50:04 2007 +0200
+++ b/dwm.c Mon Sep 24 14:28:26 2007 +0100
@@ -40,6 +40,7 @@
#include X11/Xatom.h
#include X11/Xlib.h
#include X11/Xproto.h
+#include X11/Xresource.h
#include X11/Xutil.h
/* macros */
@@ -132,6 +133,8 @@ void *emallocz(unsigned int size);
void *emallocz(unsigned int size);
void enternotify(XEvent *e);
void eprint(const char *errstr, ...);
+void *erealloc(void *res, unsigned int size);
+char *estrdup(const char *s);
void expose(XEvent *e);
void floating(void); /* default floating layout */
void focus(Client *c);
@@ -139,7 +142,10 @@ void focusprev(const char *arg);
void focusprev(const char *arg);
Client *getclient(Window w);
unsigned long getcolor(const char *colstr);
+char *getresource(const char *resource, char *defval);
+void getrules(void);
long getstate(Window w);
+void gettags(void);
Bool gettextprop(Window w, Atom atom, char *text, unsigned int size);
void grabbuttons(Client *c, Bool focused);
unsigned int idxoftag(const char *tag);
@@ -190,11 +196,11 @@ void zoom(const char *arg);
void zoom(const char *arg);
/* variables */
-char stext[256];
+char stext[256], **tags;
double mwfact;
int screen, sx, sy, sw, sh, wax, way, waw, wah;
int (*xerrorxlib)(Display *, XErrorEvent *);
-unsigned int bh, bpos, ntags;
+unsigned int bh, bpos, ntags = 0;
unsigned int blw = 0;
unsigned int ltidx = 0; /* default */
unsigned int nlayouts = 0;
@@ -226,7 +232,9 @@ Display *dpy;
Display *dpy;
DC dc = {0};
Window barwin, root;
+Rule *rules;
Regs *regs = NULL;
+XrmDatabase xrdb;
/* configuration, allows nested code to access above variables */
#include config.h
@@ -402,7 +410,6 @@ compileregs(void) {
if(regs)
return;
- nrules = sizeof rules / sizeof rules[0];
regs = emallocz(nrules * sizeof(Regs));
for(i = 0; i nrules; i++) {
Re: [dwm] [PATCH] An experiment with X resources
Anselm R. Garbe [EMAIL PROTECTED] writes:
The only questionable issue I don't like is the strsep(3) use,
because of portability concerns.
Failing all else, I guess a strsep() tokeniser
while(tag = strsep(line, \t\n)) {
if(!tag[0])
continue;
tags = erealloc(tags, sizeof(char *) * ++ntags);
tags[ntags - 1] = tag;
}
can always be expanded to something like this
do {
tag = line;
if (line = strpbrk(line, \t\n))
*line++ = '\0';
if !tag[0]
continue;
tags = erealloc(tags, sizeof(char *) * ++ntags);
tags[ntags - 1] = tag;
} while (line);
assuming strpbrk is reasonably universal.
Cheers,
Chris.
Re: [dwm] [PATCH] An experiment with X resources
Chris Webb -- dwm (2007-09-24 14:30:23 +0100):
This morning I've been thinking about run time configuration of dwm.
[...]
I only glanced at the code, but this seems to be a useful idea!
+void *
+erealloc(void *res, unsigned int size) {
+ if (!(res = res ? realloc(res, size) : malloc(size)))
+ eprint(fatal: could not realloc() %u bytes\n, size);
+ return res;
+}
Hmm, why using the ternary operator? Are there systems where
`realloc(NULL, size)' does not behave identically to `malloc(size)'?
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] [PATCH] An experiment with X resources
Jukka Salmi [EMAIL PROTECTED] writes: Hmm, why using the ternary operator? Are there systems where `realloc(NULL, size)' does not behave identically to `malloc(size)'? I remember some old unix systems that segfault if you pass realloc a null pointer! I haven't seen anything like that for a long time, though, and I think ISO C now specifies that realloc(NULL, size) is the same as malloc(size), so I was probably just being over-paranoid. Cheers, Chris.
Re: [dwm] [PATCH] An experiment with X resources
http://www.opengroup.org/onlinepubs/009695399/functions/realloc.html 2007/9/24, Chris Webb [EMAIL PROTECTED]: Jukka Salmi [EMAIL PROTECTED] writes: Hmm, why using the ternary operator? Are there systems where `realloc(NULL, size)' does not behave identically to `malloc(size)'? I remember some old unix systems that segfault if you pass realloc a null pointer! I haven't seen anything like that for a long time, though, and I think ISO C now specifies that realloc(NULL, size) is the same as malloc(size), so I was probably just being over-paranoid. Cheers, Chris.
Re: [dwm] [PATCH] An experiment with X resources
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.
Re: [dwm] [PATCH] An experiment with 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 did something similar without .Xresources. I have several keybindings that call shell scripts from ~/.scripts. Some output to a fifo to dwm's status bar, and some output directly to x, but either way, these scripts were the first thing I did to circumvent the inflexibility of compiled-in keybindings. I just edit the shell scripts, and the keybinding works differently as I want to change it. -- # Kurt H Maier
