Re: [dwm] [RFC] dwm-win32
Daniel Bainton writes: > Yeah, apparently something is wrong with Marc's email host. I'm going to guess it's because his outbound (and apparently inbound) mail is all routed through genotec.ch, which is (obviously) not the same string as brain-dump.org. Genotec appears to add a domain-keys header as well, compounding the problem.
Re: [dwm] Suckess Code Management
Typically I have three windows open: Emacs and rxvt on tag 1, and Firefox on tag 2. Emacs runs in less RAM than Firefox or what many of you use for playing music, and it does all of the following: Emacs: editor, chat (rcirc + bitlbee, comint), email (gnus), rss (gnus), address book (bbdb), shell (eshell), calendar (calendar), calculator (calc), music (eshell + ogg123), IDE, remote machine access (tramp) I am astounded by how many respondents regularly use file managers!
Re: [dwm] minimal communication
Ian Daniher 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! 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
Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
Premysl Hruby writes: > 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). 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 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. 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. I'll refrain from expounding on my opinion of DSNs. Check the Internet if you're curious. Neale
Re: [dwm] xgamma notify
On 3/6/2009, "markus schnalke" wrote: >I modified `slock' some time ago to display a fullscreen red window >that closes on any button press. I use it to notify about low battery. That reminds me, I used to use xrefresh for something similar. xrefresh -solid red If you have a fancypants graphics card it might not last long enough to notice.
Re: [dwm] xgamma notify
On 3/5/2009, "Engin Tola" wrote: >the problem with xmessage is that it steals the focus. do you know a way >to prevent it from doing that ? I haven't looked into it. When my battery is at 5%, I want to be sure I'm aware of it.
Re: [dwm] xgamma notify
On 3/5/2009, "Neale Pickett" wrote: > xbacklight =[some-value] > xvattr -a XV_BRIGHTNESS -v [some-value] While I'm thinking of it, I use xmessage to wake me up when my battery is about to die. It has the nice advantage that if I'm not looking at the screen that instant, it'll be around when I come back to it. And also the screen doesn't explode.
Re: [dwm] xgamma notify
xgamma just changes the gamma, which may not be noticeable on things that are predominantly black and white. Here are a few suggestions that will set actual brightness: xbacklight =[some-value] xvattr -a XV_BRIGHTNESS -v [some-value] These may not work on all systems, but will probably work on most laptops. See man pages for further information on these commands.
[dwm] [OT] xss bugfix
I've fixed a bug in xss that would cause the included "magic" hack to die after running for a few days straight. My 4-year-old daughter asked me to explain it to her, and it's such a good explanation that you're going to get it too. Every time I wanted to draw a new line, I would ask for a new color of crayon. Then there's this guy who you can tell "I'm done with this crayon" and will come pick it off of the floor. But I told the guy I was done with the crayon before I put it down on the floor, so when he came by to pick it up, he didn't see it and went away. Over time, I wound up taking every crayon in the box, and then the teacher noticed and gave me a timeout for not sharing crayons. Her first question: "how many crayons did you take, daddy?" My answer: "oh, probably a couple million." Download available at http://woozle.org/~neale/src/xss/ Neale
Re: [dwm] This question is probably beneath you all--but I will ask anyway
>I noticed with certain applications like Gimp, k3b, etc. it is very >difficult to maximize a work screen--I have yet to figure it out. As Anselm pointed out, you probably want to hold down your modifier key (default Alt) and use mouse buttons. A "maximize" could probably be written by raising whatever window's clicked on, and switching to monocle ([M]) layout. I actually used to run gimp under ion in its equivalent of tiled (=[]) mode. It's not so bad, really. I have a key bound to "toggle between monocle and tiled" that would make this pretty straightforward. But it seems like whenever I need to use Gimp, my wife is logged in and using Metacity, so I haven't had the opportunity to try.
Re: [dwm] Making it a million and one
On 2/17/2009, "I. Khider" wrote: >I will say this, I love DWM though I do not completely understand it >yet. It makes me feel like a man. Bwahahaha. Sometimes I wonder if that's the real reason any of us use it. Neale "Chest Beatin'" Pickett
Re: [dwm] stdin to statusbar output removed?
Evgeny Grablyk writes: > I just downloaded dwm-5.4.1 and noticed that stdin-to-statusbar output > mechanism was removed. Sadly, I don't seem to remember any discussion > about that. Was there any? Someone suggested the idea, I think in jest, and I was foolish enough to implement it. I've been running this way for quite ever since, and I've been pleased with how it works. Here's the thread about it: http://thread.gmane.org/gmane.comp.window-managers.dwm/6874 And here Anselm announces it's going in: http://thread.gmane.org/gmane.comp.window-managers.dwm/6924 Neale
[dwm] Bottom-posting and reply trimming (was: Bottom Stack Patch)
Folks, May I suggest that you get into the habit of trimming your replies? This is more important for bottom-posting, where your reply goes after the quoted text. Scrolling up and down to follow the conversation in the "Bottom Stack Patch" thread was mildly annoying :) That's all, thanks for your attention. Neale
Re: [dwm] Crash-only software
I'd be more inclined to consider this if dwm had ever had a problem in the year or so I've been using it. But if you're enamoured of the idea, here's something you can do from your .xinitrc to get this behavior. This will work better with dwm 5.4 than with a prior version. while ! dwm; do true; done Neale
Re: [dwm] dwm-5.4 restart without close clients
On 1/13/2009, "Frederic Chardon" wrote:
>void
>quit(const Arg *arg) {
>if (arg->i)
>execlp("dwm", "dwm", NULL);
>running = False;
>}
Here's the one I use, which can go into config.h instead, and can also
be used to launch other WMs (but why would you want to do that? ;)
void
restart(const Arg *arg)
{
if (arg->v) {
execvp(((char **)arg->v)[0], (char **)arg->v);
} else {
execlp("dwm", "dwm", NULL);
}
}
For instance:
{ MODKEY|ShiftMask, XK_r, restart, { 0 } },
{ MODKEY|ShiftMask, XK_b, restart, { .v = (const char *){"blackbox"}
} },
Re: [dwm] C-version of dwm status (no xsetroot needed)
Jeremy Jay writes: > Anyways, here's my "finished" dwm status code. Nice. I've written something very similar, but mine relies more on the shell and having to use lots of programs. I wanted to create an extensible tool that you could use as the foundation of a shell script that chains lots of other things together. I'm glad to see someone else on the list is using dbus, even if just a little. http://woozle.org/~neale/gitweb.cgi?p=status;a=tree Neale
Re: [dwm] [dmenu] help me test possibly faster dmenu_path
Anselm,
My apologies for bringing up something which has already been discussed,
I didn't think this specific issue would have come up before!
My primary machine (a shared machine on which I don't have root access)
triggers a cache miss nearly every time with dwm_path, due to
directories being constantly updated. This incurs a minimum 4 second
delay, since dmenu_path rebuilds the cache before displaying the cached
output. When I arrive at work in the morning, the delay can exceed 2
minutes.
I may be the only dmenu user with this problem of the cache missing more
often than hitting. But since the find version appears to be up to 20x
faster and simpler, and the only drawback is that symlinks to
non-binaries in $PATH showed up in the menu, I thought it was worth
bringing up here. I don't feel like my dmenu_run needs to be put into
the distribution unless there's overwhelming support for doing so.
My find version did use a GNU-ism, thank you. I've removed that; here's
one that works on GNU find and FreeBSD find (reports on other systems
would be welcome):
find $SPATH -maxdepth 1 \( -type f -o -type l \) -perm +111 | \
while read i; do echo ${i##*/}; done &> /dev/null
Additionally, as you point out, the find version has a problem with
symbolic links: if a symbolic link exists in the path, it isn't tested
to see what it links *to*. This is one of the things that provides a
significant speedup for me, since I have at least 10 NFS mounts at any
given time, and following all those symlinks triggers the automounter.
I think the 20-130 times speedup outweighs the rare possibility of a
symlink in $PATH not pointing to an executable.
Thanks,
Neale
[dwm] [dmenu] help me test possibly faster dmenu_path
I theorize that find outperforms for/test. Below are two shell scripts:
if you run the first one it will let you know the results of two runs.
The second one is a modified dmenu_run that uses find. I'd appreciate
it if people would run the first one and mail the results to me. I'll
let the list know what the results are.
Here are my results:
$ bin/fstest
=== find_binaries 1
real0m0.037s
user0m0.005s
sys 0m0.013s
=== find_binaries 2
real0m0.024s
user0m0.003s
sys 0m0.015s
=== shell_binaries 1
real0m5.099s
user0m0.469s
sys 0m0.185s
=== shell_binaries 2
real0m0.476s
user0m0.401s
sys 0m0.059s
On my system, the find version is 137 times faster before the OS has
cached the directories, and 19 times faster when directories are cached.
This is in part due to lots of symlinks pointing outside my path, but
mostly because find is more efficient.
-8<- findtest -8<-
#! /bin/sh
SPATH=$(IFS=:; for dir in $PATH; do echo "$dir"; done)
shell_binaries () {
for dir in $SPATH; do
for file in $dir/*; do
test -x "$file" && echo ${file##*/}
done
done > /dev/null
}
find_binaries () {
find $SPATH -maxdepth 1 \( -type f -o -type l \) -perm +111 -printf "%f\n"
&> /dev/null
}
echo "=== find_binaries 1"
time find_binaries
echo "=== find_binaries 2"
time find_binaries
echo "=== shell_binaries 1"
time shell_binaries
echo "=== shell_binaries 2"
time shell_binaries
-8<-
-8<- dmenu_run -8<-
#! /bin/sh
binaries() {
SPATH=$(IFS=:; for dir in $PATH; do echo "$dir"; done)
find $SPATH -maxdepth 1 \( -type f -o -type l \) -perm +111 -printf "%f\n"
2> /dev/null
}
exec $(binaries | sort | uniq | dmenu "$@")
-8<-
Re: [dwm] C-version of dwm status (no xsetroot needed)
Guillaume Quintin writes: > Neale Pickett, where are you in your investigations ? Could be X the > problem ? I stopped my investigation when Anselm accepted the xprop patch. Now status scripts will be just another background process with an X connection (like xterm), and there should be no need to worry about open FDs or whatever. Guillaume, I was under the impression that your specific problem had to do with something in your OS's X package. I think you're going to find the next dwm release makes the problem go away (after you convert your status script). > Anselm, if you don't like popen, then take Jeremy's runScript function. This little bourne shell script may give you the behavior you desire: #! /bin/sh while true; do sleep 2 xsetroot -name "$(myscript)" || exit 0 done Neale
Re: [dwm] xsetroot/status scripting using rc shell?
"Michael Brown" writes:
> Seems the problem has something to do with xsetroot's whitespace
> handling...
Then it's probably working like bourne shell. Observe:
$ argcount () { echo $#; }
$ argcount 1 2 3
3
$ argcount "1 2 3"
1
$ argcount $(echo 1 2 3)
3
$ argcount "$(echo 1 2 3)"
1
$
So,
xsetroot -name $(echo 1 2 3)
is different than
xsetroot -name "$(echo 1 2 3)"
You need to figure out how to get rc to take the output of your status
script and pass it in as a single argument to xsetroot. Anselm's
suggestion appears to do precisely this.
Passing around arguments which contain whitespace is one of the trickier
aspects of shell programming. "$@" is the bourne shell hacker's friend.
Neale
[dwm] screen locker
Since the list is talking about slock, now might be an appropriate time for me to mention again my xss project: http://woozle.org/~neale/src/xss/ This provides several single-purpose programs which allow you to build a screen locker (or just saver) with a shell script. I set mine up to check the entered password against an md5 hash of my password: this means there's no need for suid root. At work, it runs kinit and unlocks on success; this has the nice property of getting me a new kerberos ticket at the same time. When I mailed the list about this in April someone responded with a neat thing called "sinac", which is a little smaller than xss, but polls, and only replaces one of the 6 programs in my package. Some folks may prefer it, combined with slock or xlock: http://lists.suckless.org/dwm/0804/5534.html Neale
Re: [dwm] dwm-5.3
James Turner writes: > After taking some time and looking at the different signal headers on > OpenBSD only #include is required, no need to #include > which contains additional functions. My man page (Linux) says to #include . I don't have any of my books nearby, nor do I have access to any of my older boxen (SunOS, HP/UX, etc.) but I suspect signal.h is the portable way to do it. I'm not sure what the motivation is for changing this. If the concern is size of the compiled binary, consider that including prototypes for additional functions shouldn't change anything about the output binary; it still links against libc6, and since #define is just a C preprocessor directive, unused #defines won't affect the binary either. Neale
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
[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] dwm-5.3
"Anselm R Garbe" <[EMAIL PROTECTED]> writes: > I don't like the alternatives very much, I dislike popen() some status > feed process, or creating a fifo, or reading from some status text > file, or using X properties (like larsremote). I sort of like the idea of using X properties. You could use xprop to set some string on the root window: xprop -root -f DWM_STATUS 8s -set DWM_STATUS "whatever" It might even result in a significant SLOC reduction, since it'd just be another X event, and wouldn't have to parse text for newlines. I'll work on a patch to use X properties and we can see what everyone thinks. Neale
Re: [dwm] dwm-5.3
Guillaume Quintin <[EMAIL PROTECTED]> writes: > But now, when I reinstall dwm-5.2 I get the same problem than in > dwm-5.3 and dwm-5.3.1, "double-fork", "simple-fork" and > re-"double-fork". I don't understand why. This makes me happy, not only because my spawn function wasn't the problem, but also because I can feel again like I know how Unix works :) I now think it is the open file descriptor causing the problem. The SIGCHLD or double-fork would both cause this behavior; the problem is that the shell running .xinitrc is waiting for an EOF on the pipe it created for STD(IN|OUT|ERR), and is never getting it because you still have some X clients with it open. I advise against closing STDOUT or STDERR in the spawn function: that's how error messages make it in to .xsession-errors. I'll keep looking into ways to solve your particular problem. Guillaume. Neale
Re: [dwm] dwm-5.3
Jeremy Jay <[EMAIL PROTECTED]> writes: > This was my hunch too, glad someone got it before me though. This > patch fixes the problem with 5.3. Probably the same with the double- > fork version too. The open FD was my first guess too, but the double-fork version didn't close any fds either, so I assumed it must be something else. Guillaume, if you apply the "close(0)" patch, does the problem go away? I'm away from my dwm computer right now, or I'd try it myself. Neale
Re: [dwm] dwm-5.3
Neale Pickett <[EMAIL PROTECTED]> writes: > Would you mind sharing how you launch dwm? It might also be helpful to share your status script. If you launch your status script like this: status | dwm and status forks, the parent may not be exiting. If the status program never exits, X won't terminate when you kill dwm. To test if yours operates this way, try the following experiment: xterm1$ status | cat xterm2$ kill (pid of cat) My status program at least keeps on running even though it can no longer write to stdout. I think it's because the parent shell, the one outside the loop, never gets the SIGPIPE and keeps on running. I'll play with it and report back. This problem isn't related to the recent fork patch, tough; you can reproduce this behavior without ever calling spawn. The reason this doesn't stop X is because your .xsession (or .xinitrc) is waiting for all subprocesses to exit. As long as status keeps running, .xsession won't exit, and the X server startup script won't kill the X server. Here's something you can put in .xsession to run status as a background process and cause your .xsession to exit when dwm exits: XSTATUS=$HOME/.status.$(hostname).$DISPLAY mkfifo -m 600 $XSTATUS status > $XSTATUS & STATUS_PID=$! dwm < $XSTATUS kill $STATUS_PID rm $XSTATUS Neale
Re: [dwm] dwm-5.3
Guillaume Quintin <[EMAIL PROTECTED]> writes: > As usual this is the dwmii patch for dwm-5.3. > I think I have an issue when quitting dwm : If windows are openned > (xterm, claws-mail, firefox, pidgin for example) then X won't shut down > until I close (when possible) the windows. Does this have to do with > the new "simple-fork" ? I did not havs that issue with the previous > version of dwm. That certainly sounds like it's being caused by the new forking technique. Would you mind sharing how you launch dwm? (.xsession or whatever). I'd very much like to help you get X11 to exit when you quit dwm. Neale
Re: [dwm] patch for colored status text
Jeremy Jay <[EMAIL PROTECTED]> writes: > Hope someone else finds this handy, I let my battery die one too many > times because I never noticed how low it was... I had this problem too. My solution was this in my status script: battery_pct=$(get_charge) if [ $battery_pct -eq 10 ]; then xmessage "Better go find some juice, hoss." elif [ $battery_pct -lt 5 ]; then power Hibernate fi Haven't run the battery down since. Cool patch though. Neale
Re: [dwm] patch to not reparent children to init
"Anselm R Garbe" <[EMAIL PROTECTED]> writes: > I'm fine to add it in 5.3, since it seems to work quite well. Sweet! For the record, I've never had to work so hard to justify such a small patch to a FOSS project. It was a pleasant experience that makes me feel better about the larger codebase! Also for the record, I couldn't care less whether my toggleable setlayout patch goes in upstream. You can put the patch's author down in the "apathy" column. Neale
Re: [dwm] patch to not reparent children to init
Neale Pickett <[EMAIL PROTECTED]> writes: > "Anselm R Garbe" <[EMAIL PROTECTED]> writes: > >> Well, I remember there was a problem with the SIGCHLD signal handler, >> I need to recheck with Stevens tomorrow. It might be that this was on >> some ancient UNIX though. But the double-fork is definately the most >> portable solution. > > I assert that my SIGCHLD solution is just as portable as the > double-fork, and is more appropriate, since the double-fork is usually > only done in daemons. So what's the verdict on this? Neale
Re: [dwm] patch to not reparent children to init
"Anselm R Garbe" <[EMAIL PROTECTED]> writes: > Well, I remember there was a problem with the SIGCHLD signal handler, > I need to recheck with Stevens tomorrow. It might be that this was on > some ancient UNIX though. But the double-fork is definately the most > portable solution. Page 267 in Stevens. I can't recall ever working with a UNIX where SIGCHLD wasn't sent, process control in such an environment would be next to impossible. Maybe the older code was doing this: signal(SIGCHLD, SIG_IGN) which is a trick of POSIX.1-2001 to not create zombies. If you'd tried this (which would have worked on Linux, I think), it would have piled up zombies on anything not conformant to that standard. If you have a Linux box, this is in the NOTES section of the sigaction(2) man page. I assert that my SIGCHLD solution is just as portable as the double-fork, and is more appropriate, since the double-fork is usually only done in daemons. In fact, the only reason reparenting to init (with the double-fork) works is because init calls wait() in its SIGCHLD handler :) Neale
Re: [dwm] patch to not reparent children to init
"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
Re: [dwm] make setlayout toggle
"Donald Chai" <[EMAIL PROTECTED]> writes: > The proposed change would add inconsistency, unless if people want the > second MOD+1 to jump to the previously selected set of tags or do some > other weird thing. I think that would make more sense if all available layouts were shown at the top like the tags are. As it is they're two different beasts. Having said that, this is such a minor issue that I don't care at all what the default behavior is. It's just a 5 line addition to my config.h and I'm happy to put it on the wiki or whatever. I'm way more interested in not reparenting child processes to init, which is getting way less discussion ;) Neale
Re: [dwm] make setlayout toggle
"Thayer Williams" <[EMAIL PROTECTED]> writes: > By having a togglelayout() feature that worked for any mode, it would > allow folks to quickly go to a desired mode and jump back to the > previous when they're done. Yeah, that's my use case. I only ever go back and forth between tile and monocle. The setlayout I posted is overkill for me but obviously useful to a wider audience. Neale
Re: [dwm] make setlayout toggle
yy <[EMAIL PROTECTED]> writes:
> After a quick look, I think the last check in the first if should be
> arg->v != lt[sellt^1]
Yes, that's what it should have said. I wonder how it was working for
me before, when I sent the code to the list. [cue twilight zone music]
Here's what it should have said:
void
setlayout(const Arg *arg)
{
sellt ^= 1;
if(arg && arg->v && (arg->v != lt[sellt^1]))
lt[sellt] = (Layout *)arg->v;
if(sel)
arrange();
else
drawbar();
}
Neale
[dwm] make setlayout toggle
This simple modification to setlayout causes a binding to toggle if it's
already in the requested layout.
void
setlayout(const Arg *arg)
{
sellt ^= 1;
if(arg && arg->v && (arg->v != lt[sellt]))
lt[sellt] = (Layout *)arg->v;
if(sel)
arrange();
else
drawbar();
}
Now Alt-M toggles in and out of Monocle, etc. I far prefer this
behavior, YMMV.
Neale
[dwm] patch to not reparent children to init
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...
void
sigchld(int signal)
{
while (0 < waitpid(-1, NULL, WNOHANG));
}
void
spawn(const Arg *arg)
{
signal(SIGCHLD, sigchld);
if (fork() == 0) {
if (dpy) close(ConnectionNumber(dpy));
setsid();
execvp(((char **)arg->v)[0], (char **)arg->v);
fprintf(stderr, "dwm: execvp %s", ((char **)arg->v)[0]);
perror(" failed");
exit(0);
}
}
[dwm] I wrote a screen saver/locker and auto-launcher
I was inspired by dwm to write a screen saver / locker, and an auto-launcher (like xautolock, but mine blocks). I split it up into several little programs that each do one thing. You can use the programs to build a lot of different kinds of screen savers. http://woozle.org/~neale/src/xss I wrote it to run slock after a timeout, using the MIT-SCREEN-SAVER extension, because xautolock runs a little loop polling timestamps on the keyboard and mouse files and that bothers me. Replace xautolock like so: $ xss slock & Here's a shell script that does something similar to slock. You could modify it to use md5sum or some other "verify I typed in my password" program: #! /bin/sh xsswin xkeygrab | (while read l; do [ "$l" = "secret" ] && break xbell done) I provide a "magic" screensaver hack that you can use to draw pretty pictures without sucking CPU cycles. Or you can use any xscreensaver hack. You could also use "magic" with xscreensaver if you're happy with xscreensaver but unhappy with qix. I hope someone else thinks this is useful. Neale
