[dwm] future of suckless.org
Hi there, a couple of months ago I already announced that suckless.org will be moved to a different host, well the truth is, it will be split into 2 or 3 different hosts soon. I already got access and am setting up a host which will have the domains code.suckless.org lists.suckless.org and which is intended to host the mercurial repositories of the various tools like wmii, dwm, libixp, dmenu, etc. and the mailing lists dwm@, wmii@, and hackers@ -- I'd like to close wmii-hackers@ because that's somehow obsolete in my impression. This host will also contain all releases and a mercurial web interface to browse the source code. There will also be a second host www.suckless.org dwm.suckless.org wmii.suckless.org which will host the wiki(s?) (which will be editable through a public mercurial repository) of the suckless projects. I'd like to see a split of dwm and wmii in the wiki to have its own realm each, because they haven't got much in common nowadays. The roadmap of the switch looks as follows: 1. In the first step I'm going to switch the repositories to the new host, this means that I need a response of all developers who still contribute in one way or the other to any project to send me an ssh key (I change the new host policy to be more restrictive in the matters of access). I'd like to achieve this until end of next week. So please send me your keys now (please use [EMAIL PROTECTED] for this, we will discuss the details via privmail. 2. In the second step I'm going to switch the mailinglist, this will be by end of next week most likely. Note that the domain of the mailinglists will change to lists.suckless.org to make the move of the www part smooth. 3. In the last step I'm going to replace the current diri with a mercurial-based version, which only comes with a viewer and which does not allow HTTP POST based edits anymore. Contributors can push to a public HTTP-based mercurial repository in the future. I'd like to replace the plan9ports-based diri dependency with an sh-based viewer script only. I'd like to discuss this further with the wmii maintainers. Kris are you ok to scrap the rc-based diri in favor of a simple sh-based viewer script only? As you will notice easily, the separate www-host consideration has been made because of security concerns about the wiki being publicly accessible. I for myself have got a third server which I will use personally only in the future, so no of the above hosts is intended for personal use, except if it's in the scope of the suckless project. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
[dwm] Suggestion float my next window
Hi
It's a suggestion to create a float next windows feature.
I also learn that in 5.0 maybe the toggle-float will restore the window
dimension, so maybe this feature is not needed.
Thanks
% diff config.def.h config.h
42a46,53
/* my hack for floater */
Bool td_floater (Bool set_flag) {
static Bool float_flag = False;
Bool f = float_flag;
float_flag = set_flag;
return f;
}
{ MODKEY,XK_f,td_floater,True },
% diff dwm.c.orig dwm.c
1034c1034
c-isfloating = (rettrans == Success) || c-isfixed;
---
c-isfloating = td_floater(False) || (rettrans == Success) ||
c-isfixed; /* td floater hack */
[dwm] more consistent codestyle patch
simple modifications (whitespce, line wrapping)
diff -r f939086fa41d dwm.c
--- a/dwm.c Tue May 13 11:27:20 2008 +0100
+++ b/dwm.c Tue May 13 14:03:20 2008 +0200
@@ -595,7 +595,7 @@ drawtext(const char *text, unsigned long
x = dc.x + (h / 2);
/* shorten text if necessary */
for(; len (w = textnw(buf, len)) dc.w - h; len--);
- if (!len)
+ if(!len)
return;
if(len olen) {
if(len 1)
@@ -782,21 +782,21 @@ grabbuttons(Client *c, Bool focused) {
int i, j;
unsigned int buttons[] = { Button1, Button2, Button3 };
unsigned int modifiers[] = { MODKEY, MODKEY|LockMask, MODKEY|numlockmask,
- MODKEY|numlockmask|LockMask} ;
+MODKEY|numlockmask|LockMask} ;
XUngrabButton(dpy, AnyButton, AnyModifier, c-win);
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);
+ BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
else
XGrabButton(dpy, AnyButton, AnyModifier, c-win, False,
- BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
+ BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
}
void
-grabkeys(void) {
+grabkeys(void) {
unsigned int i, j;
KeyCode code;
XModifierKeymap *modmap;
@@ -1041,7 +1041,7 @@ monocle(void) {
Client *c;
for(c = clients; c; c = c-next)
- if((lt-isfloating || !c-isfloating) isvisible(c, NULL))
+ if((lt-isfloating || !c-isfloating) isvisible(c, NULL))
resize(c, wx, wy, ww - 2 * c-bw, wh - 2 * c-bw, RESIZEHINTS);
}
@@ -1055,7 +1055,7 @@ movemouse(Client *c) {
ocx = nx = c-x;
ocy = ny = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, GrabModeAsync,
- None, cursor[CurMove], CurrentTime) != GrabSuccess)
+ None, cursor[CurMove], CurrentTime) != GrabSuccess)
return;
XQueryPointer(dpy, root, dummy, dummy, x1, y1, di, di, dui);
for(;;) {
@@ -1221,7 +1221,7 @@ resizemouse(Client *c) {
ocx = c-x;
ocy = c-y;
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, GrabModeAsync,
- None, cursor[CurResize], CurrentTime) != GrabSuccess)
+ None, cursor[CurResize], CurrentTime) != GrabSuccess)
return;
XWarpPointer(dpy, None, c-win, 0, 0, 0, 0, c-w + c-bw - 1, c-h + c-bw - 1);
for(;;) {
@@ -1351,7 +1351,7 @@ scan(void) {
if(XQueryTree(dpy, root, d1, d2, wins, num)) {
for(i = 0; i num; i++) {
if(!XGetWindowAttributes(dpy, wins[i], wa)
- || wa.override_redirect || XGetTransientForHint(dpy, wins[i], d1))
+ || wa.override_redirect || XGetTransientForHint(dpy, wins[i], d1))
continue;
if(wa.map_state == IsViewable || getstate(wins[i]) == IconicState)
manage(wins[i], wa);
@@ -1360,7 +1360,7 @@ scan(void) {
if(!XGetWindowAttributes(dpy, wins[i], wa))
continue;
if(XGetTransientForHint(dpy, wins[i], d1)
- (wa.map_state == IsViewable || getstate(wins[i]) == IconicState))
+ (wa.map_state == IsViewable || getstate(wins[i]) == IconicState))
manage(wins[i], wa);
}
}
@@ -1479,8 +1479,8 @@ setup(void) {
wa.event_mask = ButtonPressMask|ExposureMask;
barwin = XCreateWindow(dpy, root, bx, by, bw, bh, 0, DefaultDepth(dpy, screen),
-CopyFromParent, DefaultVisual(dpy, screen),
-CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
+ CopyFromParent, DefaultVisual(dpy, screen),
+ CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
XDefineCursor(dpy, barwin, cursor[CurNormal]);
XMapRaised(dpy, barwin);
strcpy(stext, dwm-VERSION);
@@ -1704,7 +1704,6 @@ unmapnotify(XEvent *e) {
void
updatebar(void) {
-
if(dc.drawable != 0)
XFreePixmap(dpy, dc.drawable);
dc.drawable = XCreatePixmap(dpy, root, bw, bh, DefaultDepth(dpy, screen));
@@ -1839,7 +1838,7 @@ xerror(Display *dpy, XErrorEvent *ee) {
|| (ee-request_code == X_CopyArea ee-error_code == BadDrawable))
return 0;
fprintf(stderr, dwm: fatal error: request code=%d, error code=%d\n,
- ee-request_code, ee-error_code);
+ ee-request_code, ee-error_code);
return xerrorxlib(dpy, ee); /* may call exit */
}
Re: [dwm] Suggestion float my next window
2008/5/13, Tri PLC [EMAIL PROTECTED]: Hi It's a suggestion to create a float next windows feature. I think this has been discussed before. The problem is that you cannot know who is opening the next window, so if a popup dialog appears in that moment you won't have the expected behaviour (actually the problem is not dwm related, but an old X window problem). -- - yiyus || JGL .
Re: [dwm] more consistent codestyle patch
On Tue, May 13, 2008 at 02:05:27PM +0200, Szabolcs Nagy wrote:
simple modifications (whitespce, line wrapping)
U...
--- a/dwm.c Tue May 13 11:27:20 2008 +0100
+++ b/dwm.c Tue May 13 14:03:20 2008 +0200
@@ -782,21 +782,21 @@ grabbuttons(Client *c, Bool focused) {
unsigned int modifiers[] = { MODKEY, MODKEY|LockMask,
MODKEY|numlockmask,
- MODKEY|numlockmask|LockMask} ;
+ MODKEY|numlockmask|LockMask} ;
- BUTTONMASK, GrabModeAsync,
GrabModeSync, None, None);
+ BUTTONMASK, GrabModeAsync,
GrabModeSync, None, None);
XGrabButton(dpy, AnyButton, AnyModifier, c-win, False,
- BUTTONMASK, GrabModeAsync, GrabModeSync, None,
None);
+ BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
}
@@ -1055,7 +1055,7 @@ movemouse(Client *c) {
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
- None, cursor[CurMove], CurrentTime) != GrabSuccess)
+ None, cursor[CurMove], CurrentTime) != GrabSuccess)
return;
@@ -1221,7 +1221,7 @@ resizemouse(Client *c) {
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
- None, cursor[CurResize], CurrentTime) != GrabSuccess)
+ None, cursor[CurResize], CurrentTime) != GrabSuccess)
return;
@@ -1479,8 +1479,8 @@ setup(void) {
barwin = XCreateWindow(dpy, root, bx, by, bw, bh, 0, DefaultDepth(dpy,
screen),
- CopyFromParent, DefaultVisual(dpy, screen),
- CWOverrideRedirect|CWBackPixmap|CWEventMask,
wa);
+ CopyFromParent, DefaultVisual(dpy, screen),
+ CWOverrideRedirect|CWBackPixmap|CWEventMask, wa);
XDefineCursor(dpy, barwin, cursor[CurNormal]);
@@ -1839,7 +1838,7 @@ xerror(Display *dpy, XErrorEvent *ee) {
fprintf(stderr, dwm: fatal error: request code=%d, error code=%d\n,
- ee-request_code, ee-error_code);
+ ee-request_code, ee-error_code);
return xerrorxlib(dpy, ee); /* may call exit */
All of this looks like code uglification to me...
Diego
Re: [dwm] more consistent codestyle patch
On 5/13/08, Diego Biurrun [EMAIL PROTECTED] wrote:
On Tue, May 13, 2008 at 02:05:27PM +0200, Szabolcs Nagy wrote:
simple modifications (whitespce, line wrapping)
U...
All of this looks like code uglification to me...
well imho consistent code style is better than inconsistent
especially if the inconsistency does not serve any purpose
i don't want you to worry about it too much so here is an explanation
of the patch:
1) removed accidental double spaces eg.:
-grabkeys(void) {
+grabkeys(void) {
2) consistent whitespace in selection/iteration statements eg:
- if (!len)
+ if(!len)
3) use tabs for identation (even for line wraps because arg prefers this way):
XGrabButton(dpy, AnyButton, AnyModifier, c-win, False,
- BUTTONMASK, GrabModeAsync, GrabModeSync, None,
None);
+ BUTTONMASK, GrabModeAsync, GrabModeSync, None, None);
4) no extra indentation if the conditional expression of a statement wraps:
if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync,
GrabModeAsync,
- None, cursor[CurResize], CurrentTime) != GrabSuccess)
+ None, cursor[CurResize], CurrentTime) != GrabSuccess)
most of the code already followed these rules and i did not see any
reason not to follow them in the specific cases.
of course i am open to any comment about these style rules
Re: [dwm] more consistent codestyle patch
On Tue, May 13, 2008 at 05:41:30PM +0200, Szabolcs Nagy wrote: On 5/13/08, Diego Biurrun [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 02:05:27PM +0200, Szabolcs Nagy wrote: simple modifications (whitespce, line wrapping) U... All of this looks like code uglification to me... well imho consistent code style is better than inconsistent especially if the inconsistency does not serve any purpose i don't want you to worry about it too much so here is an explanation of the patch: 3) use tabs for identation (even for line wraps because arg prefers this way): XGrabButton(dpy, AnyButton, AnyModifier, c-win, False, - BUTTONMASK, GrabModeAsync, GrabModeSync, None, None); + BUTTONMASK, GrabModeAsync, GrabModeSync, None, None); Well, before it was indented to align with the XGrabButton call. This was consistently done in at least a few places and makes the code more readable. 4) no extra indentation if the conditional expression of a statement wraps: if(XGrabPointer(dpy, root, False, MOUSEMASK, GrabModeAsync, GrabModeAsync, - None, cursor[CurResize], CurrentTime) != GrabSuccess) + None, cursor[CurResize], CurrentTime) != GrabSuccess) Same here, it was aligned to make it clear what expression the next line belongs to. You kill this alignment and make this line less readable. Putting this at the same indentation depth as the if indicates that it is a new block after the if. Contrary to what your indentation indicates, this is not the case. most of the code already followed these rules and i did not see any reason not to follow them in the specific cases. I think you have misunderstood the rules the code was following. Diego
Re: [dwm] more consistent codestyle patch
one more little patch
please review
diff -r 33ba827ee84e dwm.c
--- a/dwm.c Tue May 13 14:33:02 2008 +0100
+++ b/dwm.c Tue May 13 19:01:59 2008 +0200
@@ -504,7 +504,7 @@
detachstack(Client *c) {
Client **tc;
- for(tc=stack; *tc *tc != c; tc=(*tc)-snext);
+ for(tc = stack; *tc *tc != c; tc = (*tc)-snext);
*tc = c-snext;
}
@@ -1162,8 +1162,7 @@
/* adjust for aspect limits */
if(c-minax != c-maxax c-minay != c-maxay
- c-minax 0 c-maxax 0 c-minay 0 c-maxay 0)
- {
+ c-minax 0 c-maxax 0 c-minay 0 c-maxay 0) {
if(w * c-maxay h * c-maxax)
w = h * c-maxax / c-maxay;
else if(w * c-minay h * c-minax)
@@ -1532,7 +1531,7 @@
if(!sel)
return;
for(i = 0; i LENGTH(tags); i++)
- sel-tags[i] = (NULL == arg);
+ sel-tags[i] = (arg == NULL);
sel-tags[idxoftag(arg)] = True;
arrange();
}
Re: [dwm] more consistent codestyle patch
Szabolcs Nagy [EMAIL PROTECTED] wrote: one more little patch please review Looks good. Regards Matthias-Christian
[dwm] wildcard in client rules tags ref
Hi All, DWM used to support regular expressions in the tags ref for client rules. I agree that the feature was overkill but it was nice to be able to say * so a client is on all tags. I used this for background notification popups from scripts with gxmessage. Is it possible to add a simple glob indicator back to DWM that specifies all tags? Or is there another way to do this that I overlooked...? Thanks, - e
