On Mon, Sep 24, 2007 at 07:00:19AM +0200, Alpt wrote:
How is it possible to catch a buttonpress event outside any window, without
messing up everything?
Yes, you should only grab the root window if the input focus is
on the root window (you could even passively grab the pointer in
such a case).
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
On Mon, Sep 24, 2007 at 08:49:26AM +0200, Anselm R. Garbe:
~ Yes, you should only grab the root window if the input focus is
~ on the root window (you could even passively grab the pointer in
~ such a case). Whenever the pointer enters a
~ child window of the root window you should immediately
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;
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) :
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
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
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
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
