Re: [dwm] New client on bottom instead of top
On (20/04/08 05:15), Ruben Gonzalez Arnau wrote:
To: dwm@suckless.org
From: Ruben Gonzalez Arnau [EMAIL PROTECTED]
Subject: [dwm] New client on bottom instead of top
Reply-To: dynamic window manager dwm@suckless.org
List-Id: dynamic window manager dwm.suckless.org
Hello,
What is the way to get new client at bottom instead of top? By default,
when a new client is launched it goes to the top of my clients, I just
want that new client goes to bottom(like wmii). Wich function do I need to
modify? zoom,attach? :P
any hint? :)
Lot of thanks.
Yes, it's attach() :)
try something like this:
void
attach(Client *c) {
if (clients) {
Client *last;
for (last = clients; last-next; last = last-next);
last-next = c;
c-prev = last;
c-next = NULL;
}
else
clients = c;
}
-Ph
[dwm] Compile time initialization of lt and geom
Hi,
both Layout *lt and Geom *geom can be initialized in compile time:
diff -r 4accc080ae2e -r 2fc025a5a54f dwm.c
--- a/dwm.c Sun Apr 20 00:13:19 2008 +0200
+++ b/dwm.c Sun Apr 20 00:15:30 2008 +0200
@@ -239,14 +239,15 @@ Cursor cursor[CurLast];
Cursor cursor[CurLast];
Display *dpy;
DC dc = {0};
-Geom *geom = NULL;
-Layout *lt = NULL;
Window root, barwin;
/* configuration, allows nested code to access above variables */
#include config.h
#define TAGSZ (LENGTH(tags) * sizeof(Bool))
static Bool tmp[LENGTH(tags)];
+
+Layout *lt = layouts;
+Geom *geom = geoms;
/* function implementations */
@@ -1483,7 +1484,6 @@ setup(void) {
sh = DisplayHeight(dpy, screen);
bh = dc.font.height + 2;
mfact = MFACT;
- geom = geoms[0];
geom-apply();
/* init atoms */
@@ -1518,9 +1518,6 @@ setup(void) {
seltags = emallocz(TAGSZ);
prevtags = emallocz(TAGSZ);
seltags[0] = prevtags[0] = True;
-
- /* init layouts */
- lt = layouts[0];
/* init bar */
for(blw = i = 0; LENGTH(layouts) 1 i LENGTH(layouts); i++) {
-Ph
[dwm] Anothor (this time semi-) simplification
Hi,
this patch creates macros MAX and MIN, and use it where it is possible.
-Ph
diff -r 1a0cf77c2345 dwm.c
--- a/dwm.c Sun Apr 20 12:49:18 2008 +0200
+++ b/dwm.c Sun Apr 20 15:18:46 2008 +0200
@@ -41,6 +41,8 @@
#include X11/Xutil.h
/* macros */
+#define MAX(a, b) ((a)(b)?(a):(b))
+#define MIN(a, b) ((a)(b)?(a):(b))
#define BUTTONMASK (ButtonPressMask|ButtonReleaseMask)
#define CLEANMASK(mask) (mask ~(numlockmask|LockMask))
#define LENGTH(x) (sizeof x / sizeof x[0])
@@ -605,9 +607,8 @@ drawtext(const char *text, unsigned long
if(!text)
return;
w = 0;
- olen = len = strlen(text);
- if(len = sizeof buf)
- len = sizeof buf - 1;
+ olen = strlen(text);
+ len = MIN(olen, sizeof buf - 1);
memcpy(buf, text, len);
buf[len] = 0;
h = dc.font.ascent + dc.font.descent;
@@ -884,10 +885,8 @@ initfont(const char *fontstr) {
font_extents = XExtentsOfFontSet(dc.font.set);
n = XFontsOfFontSet(dc.font.set, xfonts, font_names);
for(i = 0, dc.font.ascent = 0, dc.font.descent = 0; i n; i++) {
- if(dc.font.ascent (*xfonts)-ascent)
-dc.font.ascent = (*xfonts)-ascent;
- if(dc.font.descent (*xfonts)-descent)
-dc.font.descent = (*xfonts)-descent;
+ dc.font.ascent = MAX(dc.font.ascent, (*xfonts)-ascent);
+ dc.font.descent = MAX(dc.font.descent,(*xfonts)-descent);
xfonts++;
}
}
@@ -1012,10 +1011,8 @@ manage(Window w, XWindowAttributes *wa)
c-x = wx + ww - c-w - 2 * c-bw;
if(c-y + c-h + 2 * c-bw wy + wh)
c-y = wy + wh - c-h - 2 * c-bw;
- if(c-x wx)
- c-x = wx;
- if(c-y wy)
- c-y = wy;
+ c-x = MAX(c-x, wx);
+ c-y = MAX(c-y, wy);
c-bw = BORDERPX;
}
@@ -1181,10 +1178,8 @@ resize(Client *c, int x, int y, int w, i
if(sizehints) {
/* set minimum possible */
- if(w 1)
- w = 1;
- if(h 1)
- h = 1;
+ w = MAX(1, w);
+ h = MAX(1, h);
/* temporarily remove base dimensions */
w -= c-basew;
@@ -1210,14 +1205,14 @@ resize(Client *c, int x, int y, int w, i
w += c-basew;
h += c-baseh;
- if(c-minw 0 w c-minw)
- w = c-minw;
- if(c-minh 0 h c-minh)
- h = c-minh;
- if(c-maxw 0 w c-maxw)
- w = c-maxw;
- if(c-maxh 0 h c-maxh)
- h = c-maxh;
+ w = MAX(w, c-minw);
+ h = MAX(h, c-minh);
+
+ if (c-maxw)
+ w = MIN(w, c-maxw);
+
+ if (c-maxh)
+ h = MIN(h, c-maxh);
}
if(w = 0 || h = 0)
return;
@@ -1270,10 +1265,8 @@ resizemouse(Client *c) {
break;
case MotionNotify:
XSync(dpy, False);
- if((nw = ev.xmotion.x - ocx - 2 * c-bw + 1) = 0)
-nw = 1;
- if((nh = ev.xmotion.y - ocy - 2 * c-bw + 1) = 0)
-nh = 1;
+ nw = MAX(ev.xmotion.x - ocx - 2 * c-bw + 1, 1);
+ nh = MAX(ev.xmotion.y - ocy - 2 * c-bw + 1, 1);
if(!c-isfloating !lt-isfloating (abs(nw - c-w) SNAP || abs(nh - c-h) SNAP))
togglefloating(NULL);
if((lt-isfloating) || c-isfloating)
@@ -1525,13 +1518,11 @@ setup(void) {
/* init bar */
for(blw = i = 0; LENGTH(layouts) 1 i LENGTH(layouts); i++) {
w = textw(layouts[i].symbol);
- if(w blw)
- blw = w;
+ blw = MAX(blw, w);
}
for(bgw = i = 0; LENGTH(geoms) 1 i LENGTH(geoms); i++) {
w = textw(geoms[i].symbol);
- if(w bgw)
- bgw = w;
+ bgw = MAX(bgw, w);
}
wa.override_redirect = 1;
[dwm] Yet another simplification, this time sel/prevtags
Hi,
attached patch makes one array for both sel and prevtags. So there is
no need to swap them in memory in view() as we only change seltags
pointer to point viewtags[0] or viewtags[1].
It also with little change can support arbitrary number of saved tags
set (3 save position can be usable, with modkey-shift-tab going on
next state in queue).
-Ph
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Sun Apr 20 17:44:51 2008 +0200
@@ -231,11 +231,12 @@ Atom wmatom[WMLast], netatom[NetLast];
Atom wmatom[WMLast], netatom[NetLast];
Bool otherwm, readin;
Bool running = True;
-Bool *prevtags;
-Bool *seltags;
Client *clients = NULL;
Client *sel = NULL;
+Bool *seltags;
Client *stack = NULL;
+Bool *viewtags[2];
+int viewtags_set = 0;
Cursor cursor[CurLast];
Display *dpy;
DC dc = {0};
@@ -246,7 +247,6 @@ Window root, barwin;
/* configuration, allows nested code to access above variables */
#include config.h
#define TAGSZ (LENGTH(tags) * sizeof(Bool))
-static Bool tmp[LENGTH(tags)];
/* function implementations */
@@ -1162,11 +1162,10 @@ quit(const char *arg) {
void
reapply(const char *arg) {
- static Bool zerotags[LENGTH(tags)] = { 0 };
Client *c;
for(c = clients; c; c = c-next) {
- memcpy(c-tags, zerotags, sizeof zerotags);
+ memset(c-tags, 0, TAGSZ);
applyrules(c);
}
arrange();
@@ -1515,9 +1514,10 @@ setup(void) {
XSetFont(dpy, dc.gc, dc.font.xfont-fid);
/* init tags */
- seltags = emallocz(TAGSZ);
- prevtags = emallocz(TAGSZ);
- seltags[0] = prevtags[0] = True;
+ viewtags[0] = emallocz(TAGSZ);
+ viewtags[1] = emallocz(TAGSZ);
+ viewtags[0][0] = viewtags[1][0] = True;
+ seltags = viewtags[0];
/* init layouts */
lt = layouts[0];
@@ -1842,9 +1842,9 @@ updatewmhints(Client *c) {
}
}
-
void
view(const char *arg) {
+ Bool tmp[LENGTH(tags)];
unsigned int i;
for(i = 0; i LENGTH(tags); i++)
@@ -1852,7 +1852,7 @@ view(const char *arg) {
tmp[idxoftag(arg)] = True;
if(memcmp(seltags, tmp, TAGSZ) != 0) {
- memcpy(prevtags, seltags, TAGSZ);
+ seltags = viewtags[viewtags_set ^= 1]; /* toggle tagset */
memcpy(seltags, tmp, TAGSZ);
arrange();
}
@@ -1860,10 +1860,8 @@ view(const char *arg) {
void
viewprevtag(const char *arg) {
+ seltags = viewtags[viewtags_set ^= 1]; /* toggle tagset */
- memcpy(tmp, seltags, TAGSZ);
- memcpy(seltags, prevtags, TAGSZ);
- memcpy(prevtags, tmp, TAGSZ);
arrange();
}
Re: [dwm] Yet another simplification, this time sel/prevtags
On (20/04/08 21:49), yy wrote:
To: dynamic window manager dwm@suckless.org
From: yy [EMAIL PROTECTED]
Subject: Re: [dwm] Yet another simplification, this time sel/prevtags
Reply-To: dynamic window manager dwm@suckless.org
List-Id: dynamic window manager dwm.suckless.org
I like this change, good work Premysl! But once you are using the
array, you don't need seltags any more. The attached patch saves 2 or
3 loc. It also includes the functionality of my patch to see prevtags,
but if you do the XOR inside memcpy you can save another line of code.
I have also changed a little your notation (because I don't like
underscores in variable names), but maybe you can think of better
names.
I think I will like dwm 5.0...
Hi
- if(memcmp(seltags, tmp, TAGSZ) != 0) {
- seltags = viewtags[viewtags_set ^= 1]; /* toggle tagset */
- memcpy(seltags, tmp, TAGSZ);
- arrange();
- }
+ seltags ^= 1; /* toggle sel tagset */
+ if(memcmp(tagset[seltags ^ 1], tmp, TAGSZ) != 0)
+ memcpy(tagset[seltags], tmp, TAGSZ);
+ arrange();
This doesn't do same thing, as seltags is always toggled, even if
current and new tagset are same. So this will broke that change only if
differ behaviour or I miss something? :)
If we will throw away this behaviour, things can be even more simpler.
We then can substitute whole view with:
void
view(const char *arg) {
seltags ^= 1;
memset(tagset[seltag], (NULL == arg), TAGSZ);
tagset[seltag][idxoftag(arg)] = True;
arrange();
}
(memset can be used, because tags are always only test if they are zero
or nonzero, so it doesn't matter that tagset[i][j] (because Bool is defined
as int) can be something like 0x01010101 on x86)
-Ph
--
Premysl Anydot Hruby, htto://www.redrum.cz
Re: [dwm] bloq may used to ignore keybindings
On (23/04/08 14:18), pancake wrote: To: dwm@suckless.org From: pancake [EMAIL PROTECTED] Subject: [dwm] bloq may used to ignore keybindings Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org Recently I tried wmii (for a few minutes :P) and notice that if I press bloq.mayus I was able to use alt-1, alt-2 to change between the tabs in firefox. This makes me think that we can probably take the same idea for dwm to make it ignore the keybindings. Maybe we can also let configurable this bloq. key in config.h and use any other locked key for this. --pancake I prefer to use Mod4 (win key) as MODKEY, so I have no keybinding clash. -- Premysl Anydot Hruby, http://www.redrum.cz/
[dwm] small cleanup of drawtext()
Hi,
I do small cleanup of drawtext():
- buf[] is not needed to be global
- there's no need to end buf[] with zero byte, as all function take length
parameter
- w dc.w can be true iff length of printed text is zero
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
diff -r 042cef9c6ace dwm.c
--- a/dwm.c Fri Apr 25 00:04:27 2008 +0200
+++ b/dwm.c Sun Apr 27 18:15:02 2008 +0200
@@ -210,7 +210,7 @@
void zoom(const char *arg);
/* variables */
-char stext[256], buf[256];
+char stext[256];
int screen, sx, sy, sw, sh;
int (*xerrorxlib)(Display *, XErrorEvent *);
int bx, by, bw, bh, blw, bgw, mx, my, mw, mh, mox, moy, mow, moh, tx, ty, tw, th, wx, wy, ww, wh;
@@ -600,22 +600,23 @@
int x, y, w, h;
unsigned int len, olen;
XRectangle r = { dc.x, dc.y, dc.w, dc.h };
+ char buf[256];
XSetForeground(dpy, dc.gc, col[invert ? ColFG : ColBG]);
XFillRectangles(dpy, dc.drawable, dc.gc, r, 1);
if(!text)
return;
+ olen = strlen(text);
+ len = MIN(olen, sizeof buf);
+ memcpy(buf, text, len);
w = 0;
- olen = strlen(text);
- len = MIN(olen, sizeof buf - 1);
- memcpy(buf, text, len);
- buf[len] = 0;
h = dc.font.ascent + dc.font.descent;
y = dc.y + (dc.h / 2) - (h / 2) + dc.font.ascent;
x = dc.x + (h / 2);
/* shorten text if necessary */
- while(len (w = textnw(buf, len)) dc.w - h)
- buf[--len] = 0;
+ for(; len (w = textnw(buf, len)) dc.w - h; len--);
+ if (!len)
+ return;
if(len olen) {
if(len 1)
buf[len - 1] = '.';
@@ -624,8 +625,6 @@
if(len 3)
buf[len - 3] = '.';
}
- if(w dc.w)
- return; /* too long */
XSetForeground(dpy, dc.gc, col[invert ? ColBG : ColFG]);
if(dc.font.set)
XmbDrawString(dpy, dc.drawable, dc.font.set, dc.gc, x, y, buf, len);
Re: [dwm] Yet another simplification, this time sel/prevtags
On (27/04/08 19:58), Anselm R. Garbe wrote: With the current change in mind, do we still need viewprev()? Short answer: yes, we do :) Long answer: yes, we do because: - you are not able to see previous tagset if you have currently selected more than one tag - for switching to previous tagset you doesn't need to know what is/are current tag, you simply press key for viewprev, and it's simply done :) -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Yet another simplification, this time sel/prevtags
On (27/04/08 20:33), yy wrote: To: dynamic window manager dwm@suckless.org From: yy [EMAIL PROTECTED] Subject: Re: [dwm] Yet another simplification, this time sel/prevtags Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org After the last change in hg tip, viewprev is the only way to view the previous tags, the change when trying to view the currently selected tag is not working any more, if you remove viewprev you can then remove all the tagset stuff. Another thing, now if you press twice in a tag to view it you will lose your previous tags, I don't think that's the expected behavior. No, you will not lost anything :) I thought that too (and write it here, too), but try it. It somewhat not so easilly imaginable code. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Java patch
On (29/04/08 11:27), Anselm R. Garbe wrote: To: dynamic window manager dwm@suckless.org From: Anselm R. Garbe [EMAIL PROTECTED] Subject: Re: [dwm] Java patch User-Agent: Mutt/1.5.13 (2006-08-11) Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org On Sun, Apr 27, 2008 at 01:43:14PM -0700, Don Stewart wrote: So why not converting this patch into a standalone setwmname application written in C, then we can delete the patches in dwm and XMonad and people just run setwmname FooBarBaz to work around the XToolkit bug(s)? Kind regards, Good idea imho. -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] more consistent codestyle patch
On (14/05/08 16:24), Kai Grossjohann wrote: To: dynamic window manager dwm@suckless.org From: Kai Grossjohann [EMAIL PROTECTED] Subject: Re: [dwm] more consistent codestyle patch User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org Marc Andre Tanner wrote: [...] That is, use tabs for indention and spaces for further alignment: ---XGrabButton(dpy, AnyButton, AnyModifier, c-win, False, ---BUTTONMASK, GrabModeAsync, GrabModeSync, None, None); This way the user can set the tabwidth to whatever he likes and the code will still look decent. *drool* Is there a tool that does this? Kai indent(1) and there are other programs that this do. -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] lost keyboard with dmenu
On (19/05/08 11:16), pancake wrote:
I usually install new versions of applications in my PREFIX, and dmenu
needs to update most of time the cache. When this happens, dmenu takes
the keyboard input and it's impossible to open a terminal or type things
in a chat, etc..
The 'esc' key is not handled directly, so you have to wait until the
running program finishes.
This is quite anoying, I understand that I should do something like
a static cache updated by me manually, and I will not suffer this
problem.
But maybe sounds reasonable to make dmenu not capturing the keyboard
until something is readed from stdin. Just to make it more responsive.
You can simple edit your dmenu_run script to achieve this.
Something like:
dmenu_path /dev/null
exe=`dmenu_path | dmenu ${1+$@}` exec $exe
(of course, there still chance, that something in $PATH will change just
between that calls to dmenu_path)
or you can save output of dmenu_path to variable/tempfile, and then
output it to dmenu.
(point of this is to NOT directly pipe dmenu_path output to dmenu)
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] way towards 5.0
On (19/05/08 20:34), Anselm R. Garbe wrote:
To: dynamic window manager dwm@suckless.org
From: Anselm R. Garbe [EMAIL PROTECTED]
Well, for mainstream dwm my opinion has always been to stick to
mouse only. But I had occasional cases when I'd like to have
keyboard driven resizals as well, esp. when having no mouse
around and sticking to the thinkpad touchpad.
Maybe I will include something like this in the future.
Out of curiosity, which keybindings are you using to achieve
keyboard-driven movements and resizals, since Mod1-{h,j,k,l} are
taken already.
Kind regards,
Imho MODKEY-ctrl-{h,j,k,l} for move of window, and
MODKEY-c-s-{h,j,k,l} for resize. So, one hand will press modifiers and
other will move/resize windows with h/j/k/l
--
Premysl Anydot Hruby, http://www.redrum.cz/
[dwm] using bitaray for tags (PATCH)
Hi,
This is realization of Gottox's proposal discuted on IRC today.
It handles tags not as Bool [], but as bit-array saved in int.
There's only one problem, as I don't find easy solution (in compile time)
for check if there's no more tags than sizeof(int)*8.
Maybe it can be asserted with someting like (possibly global, compiler
take it away as it's not used anywhere):
static char too_many_tags_test[sizeof(int)*8 - LENGTH(tags)];
Has anyone better solution?
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
diff -r cd9fd0986555 dwm.c
--- a/dwm.c Mon May 19 20:29:57 2008 +0100
+++ b/dwm.c Tue May 20 18:05:46 2008 +0200
@@ -51,6 +51,10 @@
#define LENGTH(x) (sizeof x / sizeof x[0])
#define MAXTAGLEN 16
#define MOUSEMASK (BUTTONMASK|PointerMotionMask)
+#define TMASK(p)(1(p))
+#define ISSET(t,p) ((t)TMASK(p))
+#define SET(t,p,v) {if(v) (t)|=TMASK(p); else (t)= ~TMASK(p);}
+#define TOGGLE(t,p) ((t) ^= TMASK(p))
/* enums */
enum { CurNormal, CurResize, CurMove, CurLast };/* cursor */
@@ -68,7 +72,7 @@
long flags;
unsigned int bw, oldbw;
Bool isbanned, isfixed, isfloating, isurgent;
- Bool *tags;
+ int tags;
Client *next;
Client *prev;
Client *snext;
@@ -218,7 +222,7 @@
Atom wmatom[WMLast], netatom[NetLast];
Bool otherwm, readin;
Bool running = True;
-Bool *tagset[2];
+int tagset[2] = {1, 1}; /* after start, first tag is selected */
Client *clients = NULL;
Client *sel = NULL;
Client *stack = NULL;
@@ -231,7 +235,6 @@
/* configuration, allows nested code to access above variables */
#include config.h
-#define TAGSZ (LENGTH(tags) * sizeof(Bool))
/* function implementations */
@@ -251,7 +254,7 @@
(!r-instance || (ch.res_name strstr(ch.res_name, r-instance {
c-isfloating = r-isfloating;
if(r-tag) {
-c-tags[idxoftag(r-tag)] = True;
+SET(c-tags, idxoftag(r-tag), 1);
matched = True;
}
}
@@ -261,7 +264,7 @@
if(ch.res_name)
XFree(ch.res_name);
if(!matched)
- memcpy(c-tags, tagset[seltags], TAGSZ);
+ c-tags = tagset[seltags];
}
void
@@ -501,13 +504,13 @@
for(c = stack; c !isvisible(c); c = c-snext);
for(i = 0; i LENGTH(tags); i++) {
dc.w = textw(tags[i]);
- if(tagset[seltags][i]) {
+ if(ISSET(tagset[seltags], i)) {
drawtext(tags[i], dc.sel, isurgent(i));
- drawsquare(c c-tags[i], isoccupied(i), isurgent(i), dc.sel);
+ drawsquare(c ISSET(c-tags, i), isoccupied(i), isurgent(i), dc.sel);
}
else {
drawtext(tags[i], dc.norm, isurgent(i));
- drawsquare(c c-tags[i], isoccupied(i), isurgent(i), dc.norm);
+ drawsquare(c ISSET(c-tags, i), isoccupied(i), isurgent(i), dc.norm);
}
dc.x += dc.w;
}
@@ -861,7 +864,7 @@
Client *c;
for(c = clients; c; c = c-next)
- if(c-tags[t])
+ if(ISSET(c-tags, t))
return True;
return False;
}
@@ -886,19 +889,14 @@
Client *c;
for(c = clients; c; c = c-next)
- if(c-isurgent c-tags[t])
+ if(c-isurgent ISSET(c-tags, t))
return True;
return False;
}
Bool
isvisible(Client *c) {
- unsigned int i;
-
- for(i = 0; i LENGTH(tags); i++)
- if(c-tags[i] tagset[seltags][i])
- return True;
- return False;
+ return c-tags tagset[seltags];
}
void
@@ -945,7 +943,6 @@
XWindowChanges wc;
c = emallocz(sizeof(Client));
- c-tags = emallocz(TAGSZ);
c-win = w;
/* geometry */
@@ -980,7 +977,7 @@
if((rettrans = XGetTransientForHint(dpy, w, trans) == Success))
for(t = clients; t t-win != trans; t = t-next);
if(t)
- memcpy(c-tags, t-tags, TAGSZ);
+ c-tags = t-tags;
else
applyrules(c);
if(!c-isfloating)
@@ -1396,11 +1393,6 @@
if(!dc.font.set)
XSetFont(dpy, dc.gc, dc.font.xfont-fid);
- /* init tags */
- tagset[0] = emallocz(TAGSZ);
- tagset[1] = emallocz(TAGSZ);
- tagset[0][0] = tagset[1][0] = True;
-
/* init bar */
for(blw = i = 0; LENGTH(layouts) 1 i LENGTH(layouts); i++) {
w = textw(layouts[i].symbol);
@@ -1464,9 +1456,11 @@
if(!sel)
return;
- for(i = 0; i LENGTH(tags); i++)
- sel-tags[i] = (arg == NULL);
- sel-tags[idxoftag(arg)] = True;
+ if (arg)
+ sel-tags = TMASK(idxoftag(arg));
+ else
+ sel-tags = TMASK(LENGTH(tags) + 1) - 1;
+
arrange();
}
@@ -1580,22 +1574,20 @@
if(!sel)
return;
i = idxoftag(arg);
- sel-tags[i] = !sel-tags[i];
- for(j = 0; j LENGTH(tags) !sel-tags[j]; j++);
- if(j == LENGTH(tags))
- sel-tags[i] = True; /* at least one tag must be enabled */
+ TOGGLE(sel-tags, i);
+ if (!sel-tags) /* at least one tag must be selected */
+ SET(sel-tags, i, 1);
arrange();
}
void
toggleview(const char *arg) {
unsigned int i, j;
-
+
i = idxoftag(arg);
- tagset[seltags][i] = !tagset[seltags][i];
- for(j = 0; j LENGTH(tags) !tagset[seltags][j]; j++);
- if(j == LENGTH(tags))
- tagset[seltags][i] = True; /* at least one tag must be viewed */
+ TOGGLE(tagset[seltags], i);
+ if (!tagset[seltags])
+ SET(tagset[seltags], i, 1); /* at least one tag must be viewed */
arrange();
}
@@ -1622,7 +1614,6 @@
Re: [dwm] using bitaray for tags (PATCH)
On (20/05/08 11:22), Kurt H Maier wrote: To: dynamic window manager dwm@suckless.org From: Kurt H Maier [EMAIL PROTECTED] Subject: Re: [dwm] using bitaray for tags (PATCH) Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org C has bitfield support inside structs: unsigned tagsapplied :8; and replace 8 with whatever value you want Bitfields are a bad idea imo; code has to be changed pretty severely to handle a varying-sized bitfield. You'd have to either limit the number of tags a user can create or else do a lot of work to generalize the code. Yes, I don't like varying-sized bitfield for this. But even on i386 we can get 64 tags maximum with long long, prety much for everyone :) -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] using bitaray for tags (PATCH)
On (20/05/08 11:22), Kurt H Maier wrote: To: dynamic window manager dwm@suckless.org From: Kurt H Maier [EMAIL PROTECTED] Subject: Re: [dwm] using bitaray for tags (PATCH) Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org C has bitfield support inside structs: unsigned tagsapplied :8; and replace 8 with whatever value you want Bitfields are a bad idea imo; code has to be changed pretty severely to handle a varying-sized bitfield. You'd have to either limit the number of tags a user can create or else do a lot of work to generalize the code. btw, addition of varying sized bitfield to my patch wouldn't be hard, only declaration of Client must be changed, and that #macros -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] using bitaray for tags (PATCH)
On (21/05/08 08:27), Enno Gottox Boland wrote: To: dynamic window manager dwm@suckless.org From: Enno Gottox Boland [EMAIL PROTECTED] Subject: Re: [dwm] using bitaray for tags (PATCH) Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org Here's my version of a bitarray patch. Please review and comment. tagmask can be #define: #define TAGMASK ((int)(1LL (LENGTH(tags) + 1) - 1)) -Ph
Re: [dwm] using bitaray for tags (PATCH)
On (21/05/08 12:06), markus schnalke wrote: To: dwm@suckless.org From: markus schnalke [EMAIL PROTECTED] Subject: Re: [dwm] using bitaray for tags (PATCH) Mail-Followup-To: dwm@suckless.org User-Agent: Mutt/1.5.13 (2006-08-11) Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org Premysl Hruby [EMAIL PROTECTED] wrote: This is realization of Gottox's proposal discuted on IRC today. It handles tags not as Bool [], but as bit-array saved in int. I read, that bit-arrays are not very portable between different architectures. (It was in The practice of programming, I think) Maybe this is not relevant here; also I cannot recall the exact explanaition, why one should avoid it. Please check if there is any thruth in that statement. Second, I want to mention, that bit-shifts might look really leet, but _do_ obfuscate, what could be written much more clearly! Please stick to _clear_ code. meillo That's the reason why i wrote it as macros. That bitops can also be written as inline functions, without any harm to binary size or performance. And yes, with bitarrays there are some portability issues. But asside of limiting number of possible tags, there's no portability downside for dwm, imho. (it will compile, but maximum of tags is architecture dependent) -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] using bitaray for tags (PATCH)
On (20/05/08 11:22), Kurt H Maier wrote: To: dynamic window manager dwm@suckless.org From: Kurt H Maier [EMAIL PROTECTED] C has bitfield support inside structs: unsigned tagsapplied :8; and replace 8 with whatever value you want Not really with whatever value, only that values so whole variable will fit into int/long long Bitfields are a bad idea imo; code has to be changed pretty severely to handle a varying-sized bitfield. You'd have to either limit the number of tags a user can create or else do a lot of work to generalize the code. Yes, we solved this by not using variable-sized bitfields. ;) -- Premysl Anydot Hruby, http://www.redrum.cz/
[dwm] Unused variable Client.flags
Hi,
i found that Client.flags is unused and can be removed. Patch attached.
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
diff -r 2c5c99803c2e dwm.c
--- a/dwm.c Sat May 31 17:37:13 2008 +0100
+++ b/dwm.c Sat May 31 22:16:32 2008 +0200
@@ -69,7 +69,6 @@
int x, y, w, h;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
- long flags;
int bw, oldbw;
Bool isbanned, isfixed, isfloating, ismoved, isurgent;
uint tags;
@@ -1601,42 +1600,40 @@
long msize;
XSizeHints size;
- if(!XGetWMNormalHints(dpy, c-win, size, msize) || !size.flags)
- size.flags = PSize;
- c-flags = size.flags;
- if(c-flags PBaseSize) {
+ XGetWMNormalHints(dpy, c-win, size, msize);
+ if(size.flags PBaseSize) {
c-basew = size.base_width;
c-baseh = size.base_height;
}
- else if(c-flags PMinSize) {
+ else if(size.flags PMinSize) {
c-basew = size.min_width;
c-baseh = size.min_height;
}
else
c-basew = c-baseh = 0;
- if(c-flags PResizeInc) {
+ if(size.flags PResizeInc) {
c-incw = size.width_inc;
c-inch = size.height_inc;
}
else
c-incw = c-inch = 0;
- if(c-flags PMaxSize) {
+ if(size.flags PMaxSize) {
c-maxw = size.max_width;
c-maxh = size.max_height;
}
else
c-maxw = c-maxh = 0;
- if(c-flags PMinSize) {
+ if(size.flags PMinSize) {
c-minw = size.min_width;
c-minh = size.min_height;
}
- else if(c-flags PBaseSize) {
+ else if(size.flags PBaseSize) {
c-minw = size.base_width;
c-minh = size.base_height;
}
else
c-minw = c-minh = 0;
- if(c-flags PAspect) {
+ if(size.flags PAspect) {
c-minax = size.min_aspect.x;
c-maxax = size.max_aspect.x;
c-minay = size.min_aspect.y;
Re: [dwm] [patch] simplification to drawtext
On (01/06/08 12:38), Enno Gottox Boland wrote:
To: dynamic window manager dwm@suckless.org
From: Enno Gottox Boland [EMAIL PROTECTED]
Subject: [dwm] [patch] simplification to drawtext
Reply-To: dynamic window manager dwm@suckless.org
List-Id: dynamic window manager dwm.suckless.org
Hi!
Here's a small simplification to drawtext.
regards
Gottox
diff -r 2488c46e002c dwm.c
--- a/dwm.c Thu May 29 18:42:53 2008 +0100
+++ b/dwm.c Sun Jun 01 12:36:37 2008 +0200
@@ -571,14 +571,8 @@
for(; len (w = textnw(buf, len)) dc.w - h; len--);
if(!len)
return;
- if(len olen) {
- if(len 1)
- buf[len - 1] = '.';
- if(len 2)
- buf[len - 2] = '.';
- if(len 3)
- buf[len - 3] = '.';
- }
+ if(len olen)
+ strncpy(buf[MAX(0, len - 3)], ..., len);
Not much readable (because it firstly looks like it's error (buf maybe
not ended with \0)). I am against using strncpy in case that dest string
is not C string, but char[] + length.
Maybe:
memcpy(buf[MAX(0, len - 3)], ..., 3);
would be somewhat better ;)
XSetForeground(dpy, dc.gc, col[invert ? ColBG : ColFG]);
if(dc.font.set)
XmbDrawString(dpy, dc.drawable, dc.font.set, dc.gc, x, y, buf,
len);
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [patch] simplification to drawtext
On (02/06/08 09:56), Enno Gottox Boland wrote: To: dynamic window manager dwm@suckless.org From: Enno Gottox Boland [EMAIL PROTECTED] Subject: Re: [dwm] [patch] simplification to drawtext Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org whoops... memcpy(buf[MAX(0, len - 3)], ..., MIN(3, len)); Still, this is not needed, as buf is ALWAYS greater than 3 bytes. So: memcpy(buf[MAX(0, len - 3)], ..., 3); is sufficent, this was my thought when I wrote this memcpy variant. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
[dwm] slight cleanup of focus()
Hi,
patch is attached
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
diff -r 81b40dd1b766 dwm.c
--- a/dwm.c Mon Jun 02 12:19:02 2008 +0200
+++ b/dwm.c Tue Jun 03 21:22:35 2008 +0200
@@ -612,7 +612,7 @@
void
focus(Client *c) {
- if(!c || (c c-isbanned))
+ if(!c || c-isbanned)
for(c = stack; c c-isbanned; c = c-snext);
if(sel sel != c) {
grabbuttons(sel, False);
@@ -622,14 +622,12 @@
detachstack(c);
attachstack(c);
grabbuttons(c, True);
- }
- sel = c;
- if(c) {
XSetWindowBorder(dpy, c-win, dc.sel[ColBorder]);
XSetInputFocus(dpy, c-win, RevertToPointerRoot, CurrentTime);
}
else
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
+ sel = c;
drawbar();
}
[dwm] patch
Hi,
I just created patch which includes some minor patches, maybe at least
some of them can be included.
it contains these parts:
- reintroducion of union Arg
- join of focusnext and focusprev into one function which use parameter
- reenabling -Os and stripping of build (to save binary size)
- every global/function is static (to save binary size too)
- uses float instead of double
- remove Client-prev which is really not so needed
- replace minax/minay, maxax/maxay with float mina, maxa
Some of these features are more or less POC, for discussion (removing
-prev for example).
diffstat:
config.def.h | 70 ++--
config.mk|4
dwm.c| 342
---
3 files changed, 205 insertions(+), 211 deletions(-)
--
Premysl Anydot Hruby, http://www.redrum.cz/
diff -r d04ee4e2336d config.def.h
--- a/config.def.h Wed Jun 04 11:49:46 2008 +0200
+++ b/config.def.h Tue Jun 10 10:25:55 2008 +0200
@@ -8,25 +8,25 @@
#define SELBORDERCOLOR #0066ff
#define SELBGCOLOR #0066ff
#define SELFGCOLOR #ff
-unsigned int borderpx = 1;/* border pixel of windows */
-unsigned int snap = 32; /* snap pixel */
-Bool showbar = True; /* False means no bar */
-Bool topbar= True; /* False means bottom bar */
+static uint borderpx = 1;/* border pixel of windows */
+static uint snap = 32; /* snap pixel */
+static Bool showbar = True; /* False means no bar */
+static Bool topbar= True; /* False means bottom bar */
/* tagging */
-const char tags[][MAXTAGLEN] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
+static const char tags[][MAXTAGLEN] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
-Rule rules[] = {
+static Rule rules[] = {
/* class instancetitle tags ref isfloating */
{ Gimp, NULL, NULL, 0,True },
{ Firefox, NULL, NULL, 1 8, True },
};
/* layout(s) */
-double mfact = 0.55;
-Bool resizehints = False; /* False means respect size hints in tiled resizals */
+static float mfact = 0.55;
+static Bool resizehints = False; /* False means respect size hints in tiled resizals */
-Layout layouts[] = {
+static Layout layouts[] = {
/* symbol arrange function */
{ []=, tile }, /* first entry is default */
{ , NULL }, /* no layout function means floating behavior */
@@ -40,31 +40,31 @@
{ MODKEY|ShiftMask, KEY, tag,TAG }, \
{ MODKEY|ControlMask|ShiftMask, KEY, toggletag, TAG },
-Key keys[] = {
+static Key keys[] = {
/* modifier keyfunctionargument */
- { MODKEY, XK_p, spawn, (char *)exec dmenu_run -fn 'FONT' -nb 'NORMBGCOLOR' -nf 'NORMFGCOLOR' -sb 'SELBGCOLOR' -sf 'SELFGCOLOR' },
- { MODKEY|ShiftMask, XK_Return, spawn, (char *)exec uxterm },
- { MODKEY, XK_b, togglebar, NULL },
- { MODKEY, XK_j, focusnext, NULL },
- { MODKEY, XK_k, focusprev, NULL },
- { MODKEY, XK_h, setmfact, (double[]){-0.05} },
- { MODKEY, XK_l, setmfact, (double[]){+0.05} },
- { MODKEY, XK_m, togglemax, NULL },
- { MODKEY, XK_Return, zoom, NULL },
- { MODKEY, XK_Tab,view, NULL },
- { MODKEY|ShiftMask, XK_c, killclient, NULL },
- { MODKEY, XK_space, togglelayout, NULL },
- { MODKEY|ShiftMask, XK_space, togglefloating, NULL },
- { MODKEY, XK_0, view, (uint[]){ ~0 } },
- { MODKEY|ShiftMask, XK_0, tag,(uint[]){ ~0 } },
- TAGKEYS(XK_1, (uint[]){ 1 0} )
- TAGKEYS(XK_2, (uint[]){ 1 1} )
- TAGKEYS(XK_3, (uint[]){ 1 2} )
- TAGKEYS(XK_4, (uint[]){ 1 3} )
- TAGKEYS(XK_5, (uint[]){ 1 4} )
- TAGKEYS(XK_6, (uint[]){ 1 5} )
- TAGKEYS(XK_7, (uint[]){ 1 6} )
- TAGKEYS(XK_8, (uint[]){ 1 7} )
- TAGKEYS(XK_9, (uint[]){ 1 8} )
- { MODKEY|ShiftMask, XK_q, quit, NULL },
+ { MODKEY, XK_p, spawn, {.c = exec dmenu_run -fn 'FONT' -nb 'NORMBGCOLOR' -nf 'NORMFGCOLOR' -sb 'SELBGCOLOR' -sf 'SELFGCOLOR' }},
+ { MODKEY|ShiftMask, XK_Return, spawn, {.c = exec uxterm }},
+ { MODKEY,
Re: [dwm] patch
On (10/06/08 10:51), Anselm R. Garbe wrote: To: dynamic window manager dwm@suckless.org From: Anselm R. Garbe [EMAIL PROTECTED] Subject: Re: [dwm] patch On Tue, Jun 10, 2008 at 10:38:55AM +0200, Premysl Hruby wrote: - reintroducion of union Arg I don't like this, because intialization gets slightly cumbersome, I really prefer void * here. Imho it's much more cleaner then these const void *, is it don't hinder the type etc. And initialization looks cleaner too. And union has been created just for this usage, as replace for type magic. -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] dmenu directory test
On (14/06/08 16:20), James Turner wrote: To: dynamic window manager dwm@suckless.org From: James Turner [EMAIL PROTECTED] Subject: Re: [dwm] dmenu directory test On Sat, Jun 14, 2008 at 10:16:03PM +0200, Peter Hartlich wrote: Hi, [...] I was wondering if it would make sense to add a test in dmenu_path to make sure the directory actually exists before trying to cd into it? If you're bothered about cd printing an error message, you could just add 2/dev/null to the cd line. Regards, Peter Doesn't it make more sense to do a test, then just redirect error output? That cd itself is sort of test. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
[dwm] dmenu - simplification of cistrstr and kpress
Hi,
it also defines feature macro _BSD_SOURCE, so usleep and strdup is
declared.
patch attached.
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
diff -r 0088cc3243e3 config.mk
--- a/config.mk Sat Jun 21 16:43:12 2008 +0100
+++ b/config.mk Wed Jun 25 23:09:40 2008 +0200
@@ -19,7 +19,7 @@
LIBS = -L/usr/lib -lc -L${X11LIB} -lX11 ${XINERAMALIBS}
# flags
-CPPFLAGS = -DVERSION=\${VERSION}\ ${XINERAMAFLAGS}
+CPPFLAGS = -DVERSION=\${VERSION}\ ${XINERAMAFLAGS} -D_BSD_SOURCE
CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
LDFLAGS = -s ${LIBS}
diff -r 0088cc3243e3 dmenu.c
--- a/dmenu.c Sat Jun 21 16:43:12 2008 +0100
+++ b/dmenu.c Wed Jun 25 23:09:40 2008 +0200
@@ -129,25 +129,12 @@
char *
cistrstr(const char *s, const char *sub) {
- int c, csub;
- uint len;
-
if(!sub)
- return (char *)s;
- if((c = *sub++) != 0) {
- c = tolower(c);
- len = strlen(sub);
- do {
- do {
-if((csub = *s++) == 0)
- return (NULL);
- }
- while(tolower(csub) != c);
- }
- while(strncasecmp(s, sub, len) != 0);
- s--;
- }
- return (char *)s;
+ return (char *)1;
+ for (; *s; s++)
+ if (strcasecmp(s, sub) == 0)
+ return (char *)1;
+ return (char *)NULL;
}
void
@@ -411,11 +398,7 @@
switch(ksym) {
default:
if(num !iscntrl((int) buf[0])) {
- buf[num] = 0;
- if(len 0)
-strncat(text, buf, sizeof text);
- else
-strncpy(text, buf, sizeof text);
+ strncat(text, buf, num);
match(text);
}
break;
Re: [dwm] dmenu - simplification of cistrstr and kpress
On (26/06/08 16:33), Sander van Dijk wrote: To: dynamic window manager dwm@suckless.org From: Sander van Dijk [EMAIL PROTECTED] Subject: Re: [dwm] dmenu - simplification of cistrstr and kpress Reply-To: dynamic window manager dwm@suckless.org List-Id: dynamic window manager dwm.suckless.org On 6/26/08, Premysl Hruby [EMAIL PROTECTED] wrote: Hi, it also defines feature macro _BSD_SOURCE, so usleep and strdup is declared. patch attached. return (char *)1;? cistrstr(s, sub) is supposed to return a pointer to the first occurence of sub in s, or NULL if there is none; not some fixed pointer to memory that's probably not even allocated to the process. Greetings, Sander. Yes, that's true, but return value is only used only in comparison if is or isn't null, to signalize that substring is or isn't contained in the string. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] mailing list changed
On (17/07/08 14:49), Jacek Hoffman wrote: To: dwm mail list [EMAIL PROTECTED] From: Jacek Hoffman [EMAIL PROTECTED] Subject: Re: [dwm] mailing list changed Hi, I have to leave my mailbox unattended for some weeks. In order to avoid mailbox overloading perhaps I have to sign-out from the list or switch some option. Any advice what and how to do? Jacek Hi, I wrote something about mail-lists in: http://www.suckless.org/common/community.html To unsubscribe this mail-list, just send email to the adress [EMAIL PROTECTED] -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] hgiki
On (19/07/08 11:52), Yoshi Rokuko wrote: To: dwm mail list dwm@suckless.org From: Yoshi Rokuko [EMAIL PROTECTED] Subject: [dwm] hgiki Organization: Black Red Inc. Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Hi, I was trying to add a screenshot to the hg wiki, the screenshot is nothing really special and it is smaller then 100k. Now on the site there is: The following screenshot hasn't been committed yet: Screenshot (see http://www.suckless.org/dwm/screenshots/) something went wrong? or am I not supposed to add screenshots? y0shi PS I don't know much about hg just did hg pull hg update hg commit hg push something missing? did you use 'hg add' to add the file to the repository (before commiting)? -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] some proposed changes
On (09/08/08 12:55), yy wrote: To: dwm mail list dwm@suckless.org From: yy [EMAIL PROTECTED] Subject: [dwm] some proposed changes Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Attached there is a patch with some changes to dwm.c. It uses XLowerWindow and XMoveResizeWindow instead of configure functions in restack() and resize() respectively. I suposse there is a good reason to use configure here, but since Anselm is on holidays I ask here if somebody knows the reason. I'm using it this way and have found no problems so far but they could appear with tricky programs. It removes some loc and I think the code is a bit more consistent this way. The other change is a new click option: ClkTagButton, this way you can have buttons in the tags to see previous tags or to see all of them. Anyway, the comment in config.def.h should be corrected to explain the current behaviour with ClkTagBar. My config.h is attached too, with some interesting custom functions. Greets, Hi, reason for using XConfigureWindow in restack() is setting border_width of client (and this is the only reason for not using XMoveResizeWindow as you propose). XLowerWindow was used in past, but it makes windows flickering in monocle layout, as windows are pushed to the bottom of the stack. Solution currently in use prevent flickering. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [patch] Minor code cleanup
On (13/08/08 16:21), Enno Gottox Boland wrote:
To: dwm mail list dwm@suckless.org
From: Enno Gottox Boland [EMAIL PROTECTED]
Subject: Re: [dwm] [patch] Minor code cleanup
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
Hi!
2008/8/13, Martin Hurton [EMAIL PROTECTED]:
Can arg really ever be NULL?
no, that should not be possible anymore. the patch is ok so far.
Cheers,
regards
Gottox
But that is NOT true, actually view() is called with NULL param, for
select previously selected view function: (excerpt from tip's
config.def.h)
{ MODKEY, XK_Tab,view, {0} },
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [patch] Minor code cleanup
On (13/08/08 17:10), Martin Hurton wrote:
To: dwm@suckless.org
From: Martin Hurton [EMAIL PROTECTED]
Subject: Re: [dwm] [patch] Minor code cleanup
Mail-Followup-To: dwm@suckless.org
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
User-Agent: Mutt/1.5.18 (2008-05-17)
On Wed, Aug 13, 2008 at 04:43:46PM +0200, Premysl Hruby wrote:
On (13/08/08 16:21), Enno Gottox Boland wrote:
To: dwm mail list dwm@suckless.org
From: Enno Gottox Boland [EMAIL PROTECTED]
Subject: Re: [dwm] [patch] Minor code cleanup
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
Hi!
2008/8/13, Martin Hurton [EMAIL PROTECTED]:
Can arg really ever be NULL?
no, that should not be possible anymore. the patch is ok so far.
Cheers,
regards
Gottox
But that is NOT true, actually view() is called with NULL param, for
select previously selected view function: (excerpt from tip's
config.def.h)
{ MODKEY, XK_Tab,view, {0} },
That zero does not mean NULL pointer; it is there to initialize the
Arg structure.
/Martin
Hm, that's true, but I'm sure that dwm crashed without check if arg is
not null (in view()).
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [patch] Minor code cleanup, part 2
On (14/08/08 09:52), Szabolcs Nagy wrote: To: dwm mail list dwm@suckless.org From: Szabolcs Nagy [EMAIL PROTECTED] Subject: Re: [dwm] [patch] Minor code cleanup, part 2 Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org On 8/14/08, Martin Hurton [EMAIL PROTECTED] wrote: if((rettrans = XGetTransientForHint(dpy, w, trans) == Success)) - for(t = clients; t t-win != trans; t = t-next); + t = getclient(trans); nice what about - if((rettrans = XGetTransientForHint(dpy, w, trans) == Success)) + if((rettrans = XGetTransientForHint(dpy, w, trans)) == Success) Applied both changes, thanks. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] current hg tip
On (15/08/08 13:07), Martin Hurton wrote: To: dwm@suckless.org From: Martin Hurton [EMAIL PROTECTED] Subject: [dwm] current hg tip Mail-Followup-To: dwm@suckless.org Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) I think the commit bca7a556aa03 in the official dwm repo introduced a new bug. The following is the excerpt fro the Xlib manual: Some functions return Status, an integer error indication. If the function fails, it returns a zero. If the function returns a status of zero, it has not updated the return arguments. So, if the XGetTransientForHint() function fails, the trans variable is not updated and its value is undefined. I suggest to revert this commit and apply the patch a proposed yesterday. /Martin It is updated (set to be None in case there is not WM_TRANSIENT_HINT property on window), and there are also other places in the code which depends on this, so I changed it to be consistent in handling of XGetTransientForHint. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] is wmii dead?
On (17/08/08 14:48), rundstutzen wrote: To: dwm@suckless.org From: rundstutzen [EMAIL PROTECTED] Subject: [dwm] is wmii dead? User-Agent: Thunderbird 2.0.0.16 (X11/20080724) Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Hi folks, the question arised in another email here. the repository tells me the last commit is 2 month old. is there any ongoing development? i don't want to hassle people, i am satisfied with wmii the way it is, i am just curious. regards Hi well, wouldn't be better to ask this question on wmii mail-list? :) -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Bug: trying to toggletag when there is no focused window = dwm crashes
On (22/08/08 03:33), Jan Kaliszewski wrote: To: dwm@suckless.org From: Jan Kaliszewski [EMAIL PROTECTED] Subject: [dwm] Bug: trying to toggletag when there is no focused window = dwm crashes Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Opera Mail/9.51 (Linux) Good evening||morning, I noticed a bug in dwm 5.1 -- the description in the subject. The reason is using sel-tags in function toggletag before checking whether sel is not NULL. The solution is obvious (if (!sel) return; before ...sel-tags...). Patch attached. Best regards *j -- Jan Kaliszewski (zuo) Thanks, aplied only slightly changed. -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Feature request: any way to change default values in config
On (23/08/08 17:51), Jan Kaliszewski wrote: To: dwm mail list dwm@suckless.org From: Jan Kaliszewski [EMAIL PROTECTED] Subject: Re: [dwm] Feature request: any way to change default values in config Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Opera Mail/9.51 (Linux) * If we say also about some other directly-after-startup actions (especially running some programs; e.g. I'd like to always have my favorite terminal+screen run after start) and also maybe directly-before-quit actions -- adding possibility to define such actions in array(s) (in a manner similar to key bindings and button actions, but only with 'function' and 'argument') in config.h would be useful. You can run programs after start for example from .Xsession which is also much better place doing this. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] suckless mail
Hi, I'm personally using mutt+msmtp+isync for mail, but maybe you can be happy with something like msmtp+fetchmail+mailx(light cli mail reader) -Ph On (26/08/08 18:11), pancake wrote: To: dwm@suckless.org From: pancake [EMAIL PROTECTED] Subject: [dwm] suckless mail Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org I have been thinking these days on writing something suckless for managing my mail. I don't know if any of you is happy with any mail client, but I do not feel comfortable with any of them. mutt is quite nice but is 'big' and there are so many open bugs like closing the connections when receiving a window-resize event. which is quite anoying.. sylpheed have some socket-locking problems, evolution is awesomely bloated and is not very nice when resizing the window. This is why I am thinking on writing a set of small tools for managing the mail in a minimalistic way. What I have in mind is something more simple that can be done without many LOCs and splitting the problem in multiple programs will achieve a better. - pop3 client - imap client - smtp client - mbox/mdir client with support for mime - frontend shell or so using inotify() on Linux is quite simple to get notifications of new files in certain directories, so it will be possible to get the events of new mails using maildir or mbox in this way. Extracting the headers of a mail is something really simple with any basic shell tools. Im currently out of time for coding such stuff, but I think that maybe there's more people interesting on finding an almost decent solution for reading the mail without those complications. The frontend for the mail should be able to follow mail threads, sort by date or grep by contents. following these concepts shouldnt be hard to create an usable frontend for the web or a phone/pda...squirrelmail is also to blame...and writing a simple cgi using these tools will be quite simple and useful. I hope this brainstorming helps somebody to start coding them. What do you think? are you happy with your MUA? --pancake -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] malloc'ed client in manage()
On (09/09/08 09:13), Szabolcs Nagy wrote:
To: dwm mail list dwm@suckless.org
From: Szabolcs Nagy [EMAIL PROTECTED]
Subject: Re: [dwm] malloc'ed client in manage()
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
On 9/8/08, Anselm R Garbe [EMAIL PROTECTED] wrote:
but if we really care about obscure 30 year old cpus (other than x86
:)) then i'd go with my solution: c = malloc(); and *c = (Client){};
Well, I agree on this proposal and go for it. It is fairly simple and
nice looking imho.
sorry i misread the standard
eventhough it sais
If there are fewer initializers in a brace-enclosed list than there
are elements or members of an aggregate, or fewer characters in a
string literal used to initialize an array of known size than there
are elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration.
the initializer list must contain at least one element so the empty {}
is not enough. (easy to overlook since it is not stated explicitly,
just the result of the given initializer grammar)
Client can be initialized with {} (first member is .name) or {.x =
0} or whatever, but general zero-init is impossible this way :(
tl;dr: use the original patch
This can be easilly done with patch:
diff -r e4bcaca8e6ef dwm.c
--- a/dwm.c Mon Sep 08 22:24:05 2008 +0100
+++ b/dwm.c Tue Sep 09 10:12:01 2008 +0200
@@ -846,22 +846,21 @@
void
manage(Window w, XWindowAttributes *wa) {
- static Client cz;
Client *c, *t = NULL;
Window trans = None;
XWindowChanges wc;
if(!(c = malloc(sizeof(Client
die(fatal: could not malloc() %u bytes\n, sizeof(Client));
- *c = cz;
- c-win = w;
+ *c = (const Client){
+ .win = w,
+ .x = wa-x,
+ .y = wa-y,
+ .w = wa-width,
+ .h = wa-height,
+ .oldbw = wa-border_width,
+ };
- /* geometry */
- c-x = wa-x;
- c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
- c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
c-y = sy;
But, I dislike this whole !calloc solution. BTW: there are plenty of places
which expects that NULL == 0 - false ...
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Notifications
On (29/09/08 17:18), Carlos Pita wrote: To: dwm@suckless.org From: Carlos Pita [EMAIL PROTECTED] Subject: [dwm] Notifications Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Hi, I use irssi+bitlbee to cover all my im/irc needs. Up til now my window manager was ratpoison and I had programmed a simple perl hook which output the incoming message to ratpoison's status bar. This bar is normally hidden and only shows up when the echo command is called, overlayed above the current window. As I prefer to keep dwm bar hidden by default, I'm not able to see the urgent flag mark that dwm sets on the tag list. So I tried to figure out a way to be notified without permanently wasting the top bar pixels. I came up to two different solutions: 1) toggle the bar visible if urgent hint is set for any client. 2) hack manage() to show (g)xmessages floating bottom right without stealing focus. I'd implemented both variants with relative ease. I think I'll keep the first one as it's the most spartan and requires less changes. What do you think? Anyone had the same problem and came to a different solution? Regards -Carlos For notifications I heavily use urgency wm hint. It's setup is terminal dependent, in (u)rxvt it's as easy as Rxvt.urgentOnBell: true into your .Xresources. The second step is to setup irssi to beep on hilight/query etc. This can be done with: /set beep_msg_level NOTICE MSGS HILIGHT /set beel_beeps OFF and if you run irssi in screen (as I do, I connect to it via ssh) put this into .screenrc: vbell off bell_msg 'Bell in window %n^G' With this all, you can get easily notified by simple beep on terminal, so mutt can notify you on new mail, lftp on download finished etc. etc. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] How to detect TAG activity?
On (03/11/08 14:05), [EMAIL PROTECTED] wrote: To: dwm@suckless.org From: [EMAIL PROTECTED] Subject: [dwm] How to detect TAG activity? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) Hello, I'm using dwm-5.2, my question is related to window events that trigger the change of the TAG color, I have a messenger (pidgin) which triggers that event whenever a new message is received and another messenger (kopete) which does not. Could you please advise me how do applications trigger the changing of the TAG colour? Does dwm listen for some special event signal or similar? Thank you. Veselin It is triggered by Urgency hint, which is something like flag heey, I have something urgent for user, which every window can setup (on it's own). You can also set it up for any window, if you know window ID. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] How to detect TAG activity?
On (03/11/08 16:02), [EMAIL PROTECTED] wrote: To: dwm mail list dwm@suckless.org From: [EMAIL PROTECTED] Subject: Re: [dwm] How to detect TAG activity? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) Thanks for the tips guys. Kopete does not seem to set the URGENT flag but it offers tha ability to launch an app when a new message is received. Would it be possible to write a shell script that sends an URGENT flag to a specific window/tag ? Veselin On Mon, Nov 03, 2008 at 03:48:25PM +0100, Premysl Hruby wrote: On (03/11/08 14:05), [EMAIL PROTECTED] wrote: To: dwm@suckless.org From: [EMAIL PROTECTED] Subject: [dwm] How to detect TAG activity? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) Hello, I'm using dwm-5.2, my question is related to window events that trigger the change of the TAG color, I have a messenger (pidgin) which triggers that event whenever a new message is received and another messenger (kopete) which does not. Could you please advise me how do applications trigger the changing of the TAG colour? Does dwm listen for some special event signal or similar? Thank you. Veselin It is triggered by Urgency hint, which is something like flag heey, I have something urgent for user, which every window can setup (on it's own). You can also set it up for any window, if you know window ID. -Ph Hi, I wrote application which can set urgency tag to given window. But you must know that window id, dunno if you can get it from kopete in some simple way -- if not, you must write/find program which call XQueryTree and return window id of searched window. http://www.redrum.cz/hg/wmu -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] How to detect TAG activity?
On (04/11/08 16:37), yy wrote: To: dwm mail list dwm@suckless.org From: yy [EMAIL PROTECTED] Subject: Re: [dwm] How to detect TAG activity? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org 2008/11/4 markus schnalke [EMAIL PROTECTED]: I think it is worth to add this script (or an improved version) with explanations to the wiki. Any volunteer? (I don't have time atm.) meillo I could do it. I can submit it today or tomorrow, but then I think wmu should be included in the hg repository (the script could go inside the tarball). This is up to Anselm, of course. -- - yiyus || JGL . In which repository do you mean that wmu should be included? I can add this script to wmu's repo, as it is pretty handy. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] How to detect TAG activity?
On (04/11/08 11:04), [EMAIL PROTECTED] wrote: To: Matthias Kirschner [EMAIL PROTECTED], dwm@suckless.org From: [EMAIL PROTECTED] Subject: Re: [dwm] How to detect TAG activity? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) Hello Matthias, For a cleaner approach, just put that command into a shell script. Lets say kopete_events.sh: #!/bin/bash /usr/bin/wmu 1 `/usr/bin/xwininfo -int -name Kopete|egrep Window\ id:|cut -d' ' -f4` Assuming that you installed wmu in /usr/bin Make kopete_events.sh executable. Then, in Kopete, under Configure Notifications you can set Execute a program when An incoming message has been received. Also make sure you Enable events for active chat windows in SettingsBehaviourEvents. Veselin Hi, I've added you script (with markus schnalke's generalization) to the wmu's repo. thx. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] patch to not reparent children to init
On (06/11/08 09:53), Neale Pickett wrote:
To: dwm mail list dwm@suckless.org
From: Neale Pickett [EMAIL PROTECTED]
Subject: Re: [dwm] patch to not reparent children to init
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
Donald Chai [EMAIL PROTECTED] writes:
On Tue, Nov 4, 2008 at 9:09 AM, Neale Pickett [EMAIL PROTECTED] wrote:
Reparenting everything to init with the double-fork is a nightmare on a
many-user machine, especially when I'm logged in more than once. pstree
becomes useless. This sets up a SIGCHLD handler and only forks once.
Adds 2 SLOC, but surely there's some reason the double-fork is there that
I'm just missing...
If you quit dwm, what happens to any programs that you've launched?
Nothing, the setsid() call makes children process group leaders so they
don't receive any of the signals the parent gets.
What happens if you suddenly decide to manage all your windows with a
different window manager?
Suddenly all my windows have title bars, there are background menus, and
I find myself using the mouse a lot ;)
Given that dwm doesn't come with a facility to launch a new wm, I'm not
terribly worried about either of these cases. But here's a function to
restart dwm or change to a new wm (why would you want to do that?!),
anyway, so you can try it out for yourself and see what happens:
void
restart(const Arg *arg)
{
if (arg-v) {
execvp(((char **)arg-v[0]), (char **)arg-v);
} else {
execlp(dwm, dwm, NULL);
}
}
In all seriousness, the only thing this changes for me is making the
output of pstree useful. When there are 20 X sessions on the machine
and I need to kill a stuck firefox, having useful pstree output is super
handy. If everything's a child of init, the output is flat, and I have
to pull out my hair. Nobody wants that, least of all my head.
Neale
pkill -u $USER firefox
that's all, no searching pstree etc etc. :)
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] urxvt and show/hide bar
On (11/11/08 01:01), Carlos Pita wrote: To: dwm mail list dwm@suckless.org From: Carlos Pita [EMAIL PROTECTED] Subject: [dwm] urxvt and show/hide bar Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Hi all, I usually prefer to keep the bar hidden so I've written a tiny patch in order to show it when a window has the urgent hint. But when I'm working with the urxvt term and the bar appears, the last line in the console is duplicated, a phantom version of it appears below it. If I change the tag or the layout, or hide the bar again, the term is redrawn correctly again. Any ideas? Best regards -Carlos Hi, Afaik there's no easy solution, as (u)rxvt depends with this on having window size be multiple of windows size increments (given by wmhints). But this iirc is NOT MUST by ICCCM. This is how this broblem occur, the last line is duplicated, because rxvt doesn't redraw it (because it think that it have window size given by itself -- which mustn't be true in tile mode with resizehints == false). -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Re: What happened here?
On (20/01/09 09:49), henry atting wrote: To: dwm@suckless.org From: henry atting nspm...@literaturlatenight.de Subject: [dwm] Re: What happened here? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:WaXw8qx3RxRmlkx9dQJG0B9fg4s= I recently switched from dwm to xmonad. I did not like the rigid constraint on a certain number of code lines. The resulting way of doing it with patches in my opinion is not very sincere. I needed only two - and they did not match. I don't see any rigid constraint, as for SLOC, we are now pretty far from 2k SLOC as current dwm has ~1.5k SLOCs. I personaly see this limit as only expression of something like: we don't want dbus etc etc. Though I do not know haskell at all I find it very simple to configure xmonad, took me an hour or so to get things done. But on the other hand being no coder I do not fit into the dwm target group anyhow. ;) henry -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] OT: Bottom-posting and reply trimming (was: Bottom Stack Patch)
On (10/02/09 06:51), Kurt H Maier wrote: To: dwm mail list dwm@suckless.org From: Kurt H Maier karmaf...@gmail.com Subject: Re: [dwm] Bottom-posting and reply trimming (was: Bottom Stack Patch) Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Please mark mailing-list etiquette posts as off-topic, so my mail client and filter them appropriately. Thanks. # Kurt H Maier Why you want others to do something, which you don't do yourself. (Your email wasn't marked as OT) -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [PATCH] small fix in propertynotify
On (12/02/09 17:16), Enno Gottox Boland wrote: To: dwm mail list d...@lists.suckless.org From: Enno Gottox Boland got...@gmail.com Subject: [dwm] [PATCH] small fix in propertynotify Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org looks like a typo. Yes, it was. Now it's gone thanks to you. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Tag masks
On (17/02/09 17:04), Jake Todd wrote:
To: dwm@suckless.org
From: Jake Todd jaketodd...@gmail.com
Subject: [dwm] Tag masks
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
I'm having some trouble with tag masks. From what I understand, they
allow you to place certain windows on specific tags when they are
spawned; please correct me if that is wrong. I've been trying to get
firefox (Iceweasel) to spawn on the second tag, but I have not had any
luck accomplishing this. in my config.h I have my tags set up like this:
static const char tags[][MAXTAGLEN] = { term, web, irc, im,
media, misc };
I've have this for the my tag masks:
static Rule rules[] = {
/* class instancetitle tags mask isfloating
{ Gimp, NULL, NULL, 1 2, True },
{ Navigator, NULL, NULL, 1 4, False },
{ Navigator, NULL, Iceweasel, 1 4,
False },
{ NULL, NULL, Iceweasel, 1 4, False }
};
This hasn't worked so far. I got the class and instance entries from
'xprop WM_CLASS', which returned:
WM_CLASS(STRING) = Navigator, Iceweasel
Does anyone have any other information on this? The 'wiki' has very
limited info in it concerning this, despite it saying that it has
extensive information on it.
Thanks for any help.
{ Navigator, Iceweasel, NULL, 1 1, False }
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] Issues with border
On (19/02/09 13:34), Anselm R Garbe wrote:
To: dwm mail list dwm@suckless.org
From: Anselm R Garbe garb...@gmail.com
Subject: [dwm] Issues with border
Reply-To: dwm mail list dwm@suckless.org
List-Id: dwm mail list dwm.suckless.org
Hi,
I dislike the recent addition of the 0 border if only 1 tiled client
is in the view, reasons:
- gained screen real eastate is very minimal
- configure events are increased by n at any view() and toggleview(),
if n is the number of clients in the view
- corner cases for togglefloating()
- I dislike adjustborder() altogether
So my proposal is: reverting to old behavior (nonoborder), and for
those who like it, use a config.h function like:
void toggleborder(const Arg *arg) {
borderpx = 1 - borderpx;
arrange();
}
And then define a key binding for it.
Opinions?
Kind regards,
--Anselm
I'm pro too, as I really dislike the noborder.
-Ph
--
Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
On (06/03/09 17:24), Joerg van den Hoff wrote: To: dwm mail list dwm@suckless.org From: Joerg van den Hoff j.van_den_h...@fzd.de Subject: Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing] Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) On Thu, Mar 05, 2009 at 09:35:43AM +0100, Szabolcs Nagy wrote: On 3/5/09, Szabolcs Nagy nszabo...@gmail.com wrote: 7587 messages: Starting Wed Jul 19 2006 - 06:39:23 UTC, Ending Thu Mar 05 2009 - 08:03:46 UTC so i wonder which is the no. 7600 if there is only 7538.. 7587 (sorry) well the last one I've got ( Fri, 06 Mar 2009 00:00:09 + ) reads: ==CUT== Hi, this is the mlmmj program managing the mailinglist dwm@suckless.org Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: 7617 ==CUT== right now the archive counts 7610 mails. I presume this is updated only once a day or something? so I can wait a day or so before looking which mail bounced, but still: is there an easy way to find, e.g, message no. 4321? until a few weeks ago I've never seen such bouncing messages. it does'nt occur with any other list, too. regards, joerg Hi, sorry for such a late reply, first: yes, web archive is not updated live but twice a day. That messages you are receiving are just bounce test as reaction to mlmmj receiving bounce message (itself as consequnce of mlmmj trying to send you a message from mail-list). I had saved one bounce message mlmmj received from your MX, and it looks like your MX is acting very strangely (bounce message attached to this email). I hope that it will help you to solve the problem, because from what I can get from bounce message and mail-logs, it looks like problem on your side. Regards, -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ X-Original-To: dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org Delivered-To: dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org X-Greylist: delayed 1324 seconds by postgrey-1.27 at epona; Wed, 18 Feb 2009 23:52:35 UTC Received: from smtpout.fz-rossendorf.de (ix2.fz-rossendorf.de [149.220.4.86]) by code.suckless.org (Postfix) with ESMTP id C66E141C0 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Wed, 18 Feb 2009 23:52:35 + (UTC) Received: from localhost (localhost [127.0.0.1]) by smtpout.fz-rossendorf.de (Postfix) with ESMTP id 9C1B6936C6 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Thu, 19 Feb 2009 00:30:30 +0100 (CET) Received: from smtpout.fz-rossendorf.de ([127.0.0.1]) by localhost (ix2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14521-05-2 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Thu, 19 Feb 2009 00:30:30 +0100 (CET) Received: from fz-rossendorf.de (cg.fzd.de [149.220.4.66]) by smtpout.fz-rossendorf.de (Postfix) with ESMTP id 655E3936C3 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Thu, 19 Feb 2009 00:30:30 +0100 (CET) Subject: Delivery report: Re: [dwm] [OT] Personal Website and CSS From: mailer-dae...@fz-rossendorf.de To: dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org Date: Thu, 19 Feb 2009 00:30:30 +0100 Message-ID: receipt-2044...@cg2.fz-rossendorf.de X-MAPI-Message-Class: REPORT.IPM.Note.DR Precedence: list Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org List-Unsubscribe: mailto:dwm+unsubscr...@suckless.org List-Subscribe: mailto:dwm+subscr...@suckless.org List-Help: mailto:dwm+h...@suckless.org List-Post: mailto:dwm@suckless.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=_===2044759cg2.fz-rossendorf.de===_ X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fz-rossendorf.de --_===2044759cg2.fz-rossendorf.de===_ Content-Type: text/plain; charset=utf-8 Message delivered to 'j.van_den_h...@cg.fzd.de' LOCAL module(account v...@fzd.de) reports: Delivered to the user mailbox --_===2044759cg2.fz-rossendorf.de===_ Content-Type: message/delivery-status Reporting-MTA: dns; cg2.fz-rossendorf.de Original-Recipient: rfc822;j.van_den_h...@cg.fzd.de Final-Recipient: LOCAL;v...@fzd.de Action: delivered Status: 2.0.0 --_===2044759cg2.fz-rossendorf.de===_ Content-Type: text/rfc822-headers Received: from mx1.fz-rossendorf.de ([149.220.142.11] verified) by cg2.fz-rossendorf.de (CommuniGate Pro SMTP 5.2.12) with ESMTP id 2044758 for j.van_den_h...@cg.fzd.de; Thu, 19 Feb 2009 00:30:30 +0100 Received: from localhost (mx1 [127.0.0.1]) by mx1.fz-rossendorf.de (Postfix) with ESMTP id 11EA92FBBF for j.van_den_h...@cg.fzd.de; Thu, 19 Feb 2009 00:30:30 +0100 (CET)
Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
On (07/03/09 11:50), Joerg van den Hoff wrote: To: dwm mail list dwm@suckless.org Cc: Premysl Hruby dfe...@gmail.com From: Joerg van den Hoff j.van_den_h...@fzd.de Subject: Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing] ... Wow, his MTA (or maybe MUA) is sending out a delivery status notification, saying that the message was delivered. I didn't think any MTAs actually did that, it can create many problems (like the current one). Joerg, you should check your mail client to see if it's sending out delivery status notifications (DSNs). What's happening is that your mail client, or your mail server, is responding back to the message I presume, it's our IMAP server in central IT. I'll forward your message. I'm using `mutt' (which at least claims to suck less than other mail clients) and AFAICS should have nothing to do with the delivery notification, right? I'm using mutt too, and have no problem. Do you use any other program/device to access that IMAP account? saying I got it! mlmmj (the list software used at suckless.org, which I happen to have contributed to) treats any response to the envelope sender address as a bounced message. naive question: would it harm if mlmmj would treat the DSN has harmless/irrelevant instead of 'bounced'? No, that's not possible. If you look on that bounce message carefully you will see that your MX is sending it as MAILERDAEMON ( address to be precise) so that's fully featured bounce message. I'm guessing there's some sender on the list who requests delivery status notifications on their outbound messages, and this is why you only see the bounces occasionally. Well, I searched dwm archive and there's no email with header from disposition-notification-* family -- one responsible for requesting that I read your email thingie. I start to get the picture. I'll refrain from expounding on my opinion of DSNs. Check the Internet if you're curious. I always am. thanks again, joerg regards -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] minimal communication
On (06/03/09 21:27), Neale Pickett wrote: To: Ian Daniher it.dani...@gmail.com Cc: dwm mail list dwm@suckless.org From: Neale Pickett ne...@woozle.org Subject: Re: [dwm] minimal communication User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Ian Daniher it.dani...@gmail.com writes: Why do you want to use sic over irssi? Maybe the guy likes a challenge :) irssi is pretty light... The irssi processes on my multi-user server are currently the second biggest memory users. Behind them are the web server, the SMTP, IMAP, and POP3 servers, bitlbee, and even the IRC server! Well, there's problem with perl scripts leaking and memory fragmentation etc. so there's simple solution -- doesn't use any scripts in irssi. Also, you can use /upgrade command from time to time. It just reexec irssi, but your configuration will remain same and you will still use that pretty same connection to irc server -- no quits+rejoins. It certainly isn't anywhere near as heavyweight as, say, pidgin, but I'd stop short of calling irssi pretty light. I'm pretty sure it weighs in heavier than any other text-mode client. Neale -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] irssi + screen + urxvt in dwm - window hint urgent not working
On (07/04/09 10:23), Zhengning Jiang wrote: To: dwm@suckless.org From: Zhengning Jiang zhengto...@gmail.com Subject: [dwm] irssi + screen + urxvt in dwm - window hint urgent not working Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Hi, i have a little problem regarding window hint urgent with my setup. I run a screen with irssi inside on my server and use urxvt as terminal for access. The problem is: dwm does not catch the window hint urgent on new messages from irssi as it should. Here is what i did: .Xdefault: Urxvt.urgentOnBell = true (urxvt version 8.4-1 ... the man page says this flag exists ) .screenrc: bell_msg bell in window %n ^G (yes, i turned vbell off and ^G is a ^V^G) .irssi/config: set bell_beeps ON set beep_msg_level MSGS NOTICES DCC DCCMSGS HILIGHT The strange thing is, if i switch to another session (e.g. vim) inside my screen (and put the dwm focus on another window/label of course) it does work. But it should work without switching the irssi session in my screen. Do you guys have an idea? Thanks in advance! Best regards, zhengtonic For me, this setup works, except I have bell_beeps OFF, but dunno if it make any difference. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
Re: [dwm] Re: New mailing list
On (20/05/09 10:04), Anselm R Garbe wrote: To: dwm mail list dwm@suckless.org, wmii mail list w...@suckless.org From: Anselm R Garbe garb...@gmail.com Subject: Re: [dwm] Re: New mailing list Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org Ok, I meant the following: Let's have hackers@ be some meta list which sends to dwm@ and wmii@, and those subscribed to hackers will receive dwm@ and w...@. Those who are only interested in dwm@ or wmii@ specifically could just stay on dwm@ resp. w...@. That should be technically possible. Kind regards, Anselm Don't forget that hackers@ receive commit emails, imho leave it as is or join all into one ml. Idea for having one ml as sort of syndication ml imho sux :), if someone wants to receive/send both ml, he/she can subscribe/cc them. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
Re: [dwm] Re: New mailing list
On (20/05/09 11:53), Uriel wrote: To: dwm mail list dwm@suckless.org From: Uriel urie...@gmail.com Subject: Re: [dwm] Re: New mailing list Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org The problem is not dwm@ and wmii@, the problem is all the other stuff that is unrelated to either, the only two logical and consistent options are to either we further split the community into st@ dws@ and so on, or we merge everything, and I think that option is a no-brainer. uriel Well, as I said in earlier email, I'm not against merge-all-in-on, I just dislike idea of having hackers@ as sort of alias send to all etc. I even think that having only one ml for all (wmii+dwm+commit mails+other) would be fine for all of us. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ - I'm a signature virus. Please add me to your signature and help me spread!
