[dwm] [patch] minor cleanups
Hi,
attached are two minor cleanups. The first simplifies grabkeys()
similar to grabbuttons().
The second removes isurgent() and isoccupied(). This also means that
we need to loop over all clients only once in drawbar() now.
Cheers,
Johannes
diff -r 40cd44593977 -r 4cae21457969 dwm.c
--- a/dwm.c Sat Aug 02 19:12:15 2008 +0100
+++ b/dwm.c Mon Aug 04 17:46:20 2008 +0200
@@ -159,9 +159,7 @@ static void grabbuttons(Client *c, Bool
static void grabbuttons(Client *c, Bool focused);
static void grabkeys(void);
static void initfont(const char *fontstr);
-static Bool isoccupied(unsigned int t);
static Bool isprotodel(Client *c);
-static Bool isurgent(unsigned int t);
static void keypress(XEvent *e);
static void killclient(const Arg *arg);
static void manage(Window w, XWindowAttributes *wa);
@@ -500,19 +498,23 @@ die(const char *errstr, ...) {
void
drawbar(void) {
- int i, x;
+ int x;
+ unsigned int i, occ = 0, urg = 0;
+ unsigned long *col;
+ Client *c;
+
+ for(c = clients; c; c = c-next) {
+ occ |= c-tags;
+ if(c-isurgent)
+ urg |= c-tags;
+ }
dc.x = 0;
for(i = 0; i LENGTH(tags); i++) {
dc.w = TEXTW(tags[i]);
- if(tagset[seltags] 1 i) {
- drawtext(tags[i], dc.sel, isurgent(i));
- drawsquare(sel sel-tags 1 i, isoccupied(i),
isurgent(i), dc.sel);
- }
- else {
- drawtext(tags[i], dc.norm, isurgent(i));
- drawsquare(sel sel-tags 1 i, isoccupied(i),
isurgent(i), dc.norm);
- }
+ col = tagset[seltags] 1 i ? dc.sel : dc.norm;
+ drawtext(tags[i], col, urg 1 i);
+ drawsquare(sel sel-tags 1 i, occ 1 i, urg 1
i, col);
dc.x += dc.w;
}
if(blw 0) {
@@ -741,7 +743,7 @@ grabbuttons(Client *c, Bool focused) {
if(buttons[i].click == ClkClientWin)
for(j = 0; j LENGTH(modifiers); j++)
XGrabButton(dpy, buttons[i].button,
buttons[i].mask | modifiers[j], c-win, False, BUTTONMASK, GrabModeAsync,
GrabModeSync, None, None);
-} else
+ } else
XGrabButton(dpy, AnyButton, AnyModifier, c-win, False,
BUTTONMASK, GrabModeAsync, GrabModeSync, None,
None);
}
@@ -749,6 +751,7 @@ void
void
grabkeys(void) {
unsigned int i, j;
+ unsigned int modifiers[] = { 0, LockMask, numlockmask,
numlockmask|LockMask };
KeyCode code;
XModifierKeymap *modmap;
@@ -764,14 +767,9 @@ grabkeys(void) {
XUngrabKey(dpy, AnyKey, AnyModifier, root);
for(i = 0; i LENGTH(keys); i++) {
code = XKeysymToKeycode(dpy, keys[i].keysym);
- XGrabKey(dpy, code, keys[i].mod, root, True,
- GrabModeAsync, GrabModeAsync);
- XGrabKey(dpy, code, keys[i].mod|LockMask, root, True,
- GrabModeAsync, GrabModeAsync);
- XGrabKey(dpy, code, keys[i].mod|numlockmask, root, True,
- GrabModeAsync, GrabModeAsync);
- XGrabKey(dpy, code, keys[i].mod|numlockmask|LockMask, root,
True,
- GrabModeAsync, GrabModeAsync);
+ for(j = 0; j LENGTH(modifiers); j++)
+ XGrabKey(dpy, code, keys[i].mod | modifiers[j], root,
True,
+GrabModeAsync, GrabModeAsync);
}
}
@@ -816,16 +814,6 @@ initfont(const char *fontstr) {
}
Bool
-isoccupied(unsigned int t) {
- Client *c;
-
- for(c = clients; c; c = c-next)
- if(c-tags 1 t)
- return True;
- return False;
-}
-
-Bool
isprotodel(Client *c) {
int i, n;
Atom *protocols;
@@ -838,16 +826,6 @@ isprotodel(Client *c) {
XFree(protocols);
}
return ret;
-}
-
-Bool
-isurgent(unsigned int t) {
- Client *c;
-
- for(c = clients; c; c = c-next)
- if(c-isurgent c-tags 1 t)
- return True;
- return False;
}
void
[dwm] click to focus no longer works
Hi, with current tip (118ea4f4f554) it seems no longer possible to focus a client by clicking it with the left mouse button. To reproduce move the mouse over the stack, focus the main window using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not possible to focus the window under the mouse by clicking on it. Regards, Johannes
Re: [dwm] click to focus no longer works
On Sat, Jun 14, 2008 at 06:31:31PM +0200, yy wrote:
2008/6/14 Johannes Hofmann [EMAIL PROTECTED]:
Hi,
with current tip (118ea4f4f554) it seems no longer possible to focus
a client by clicking it with the left mouse button.
To reproduce move the mouse over the stack, focus the main window
using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not
possible to focus the window under the mouse by clicking on it.
Regards,
Johannes
It's true, this is something I changed in my dwm after sending the
patch to the list (I didn't know it was going to be applied). This (in
buttonpress()) will do the trick:
else if((c = getclient(ev-window))) {
click = ClkClientWin;
focus(c);
}
Yes, that fixes it. Thanks!
Johannes
[dwm] tile bug if window has size of screen
Hi, in tip I see a weirdness whenever a new client has exactly the size of the screen. On my laptop e.g. xpdf -geometry 1400x1050 makes the tiled layout go crazy. bisect shows that 941bd7c15a32 introduced this behaviour. Cheers, Johannes
Re: [dwm] way towards 5.0
On Thu, May 22, 2008 at 08:17:47PM +0200, Antoni Grzymala wrote: Anselm R. Garbe dixit (2008-05-17, 16:05): - removed reapply() [...] Let me know how welcome do you feel about those changes. Bug reports are also welcome. I'm not sure removing reapply() and forcing people to restart dwm is a neat idea for those using logon managers. Quitting dwm ends my Xsession, kills the X clients and takes me back to xdm. Perhaps I'm missing something, if so, please clarify. You can put a loop in .xinitrc that restarts dwm automatically. I have: while true do echo temp $((`sysctl -n hw.acpi.thermal.tz0.temperature`/10-273))°C batt `sysctl -n hw.acpi.battery.life`% sleep 1 done | while true; do dwm done which works fine with xdm. Cheers, Johannes
[dwm] simplify grabbuttons()
Hello,
below is a patch that shortens grabbuttons() a bit.
Cheers,
Johannes
PS: I really appreciate the attitude to reconsider everything from
time to time - even though I'm quite satisfied with current dwm.
diff --git a/dwm.c b/dwm.c
--- a/dwm.c
+++ b/dwm.c
@@ -805,36 +805,18 @@
void
grabbuttons(Client *c, Bool focused) {
+ unsigned int Buttons[] = {Button1, Button2, Button3};
+ unsigned int Modifiers[] = {MODKEY, MODKEY|LockMask,
+ MODKEY|numlockmask, MODKEY|numlockmask|LockMask};
+ int i, j;
+
XUngrabButton(dpy, AnyButton, AnyModifier, c-win);
- if(focused) {
- XGrabButton(dpy, Button1, MODKEY, c-win, False, BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button1, MODKEY|LockMask, c-win, False,
BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button1, MODKEY|numlockmask, c-win, False,
BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button1, MODKEY|numlockmask|LockMask, c-win,
False, BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
-
- XGrabButton(dpy, Button2, MODKEY, c-win, False, BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button2, MODKEY|LockMask, c-win, False,
BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button2, MODKEY|numlockmask, c-win, False,
BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button2, MODKEY|numlockmask|LockMask, c-win,
False, BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
-
- XGrabButton(dpy, Button3, MODKEY, c-win, False, BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button3, MODKEY|LockMask, c-win, False,
BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button3, MODKEY|numlockmask, c-win, False,
BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- XGrabButton(dpy, Button3, MODKEY|numlockmask|LockMask, c-win,
False, BUTTONMASK,
- GrabModeAsync, GrabModeSync, None, None);
- }
+ if(focused)
+ for (i = 0; i LENGTH(Buttons); i++)
+ for (j = 0; j LENGTH(Modifiers); j++)
+ XGrabButton(dpy, Buttons[i], Modifiers[j],
c-win, False,
+ BUTTONMASK, GrabModeAsync,
GrabModeSync, None, None);
else
XGrabButton(dpy, AnyButton, AnyModifier, c-win, False,
BUTTONMASK,
GrabModeAsync, GrabModeSync, None, None);
Re: [dwm] new setgeom in hg tip
Hi, first of all thanks a lot for dmw! Works great for me. On Sat, Mar 15, 2008 at 03:59:35PM +0100, Anselm R. Garbe wrote: Hi there, I thought about all those feedback mails so far and implemented a new setgeom function which expects a certain input syntax. I'm not confident yet if this approach will stay, but what do you think about it? Huh? That's a config parser in dwm! I'd prefer to stay with plain C to configure dwm. It has a well known syntax and is parsed at compile time. Cheers, Johannes
Re: [dwm] new setgeom in hg tip
On Sat, Mar 15, 2008 at 05:55:11PM -0300, Brendan MacDonell wrote:
On Sat, Mar 15, 2008 at 5:30 PM, Johannes Hofmann
[EMAIL PROTECTED] wrote:
Huh? That's a config parser in dwm!
Luckily I'd say, since otherwise we'd seem to be stuck hardcoding
values for screen sizes as 24-line functions for each set of geoms.
This config parser isn't really much different from the regexes that
were used in config.h for matching windows, nor is it difficult to
understand, so I have no objections.
What do you think of the attached patch (against 4.8)? It reduces
the setgeoms() function a bit - agreed, not very much :-)
But you only need a custom setgeoms () function for multiscreen
setups anyway.
Johannes
diff --git a/config.anselm.h b/config.anselm.h
--- a/config.anselm.h
+++ b/config.anselm.h
@@ -37,40 +37,34 @@ setanselmgeoms(void) {
setanselmgeoms(void) {
/* screen dimensions */
- sx = 0;
- sy = 0;
- sw = DisplayWidth(dpy, screen);
- sh = DisplayHeight(dpy, screen);
+ scr.x = 0;
+ scr.y = 0;
+ scr.w = DisplayWidth(dpy, screen);
+ scr.h = DisplayHeight(dpy, screen);
/* bar position */
- bx = sx;
- by = sy;
- bw = 1280;
- bh = dc.font.height + 2;
+ bar = scr;
+ bar.w = 1280;
+ bar.h = dc.font.height + 2;
/* window area */
- wx = sx;
- wy = sy + bh;
- ww = sw;
- wh = sh - bh;
+ win = scr;
+ win.y += bar.h;
+ win.h -= bar.h;
/* master area */
- mx = wx;
- my = wy;
- mw = 1280;
- mh = 800 - bh;
+ mas = win;
+ mas.w = 1280;
+ mas.h = 800 - bar.h;
/* tile area */
- tx = 1280;
- ty = 0;
- tw = sw - 1280;
- th = sh;
+ til.x = 1280;
+ til.y = 0;
+ til.w = scr.w - 1280;
+ til.h = scr.h;
/* monocle area */
- mox = mx;
- moy = my;
- mow = mw;
- moh = mh;
+ mon = mas;
}
void
diff --git a/dwm.c b/dwm.c
--- a/dwm.c
+++ b/dwm.c
@@ -69,6 +69,10 @@ struct Client {
Client *snext;
Window win;
};
+
+typedef struct {
+ int x, y, w, h;
+} Rectangle;
typedef struct {
int x, y, w, h;
@@ -193,9 +197,10 @@ void zoom(const char *arg);
/* variables */
char stext[256], buf[256];
-int screen, sx, sy, sw, sh;
+int screen;
int (*xerrorxlib)(Display *, XErrorEvent *);
-int bx, by, bw, bh, blw, mx, my, mw, mh, mox, moy, mow, moh, tx, ty, tw, th,
wx, wy, ww, wh;
+int blw;
+Rectangle scr, bar, win, mas, til, mon;
unsigned int numlockmask = 0;
void (*handler[LASTEvent]) (XEvent *) = {
[ButtonPress] = buttonpress,
@@ -296,7 +301,7 @@ ban(Client *c) {
ban(Client *c) {
if(c-isbanned)
return;
- XMoveWindow(dpy, c-win, c-x + 2 * sw, c-y);
+ XMoveWindow(dpy, c-win, c-x + 2 * scr.w, c-y);
c-isbanned = True;
}
@@ -408,7 +413,7 @@ configurenotify(XEvent *e) {
configurenotify(XEvent *e) {
XConfigureEvent *ev = e-xconfigure;
- if(ev-window == root (ev-width != sw || ev-height != sh)) {
+ if(ev-window == root (ev-width != scr.w || ev-height != scr.h)) {
setgeoms();
updatebarpos();
arrange();
@@ -426,17 +431,17 @@ configurerequest(XEvent *e) {
c-border = ev-border_width;
if(c-isfixed || c-isfloating || lt-isfloating) {
if(ev-value_mask CWX)
- c-x = sx + ev-x;
+ c-x = scr.x + ev-x;
if(ev-value_mask CWY)
- c-y = sy + ev-y;
+ c-y = scr.y + ev-y;
if(ev-value_mask CWWidth)
c-w = ev-width;
if(ev-value_mask CWHeight)
c-h = ev-height;
- if((c-x - sx + c-w) sw c-isfloating)
- c-x = sx + (sw / 2 - c-w / 2); /* center in x
direction */
- if((c-y - sy + c-h) sh c-isfloating)
- c-y = sy + (sh / 2 - c-h / 2); /* center in y
direction */
+ if((c-x - scr.x + c-w) scr.w c-isfloating)
+ c-x = scr.x + (scr.w / 2 - c-w / 2); /*
center in x direction */
+ if((c-y - scr.y + c-h) scr.h c-isfloating)
+ c-y = scr.y + (scr.h / 2 - c-h / 2); /*
center in y direction */
if((ev-value_mask (CWX|CWY))
!(ev-value_mask (CWWidth|CWHeight)))
configure(c);
@@ -519,13 +524,13 @@ drawbar(void) {
drawtext(lt-symbol, dc.norm, False);
x = dc.x + dc.w;
dc.w = textw(stext);
- dc.x = bw - dc.w;
+ dc.x = bar.w - dc.w;
if(dc.x x) {
dc.x = x
[dwm] dwm and fltk apps
Hello, thank you very much for dwm. It's simply great! I have a minor annoyance with fltk (http://www.fltk.org) apps. On startup, they show a white window with the default fltk window position and size. Only later they get moved and resized to the correct position by dwm. This is mostly visible on slow or loaded systems. I understand that this is most probabely a fltk issue as other toolkits work fine, but perhaps someone on the list has an idea about this problem. Johannes
