Re: [dwm] xprop patch
Or even simpler =) while dwm do sleep 1 done - Jeremy On Tue 09 Dec 2008 - 04:26PM, Evan Gates wrote: > You can do > while true > do > dwm || exit > done > > This way when you kill dwm correctly (with modkey+shift+q as default) > it respawns, but if you kill it any other way, the Xsession finishes. > You could even add a key binding that does killall dwm or something of > the sort for when you want to end the Xsession. > > -Evan > > On Tue, Dec 9, 2008 at 3:44 PM, Benoit T <[EMAIL PROTECTED]> wrote: > > On Tue, Dec 09, 2008 at 07:44:21PM +, Anselm R Garbe wrote: > >> 2008/12/9 Benoit T <[EMAIL PROTECTED]>: > >> > conversely, when hacking on dwm itself, i like being able to restart dwm > >> > without restarting my x session, yet i want the session to exit when dwm > >> > exits, ie. "dwm & xterm" in .xsession is not what i want. > >> > >> If you consider that Neale's patch makes it upstream, what do you think > >> about: > >> > >> while true > >> do > >> dwm > >> done > >> > >> in .xinitrc to restart dwm? > > > > One of my requirements above was that quitting dwm should quit the X > > session. Here you would have to kill .xsession. This can certainly be > > done by killing dwm's parent in quit() but then the behavior when dwm is > > launched from an xterm would be counter-intuitive! > > > > > > Also, I initially had the requirement of being able to exec dwm at the > > end of .xsession (and have a restart function). But you don't do that > > with dwm reading from stdin, so no way to save one shell process. > > > > With Neale's patch I can finally fulfill that requirement :) > > > > One might point out that we still want one shell process for the status > > script, and that shell could be the one interpreting .xsession and thus > > we do not need exec'ing dwm in the first place. > > > > I know of 2 reasons why we still want a separate process for the status > > script: > > - I can't think of a way to update the status script if it is sourced by > > .xsession rather than forked. > > - the status script might break (after all I am hacking it :) and if > > sourced by .xsession could prevent the entire X session from starting up. > > > > > > Speaking of a separate process, people should probably check the status > > from xsetroot and exit when the X connection closes, to make it more > > robust in case they detach the status script from the parent X process. > > > > cheers > > > > -- > > Benoit Triquet > > .''`. > > : :' : We are debian.org. Lower your prices, surrender your code. > > `. `' We will add your hardware and software distinctiveness to > > `-our own. Resistance is futile. > > > > >
Re: [dwm] applyrules()
2008/12/6 yy <[EMAIL PROTECTED]>:
> Great 5.3.1 release!
>
> What about this little change in applyrules?
> @@ -259,7 +259,7 @@
>&& (!r->class || (ch.res_class &&
> strstr(ch.res_class, r->class)))
>&& (!r->instance || (ch.res_name &&
> strstr(ch.res_name, r->instance {
>c->isfloating = r->isfloating;
> - c->tags |= r->tags & TAGMASK;
> + c->tags |= r->tags & TAGMASK ? r->tags
> & TAGMASK : tagset[seltags];
>}
>}
>if(ch.res_class)
>
> This way you can define rules like:
>{ "MPlayer",NULL, NULL, 0,True },
>{ "MPlayer",NULL, NULL, 1 << 6, True },
> and have mplayer tagged to the currently selected tags and to the 6th
> tag, for example. This trick is very convenient to group windows by
> categories, I do it with image viewers, music players... and I think
> it makes clearer the rules definition. With the current
> implementation, if r->tags is 0 the result of applying that rule is
> undefined depending on the previous rules. The only problem I can see
> is that somebody could be doing:
>{ NULL, NULL, NULL, 0,True },
> to treat new windows like float by default, by I doubt there's anybody
> here doing such a thing...
> - yiyus || JGL .
I see the use and won't worry to much about this corner case. I
consider making this mainstream as well.
Kind regards,
--Anselm
Re: [dwm] [slock] slock doesn't like to deactivate after password entry
On Tue, Dec 9, 2008 at 4:48 AM, Anselm R Garbe <[EMAIL PROTECTED]> wrote: > 2008/12/9 Ali Gholami Rudi <[EMAIL PROTECTED]>: >> On Mon, Dec 08, 2008 at 04:00:48PM -0800, Thayer Williams wrote: >>> I've been using slock for about two months now and, as per the >>> subject, slock doesn't release my screen right away after a valid >>> password entry. After inputing the password and pressing Enter, the >>> screen remains blanked and no amount of input brings it up. I can >>> actually see the LCD backlight flicking on and off with each >>> subsequent keypress or mouse wiggle. >> >> I don't know how to handle others, but I use this patch for handling the >> flickering problem. AFAIK turning a lamp on and off excessively >> decreases its lifetime; that might be true for displays, too. Ali, thanks for that! This works great and I like the fact that I can customise the timeout values. It's too early to say for sure, but it also looks like your patch fixed my input issues (though I'm not sure how that could be). I've been using it for a few hours now and haven't encountered any problems yet. Cheers
Re: [dwm] xprop patch
2008/12/9 Neale Pickett <[EMAIL PROTECTED]>: > I very much like this patch. I realized right away that I would never > again need to restart dwm when I work on my status script. When it > dies, I can just start it up again without restarting DWM. Someone > could even have multiple programs running to update the status text. It > removes the need for the "readin" variable: you either set the property > or you don't. I dislike X properties, however I like your patch a lot and consider it making mainstream, since it simplifies dwm a lot and fixes a lot of issues. dwm depends on X anyways, so for the status text mechanism to happen, it's the simpler method. > This would be 40 if the property were hard coded to XA_WM_NAME. I left > in a comment to use a property named "DWM_STATUS" instead of XA_WM_NAME, > so people could play with it easily, but I think XA_WM_NAME is > ultimately the right way to do it. XA_WM_NAME is the way to go. Kind regards, --Anselm
Re: [dwm] xprop patch
Benoit, I'm still confused about what you want. I have a "restart"
function in my config.h that also lets me start a different WM
(currently unused):
void
restart(const Arg *arg)
{
if (arg->v) {
execvp(((char **)arg->v)[0], (char **)arg->v);
} else {
execlp("dwm", "dwm", NULL);
}
}
There's really no reason to keep the always-empty argv around in your
patch: dwm's only argument is "-v", in which case it prints the version
and exits.
Benoit T <[EMAIL PROTECTED]> writes:
> Speaking of a separate process, people should probably check the
> status from xsetroot and exit when the X connection closes, to make it
> more robust in case they detach the status script from the parent X
> process.
Oh right, I forgot that when I typed in my email
So you'll want to use something like:
xsetroot -name "$(date)" || exit 0
or
status | while read line; do xsetroot -name "$line" || break; done
However, if you restart X before it has a chance to write, you will have
*two* status processes running. Dealing with this is left as an
exercise to the hacker.
Neale
Re: [dwm] xprop patch
You can do while true do dwm || exit done This way when you kill dwm correctly (with modkey+shift+q as default) it respawns, but if you kill it any other way, the Xsession finishes. You could even add a key binding that does killall dwm or something of the sort for when you want to end the Xsession. -Evan On Tue, Dec 9, 2008 at 3:44 PM, Benoit T <[EMAIL PROTECTED]> wrote: > On Tue, Dec 09, 2008 at 07:44:21PM +, Anselm R Garbe wrote: >> 2008/12/9 Benoit T <[EMAIL PROTECTED]>: >> > conversely, when hacking on dwm itself, i like being able to restart dwm >> > without restarting my x session, yet i want the session to exit when dwm >> > exits, ie. "dwm & xterm" in .xsession is not what i want. >> >> If you consider that Neale's patch makes it upstream, what do you think >> about: >> >> while true >> do >> dwm >> done >> >> in .xinitrc to restart dwm? > > One of my requirements above was that quitting dwm should quit the X > session. Here you would have to kill .xsession. This can certainly be > done by killing dwm's parent in quit() but then the behavior when dwm is > launched from an xterm would be counter-intuitive! > > > Also, I initially had the requirement of being able to exec dwm at the > end of .xsession (and have a restart function). But you don't do that > with dwm reading from stdin, so no way to save one shell process. > > With Neale's patch I can finally fulfill that requirement :) > > One might point out that we still want one shell process for the status > script, and that shell could be the one interpreting .xsession and thus > we do not need exec'ing dwm in the first place. > > I know of 2 reasons why we still want a separate process for the status > script: > - I can't think of a way to update the status script if it is sourced by > .xsession rather than forked. > - the status script might break (after all I am hacking it :) and if > sourced by .xsession could prevent the entire X session from starting up. > > > Speaking of a separate process, people should probably check the status > from xsetroot and exit when the X connection closes, to make it more > robust in case they detach the status script from the parent X process. > > cheers > > -- > Benoit Triquet > .''`. > : :' : We are debian.org. Lower your prices, surrender your code. > `. `' We will add your hardware and software distinctiveness to > `-our own. Resistance is futile. > >
Re: [dwm] xprop patch
On Tue, Dec 09, 2008 at 07:44:21PM +, Anselm R Garbe wrote: > 2008/12/9 Benoit T <[EMAIL PROTECTED]>: > > conversely, when hacking on dwm itself, i like being able to restart dwm > > without restarting my x session, yet i want the session to exit when dwm > > exits, ie. "dwm & xterm" in .xsession is not what i want. > > If you consider that Neale's patch makes it upstream, what do you think about: > > while true > do > dwm > done > > in .xinitrc to restart dwm? One of my requirements above was that quitting dwm should quit the X session. Here you would have to kill .xsession. This can certainly be done by killing dwm's parent in quit() but then the behavior when dwm is launched from an xterm would be counter-intuitive! Also, I initially had the requirement of being able to exec dwm at the end of .xsession (and have a restart function). But you don't do that with dwm reading from stdin, so no way to save one shell process. With Neale's patch I can finally fulfill that requirement :) One might point out that we still want one shell process for the status script, and that shell could be the one interpreting .xsession and thus we do not need exec'ing dwm in the first place. I know of 2 reasons why we still want a separate process for the status script: - I can't think of a way to update the status script if it is sourced by .xsession rather than forked. - the status script might break (after all I am hacking it :) and if sourced by .xsession could prevent the entire X session from starting up. Speaking of a separate process, people should probably check the status from xsetroot and exit when the X connection closes, to make it more robust in case they detach the status script from the parent X process. cheers -- Benoit Triquet .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: [dwm] xprop patch
2008/12/9 Benoit T <[EMAIL PROTECTED]>: > On Tue, Dec 09, 2008 at 10:41:35AM -0700, Neale Pickett wrote: >> I very much like this patch. I realized right away that I would never >> again need to restart dwm when I work on my status script. When it >> dies, I can just start it up again without restarting DWM. Someone >> could even have multiple programs running to update the status text. It >> removes the need for the "readin" variable: you either set the property >> or you don't. >> >> The patch removes 39 SLOC: > > gotta admit Neale has 2 points :) > > i like the idea of not having to restart dwm when hacking on the status > script > > conversely, when hacking on dwm itself, i like being able to restart dwm > without restarting my x session, yet i want the session to exit when dwm > exits, ie. "dwm & xterm" in .xsession is not what i want. > > here is a "respawn" patch. it is most useful in conjunction with a > "local install" in the makefile, copying the newly built dwm binary over > the currently running one, inside my $HOME rather than in /usr/local > > the patch costs 5 loc in the source + 1 loc in config.h > the patch is not completely portable due to use of ``environ''. i hope > that even the BSDs have that nowadays, but probably not through defining > _GNU_SOURCE, which is glibc specific. If you consider that Neale's patch makes it upstream, what do you think about: while true do dwm done in .xinitrc to restart dwm? Kind regards, --Anselm
Re: [dwm] xprop patch
On Tue, Dec 09, 2008 at 10:41:35AM -0700, Neale Pickett wrote:
> I very much like this patch. I realized right away that I would never
> again need to restart dwm when I work on my status script. When it
> dies, I can just start it up again without restarting DWM. Someone
> could even have multiple programs running to update the status text. It
> removes the need for the "readin" variable: you either set the property
> or you don't.
>
> The patch removes 39 SLOC:
gotta admit Neale has 2 points :)
i like the idea of not having to restart dwm when hacking on the status
script
conversely, when hacking on dwm itself, i like being able to restart dwm
without restarting my x session, yet i want the session to exit when dwm
exits, ie. "dwm & xterm" in .xsession is not what i want.
here is a "respawn" patch. it is most useful in conjunction with a
"local install" in the makefile, copying the newly built dwm binary over
the currently running one, inside my $HOME rather than in /usr/local
the patch costs 5 loc in the source + 1 loc in config.h
the patch is not completely portable due to use of ``environ''. i hope
that even the BSDs have that nowadays, but probably not through defining
_GNU_SOURCE, which is glibc specific.
cheers
--
Benoit Triquet
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
diff -ruN orig/dwm-5.3.1/config.def.h dwm-5.3.1/config.def.h
--- orig/dwm-5.3.1/config.def.h 2008-12-06 10:33:03.0 +0100
+++ dwm-5.3.1/config.def.h 2008-12-09 20:12:45.0 +0100
@@ -80,7 +80,8 @@
TAGKEYS(XK_7, 6)
TAGKEYS(XK_8, 7)
TAGKEYS(XK_9, 8)
- { MODKEY|ShiftMask, XK_q, quit, {0} },
+ { MODKEY|ShiftMask, XK_q, quit, {.i = 0 } },
+ { MODKEY|ShiftMask|ControlMask, XK_q, quit, {.i = 1 } },
};
/* button definitions */
diff -ruN orig/dwm-5.3.1/dwm.c dwm-5.3.1/dwm.c
--- orig/dwm-5.3.1/dwm.c 2008-12-06 10:33:03.0 +0100
+++ dwm-5.3.1/dwm.c 2008-12-08 20:33:16.0 +0100
@@ -23,6 +23,7 @@
*
* To understand everything else, start reading main().
*/
+#define _GNU_SOURCE
#include
#include
#include
@@ -238,6 +240,7 @@
static DC dc;
static Layout *lt[] = { NULL, NULL };
static Window root, barwin;
+static char **args;
/* configuration, allows nested code to access above variables */
#include "config.h"
@@ -1026,6 +1032,8 @@
void
quit(const Arg *arg) {
+ if(arg->i) /* restart dwm, if fails just fall through and exit */
+ execve(args[0], args, environ);
readin = running = False;
}
@@ -1733,6 +1741,7 @@
if(!(dpy = XOpenDisplay(0)))
die("dwm: cannot open display\n");
+ args = argv;
checkotherwm();
setup();
scan();
[dwm] xprop patch
I very much like this patch. I realized right away that I would never
again need to restart dwm when I work on my status script. When it
dies, I can just start it up again without restarting DWM. Someone
could even have multiple programs running to update the status text. It
removes the need for the "readin" variable: you either set the property
or you don't.
The patch removes 39 SLOC:
1546dwm-5.3.1 ansic=1546
1585dwm-5.3.1-orig ansic=1585
This would be 40 if the property were hard coded to XA_WM_NAME. I left
in a comment to use a property named "DWM_STATUS" instead of XA_WM_NAME,
so people could play with it easily, but I think XA_WM_NAME is
ultimately the right way to do it.
To use this, modify your status script to use "xsetroot -name" instead
of "echo". For instance:
while true; do
xsetroot -name "$(date)"
sleep 1
done
You could also pipe an existing status script to an xsetroot loop like
so:
status | while read line; do xsetroot -name "$line"; done
If you'd prefer to not use the otherwise-unused WM_NAME property of the
root window, uncomment the commented "statusatom" line, and use xprop as
I detailed in my previous email to the list. I decided WM_NAME was a
good choice, since the default is to display "dwm-"VERSION, and since
xsetroot has a nicer syntax than xprop.
Neale
-8<- cut here -8<-
diff -ur dwm-5.3.1.orig/config.def.h dwm-5.3.1/config.def.h
--- dwm-5.3.1.orig/config.def.h 2008-12-06 02:33:03.0 -0700
+++ dwm-5.3.1/config.def.h 2008-12-08 22:39:49.0 -0700
@@ -12,7 +12,6 @@
static unsigned int snap= 32; /* snap pixel */
static Bool showbar = True; /* False means no bar */
static Bool topbar = True; /* False means bottom bar */
-static Bool readin = True; /* False means do not read
stdin */
static Bool usegrab = False;/* True means grabbing the X
server
during mouse-based resizals
*/
diff -ur dwm-5.3.1.orig/dwm.c dwm-5.3.1/dwm.c
--- dwm-5.3.1.orig/dwm.c2008-12-06 02:33:03.0 -0700
+++ dwm-5.3.1/dwm.c 2008-12-08 22:39:49.0 -0700
@@ -6,12 +6,9 @@
* events about window (dis-)appearance. Only one X connection at a time is
* allowed to select for this event mask.
*
- * Calls to fetch an X event from the event queue are blocking. Due reading
- * status text from standard input, a select()-driven main loop has been
- * implemented which selects for reads on the X connection and STDIN_FILENO to
- * handle all data smoothly. The event handlers of dwm are organized in an
- * array which is accessed whenever a new event has been fetched. This allows
- * event dispatching in O(1) time.
+ * The event handlers of dwm are organized in an array which is accessed
+ * whenever a new event has been fetched. This allows event dispatching
+ * in O(1) time.
*
* Each child of the root window is called a client, except windows which have
* set the override_redirect flag. Clients are organized in a global
@@ -30,7 +27,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -196,6 +192,7 @@
static void updategeom(void);
static void updatenumlockmask(void);
static void updatesizehints(Client *c);
+static void updatestatus(void);
static void updatetitle(Client *c);
static void updatewmhints(Client *c);
static void view(const Arg *arg);
@@ -227,7 +224,7 @@
[PropertyNotify] = propertynotify,
[UnmapNotify] = unmapnotify
};
-static Atom wmatom[WMLast], netatom[NetLast];
+static Atom wmatom[WMLast], netatom[NetLast], statusatom;
static Bool otherwm;
static Bool running = True;
static Client *clients = NULL;
@@ -998,9 +995,11 @@
Window trans;
XPropertyEvent *ev = &e->xproperty;
- if(ev->state == PropertyDelete)
+ if((ev->window == root) && (ev->atom = statusatom))
+ updatestatus();
+ else if(ev->state == PropertyDelete)
return; /* ignore */
- if((c = getclient(ev->window))) {
+ else if((c = getclient(ev->window))) {
switch (ev->atom) {
default: break;
case XA_WM_TRANSIENT_FOR:
@@ -1026,7 +1025,7 @@
void
quit(const Arg *arg) {
- readin = running = False;
+ running = False;
}
void
@@ -1180,60 +1179,13 @@
void
run(void) {
- char *p;
- char sbuf[sizeof stext];
- fd_set rd;
- int r, xfd;
- unsigned int len, offset;
XEvent ev;
- /* main event loop, also reads status text from stdin */
+ /* main event loop */
XSync(dpy, False);
- xfd = ConnectionNumber(dpy);
- offset = 0;
- len = sizeof stext - 1;
- sbuf[len] = stext[len] = '\0'; /* 0-terminator is never touched */
- while(running) {
- FD_ZERO(&rd);
- if(readin)
-
Re: [dwm] [slock] slock doesn't like to deactivate after password entry
2008/12/9 Ali Gholami Rudi <[EMAIL PROTECTED]>:
> On Mon, Dec 08, 2008 at 04:00:48PM -0800, Thayer Williams wrote:
>> I've been using slock for about two months now and, as per the
>> subject, slock doesn't release my screen right away after a valid
>> password entry. After inputing the password and pressing Enter, the
>> screen remains blanked and no amount of input brings it up. I can
>> actually see the LCD backlight flicking on and off with each
>> subsequent keypress or mouse wiggle.
>
> I don't know how to handle others, but I use this patch for handling the
> flickering problem. AFAIK turning a lamp on and off excessively
> decreases its lifetime; that might be true for displays, too.
>
> Regards,
> Ali
>
> diff --git a/slock.c b/slock.c
> --- a/slock.c
> +++ b/slock.c
> @@ -79,6 +79,7 @@
>XColor black, dummy;
>XEvent ev;
>XSetWindowAttributes wa;
> + CARD16 standby, suspend, off;
>
>if((argc == 2) && !strcmp("-v", argv[1]))
>die("slock-"VERSION", (c) 2006-2008 Anselm R Garbe\n");
> @@ -123,12 +124,14 @@
>len = 0;
>XSync(dpy, False);
>
> + /* save and customize DPMS settings */
> + if (DPMSCapable(dpy)) {
> + DPMSGetTimeouts(dpy, &standby, &suspend, &off);
> + DPMSSetTimeouts(dpy, 10, 30, 90);
> + }
> +
>/* main event loop */
>while(running && !XNextEvent(dpy, &ev)) {
> - if(len == 0 && DPMSCapable(dpy)) {
> - DPMSEnable(dpy);
> - DPMSForceLevel(dpy, DPMSModeOff);
> - }
>if(ev.type == KeyPress) {
>buf[0] = 0;
>num = XLookupString(&ev.xkey, buf, sizeof buf, &ksym,
> 0);
> @@ -170,6 +173,10 @@
>}
>}
>}
> + /* restore DPMS settings */
> + if (DPMSCapable(dpy)) {
> + DPMSSetTimeouts(dpy, standby, suspend, off);
> + }
>XUngrabPointer(dpy, CurrentTime);
>XFreePixmap(dpy, pmap);
>XDestroyWindow(dpy, w);
I agree, I consider this going upstream Ali!
Kind regards,
--Anselm
Re: [dwm] [slock] slock doesn't like to deactivate after password entry
Hi,
On Mon, Dec 08, 2008 at 04:00:48PM -0800, Thayer Williams wrote:
> I've been using slock for about two months now and, as per the
> subject, slock doesn't release my screen right away after a valid
> password entry. After inputing the password and pressing Enter, the
> screen remains blanked and no amount of input brings it up. I can
> actually see the LCD backlight flicking on and off with each
> subsequent keypress or mouse wiggle.
I don't know how to handle others, but I use this patch for handling the
flickering problem. AFAIK turning a lamp on and off excessively
decreases its lifetime; that might be true for displays, too.
Regards,
Ali
diff --git a/slock.c b/slock.c
--- a/slock.c
+++ b/slock.c
@@ -79,6 +79,7 @@
XColor black, dummy;
XEvent ev;
XSetWindowAttributes wa;
+ CARD16 standby, suspend, off;
if((argc == 2) && !strcmp("-v", argv[1]))
die("slock-"VERSION", © 2006-2008 Anselm R Garbe\n");
@@ -123,12 +124,14 @@
len = 0;
XSync(dpy, False);
+ /* save and customize DPMS settings */
+ if (DPMSCapable(dpy)) {
+ DPMSGetTimeouts(dpy, &standby, &suspend, &off);
+ DPMSSetTimeouts(dpy, 10, 30, 90);
+ }
+
/* main event loop */
while(running && !XNextEvent(dpy, &ev)) {
- if(len == 0 && DPMSCapable(dpy)) {
- DPMSEnable(dpy);
- DPMSForceLevel(dpy, DPMSModeOff);
- }
if(ev.type == KeyPress) {
buf[0] = 0;
num = XLookupString(&ev.xkey, buf, sizeof buf, &ksym,
0);
@@ -170,6 +173,10 @@
}
}
}
+ /* restore DPMS settings */
+ if (DPMSCapable(dpy)) {
+ DPMSSetTimeouts(dpy, standby, suspend, off);
+ }
XUngrabPointer(dpy, CurrentTime);
XFreePixmap(dpy, pmap);
XDestroyWindow(dpy, w);
Re: [dwm] dwm-5.3
2008/12/9 Szabolcs Nagy <[EMAIL PROTECTED]>: > On 12/8/08, Neale Pickett <[EMAIL PROTECTED]> wrote: >> I sort of like the idea of using X properties. You could use xprop to > > one of the most ununixy interfaces > > man XGetWindowProperty > > I agree 100%. The idea of X properties can seem appealing at first, but it is a pain to use them. I really doubt you can remove loc with it. Anyway, I feel curiosity for a patch in this direction, it could be good to have it for reference, to compare. If you don't try, you'll never know for sure. -- - yiyus || JGL .
Re: [dwm] dwm-5.3
On 12/8/08, Neale Pickett <[EMAIL PROTECTED]> wrote: > I sort of like the idea of using X properties. You could use xprop to one of the most ununixy interfaces man XGetWindowProperty
