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
On Mon, Dec 8, 2008 at 10:40 PM, Neale Pickett [EMAIL PROTECTED] wrote: 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. I like the idea as well, go ahead it worth testing! -- Sidney Amani
Re: [dwm] dwm-5.3
On Sun, Dec 07, 2008 at 11:06:59AM +, Anselm R Garbe wrote: 2008/12/7 Neale Pickett [EMAIL PROTECTED]: 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. Afair running exec dwmstatus in .xinitrc should delegate this issue to dwmstatus, because the problem of running some loop | dwm in .xinitrc existed since the very first dwm version and there is no real solution to this problem unless the feed process is replaced by something more appropriate which uses a fifo redirection. I advise against closing STDOUT or STDERR in the spawn function: that's how error messages make it in to .xsession-errors. So far it was only about closing stdin. 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). Reading from stdin in dwm is the simpliest and most elegant solution imho. Amen to that, please keep it the way it currently is. Communication should be done over stdin/stdout. Cheers, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] [dvtm]: fix for status bar
On Sat, Nov 29, 2008 at 09:12:20PM +0100, Claudio M. Alessi wrote: I tested your patch a bit and it seems to work properly. Does it will going in upstream? I hope to push it sometime next weekend and then finally release dvtm-0.5. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] [dvtm] Cyrillic input
Hi, On Sat, Nov 29, 2008 at 05:40:13PM +0300, SIO wrote: If I start some applications inside dvtm, sometimes I've got troubles with cyrillic input. Sometimes letters enter, sometimes not. I have to press a key for a long time to get it entered. 1. mcabber reports following error: Unknown key=128 (keycode may vary) 2. aptitude crashes with a report: Uncaught exception: Unable to read from stdin: Success 3. htop just closes the search prompt when I try to enter some cyrillic symbols But some applications always work pretty good with cyrillic input, e.g. bash, ncmpc, vim I tested it on: - dvtm 0.4.1-1 from ubuntu repos, - dvtm 0.4.1 compiled from source (tarball from http://www.brain-dump.org/projects/dvtm/dvtm-0.4.1.tar.gz) - dvtm 0.4.1 from git repository (fetched on November, 29) The bug appears in all versions. Is there any way to fix it? Thanks for the report, I have added it to my TODO list but I am a bit busy right now so don't expect anything useful in the near future. The upcoming dvtm-0.5 release will most likely not contain a fix for it. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
[dwm] [slock] slock doesn't like to deactivate after password entry
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. If I wait 3-5 seconds and then press a key or bump the mouse, it finally comes back on, but I do have to wait 3-5 seconds with absolutely no input activity in order for this happen. I'm sure this can't be the expected behaviour. I'm running Arch Linux with xorg-server v1.5.3 on an ATI X1400 (catalyst driver) in case that has any bearing. I normally start slock via xautolock, however I can reproduce this when starting slock manually. Haven't seen anyone else posting about this, so I thought I'd toss it out there. Cheers
