Re: [dwm] Using dwm as a nested manager?
2008/12/6 Jorge Vargas [EMAIL PROTECTED]: Hi, I have been thinking about this for some time, and I like dwm a lot but I don't like it to manage all my windows, so I was wondering if it's possible to nest it inside another manager and tell it to handle only some windows? Please note I used this a long time ago in the 2.x releases so I'm not familiar with the codebase anymore. You could use Xnest(1) in order to run dwm in a nested sense. However what do you miss in dwm that you don't like to manage all windows? Kind regards, --Anselm
Re: [dwm] patch for colored status text
What about adding this patch to the wiki?
Kind regards,
Anselm
2008/12/4 Jeremy Jay [EMAIL PROTECTED]:
Another simple patch for anyone interested. Changes the way colors are
defined slighty, allowing you to create more color combinations. Then,
to color the status text from stdin you can simply use the color combo # as
follows:
echo -e \x03 warning low battery -- will be printed with the third color
combo
echo -e \x04 danger will robinson -- will be printed with the fourth color
combo
echo -e normal text \x03 warning \x04 error \x01 normal again
For example, my colors in config.h are:
#define NUMCOLORS 4
static const char colors[NUMCOLORS][ColLast][8] = {
// border foreground background
{ #33, #dd, #33 }, // normal
{ #88, #ff, #88 }, // selected
{ #ff, #00, #00 }, // urgent/warning (black on
yellow)
{ #ff, #ff, #ff }, // error (white on red)
// add more here
};
Which, coupled with my own status script results in things like the attached
image.
Hope someone else finds this handy, I let my battery die one too many
times because I never noticed how low it was...
Jeremy
Re: [dwm] Re: urgent windows border
2008/12/4 yy [EMAIL PROTECTED]: 2008/12/4 Anselm R Garbe [EMAIL PROTECTED]: I have mixed feelings about this patch. Does someone has strong arguments that this would be a good idea for upstream dwm? I also have mixed feelings... I wrote it because I didn't see urgent windows when they were visible (I know this sentence looks stupid, I know, but you get it), and since the implementation resulted simpler I decided to post it here. There is another middle-way solution which you could be interested in: move the clearurgent() call to focus(), like in my patch, but forget about the urgent border color (which is what makes the patch uglier). This way, you could save some loc while getting the functionality of notifying urgent clients in viewed tags. If you have no time or whatever I can modify my patch and send it to the list tomorrow. OTOH, I will probably maintain the patch for the border color, at least for the moment. But I won't post it here or anything if nobody else is interested. Yes, I did something similiar for the 5.3.1 bugfix release I'm currently uploading. Kind regards, --Anselm
Re: [dwm] dwm-5.3
I reverted the old spawn in the 5.3.1 release I'm currently uploading, until this issue gets sorted. But this proofs again never change a running system, especially I believe we experienced exactly the same 4 years ago when we switched back and forth to double-forks and signal handlers. Unix is a mess... ;) Kind regards, Anselm 2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 15:52:26 +0100 yy [EMAIL PROTECTED] wrote: 2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 08:33:44 + Here is my .xinitrc : while true do echo `date` sleep 1 done | dwm A bit off-topic, but, why the echo? A simple date should do it. Yes a simple date makes it. -- Kind regards, Guillaume Quintin.
[dwm] dwm-5.3.1
Hi, the bugfix release can be found at http://code.suckless.org/dl/dwm/dwm-5.3.1.tar.gz It includes a reverted spawn function. Sorry for any inconvenience. Kind regards, Anselm 2008/12/4 Anselm R Garbe [EMAIL PROTECTED]: Hi, there was some silence during the last weeks, simply because I am/was rather busy but also because I'm working on a secret surprise project (yes it's st related). But I won't tell anything about it yet -- I hope to disclose the details at 25C3 in Berlin in a couple of weeks ;) Anyway, it's time for a new dwm release, you can fetch it from http://code.suckless.org/dl/dwm/dwm-5.3.tar.gz This release contains the spawn() version of Neale and several bugfixes regarding the NOBORDER handling in 5.2, and a new config.h option which allows to set use server grabs during mouse based resizals/movements. Let me know any issues. Kind regards, --Anselm
Re: [dwm] Using dwm as a nested manager?
On 12/6/08, Anselm R Garbe [EMAIL PROTECTED] wrote: ... However what do you miss in dwm that you don't like to manage all windows? i can think of a few issues: - java awt bug - apps with many popup windows - apps which does not handle resizals correctly (eg matlab uses split areas in its main window, if you resize the main win the splits change so you dont want to accidentally resize the matlab main win which happens when you use tiling wm) - managing floating wins might be easier in other wms (drag, resize, close, minimize with only mouse, using gimp in dwm is a pain) - apps with fullscreen modes (eg if i togglefloating on xpdf,feh.. and then try to change them to fullscreen then they open a new win which will be tiled so no fullscreen which is annoying and also means information loss: the position of the original floating win) - floating wins are opened at the same position (eg some like their terminals to be 80x25 so tiling is not good but floating is not usable either) - i got a request to open every child of a win with the same tag, which turns out to be undoable in X
[dwm] applyrules()
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 .
applyrules.diff
Description: Binary data
Re: [dwm] dwm-5.3
I reprodeced this problem with dwm-4.7 and also dwm 5.3.1.
Neale's spawn() change is not guilty.
I think that fork() copy fd and pipe survive.
Please try this patch:
diff -r 94032e7d3943 dwm.c
--- a/dwm.c Sat Dec 06 11:22:30 2008 +
+++ b/dwm.c Sat Dec 06 22:57:46 2008 +0900
@@ -1396,6 +1396,7 @@
if(fork() == 0) {
if(dpy)
close(ConnectionNumber(dpy));
+ fclose (stdin);
setsid();
execvp(((char **)arg-v)[0], (char **)arg-v);
fprintf(stderr, dwm: execvp %s, ((char **)arg-v)[0]);
--
Yamada Yohei (山田洋平) [EMAIL PROTECTED]
Re: [dwm] Re: urgent windows border
There is little error here. It is not working as expected in 5.3.1. This patch fixes it. -- - yiyus || JGL . urgencyfix.diff Description: Binary data
Re: [dwm] Re: urgent windows border
2008/12/6 yy [EMAIL PROTECTED]: There is little error here. It is not working as expected in 5.3.1. This patch fixes it. Be care if you apply this, I forgot to remove my PREFIX (which is /usr) in config.mk -- - yiyus || JGL .
[dwm] [patch] Taskbar
Hi,
I've just updated my taskbar patch to the current hg tip and fixed
some bugs :)
Kind regards,
Nibblediff -r 00da7bf0bba7 dwm.c
--- a/dwm.c Sat Dec 06 09:33:58 2008 +
+++ b/dwm.c Sat Dec 06 16:40:41 2008 +0100
@@ -487,8 +487,8 @@ die(const char *errstr, ...) {
void
drawbar(void) {
- int x;
- unsigned int i, occ = 0, urg = 0;
+ int x, stx;
+ unsigned int i, occ = 0, urg = 0, vc = 0;
unsigned long *col;
Client *c;
@@ -496,6 +496,8 @@ drawbar(void) {
occ |= c-tags;
if(c-isurgent)
urg |= c-tags;
+ if(ISVISIBLE(c))
+ vc++;
}
dc.x = 0;
@@ -520,12 +522,18 @@ drawbar(void) {
dc.w = ww - x;
}
drawtext(stext, dc.norm, False);
- if((dc.w = dc.x - x) bh) {
+ if((dc.w = vc 0 ? (dc.x - x) / vc : dc.x - x) bh) {
+ stx = dc.x;
dc.x = x;
- if(sel) {
- drawtext(sel-name, dc.sel, False);
- drawsquare(sel-isfixed, sel-isfloating, False, dc.sel);
- }
+ if(sel)
+ for(c = clients, i = 1; c; c = c-next) {
+if(ISVISIBLE(c)) {
+ drawtext(c-name, (c == sel ? dc.sel : dc.norm), False);
+ drawsquare(c-isfixed, c-isfloating, False, (c == sel ? dc.sel : dc.norm));
+ dc.x += dc.w;
+ dc.w = ++i vc ? dc.w : stx - dc.x;
+}
+ }
else
drawtext(NULL, dc.norm, False);
}
Re: [dwm] dwm-5.3
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.
Jeremy
On Sat 06 Dec 2008 - 11:14PM, yamada yohei wrote:
I reprodeced this problem with dwm-4.7 and also dwm 5.3.1.
Neale's spawn() change is not guilty.
I think that fork() copy fd and pipe survive.
Please try this patch:
diff -r 94032e7d3943 dwm.c
--- a/dwm.c Sat Dec 06 11:22:30 2008 +
+++ b/dwm.c Sat Dec 06 22:57:46 2008 +0900
@@ -1396,6 +1396,7 @@
if(fork() == 0) {
if(dpy)
close(ConnectionNumber(dpy));
+ fclose (stdin);
setsid();
execvp(((char **)arg-v)[0], (char **)arg-v);
fprintf(stderr, dwm: execvp %s, ((char
**)arg-v)[0]);
--
Yamada Yohei (?$B;3EDMNJ?) [EMAIL PROTECTED]
Re: [dwm] Re: urgent windows border
2008/12/6 yy [EMAIL PROTECTED]: 2008/12/6 yy [EMAIL PROTECTED]: There is little error here. It is not working as expected in 5.3.1. This patch fixes it. Be care if you apply this, I forgot to remove my PREFIX (which is /usr) in config.mk Thanks, applied. I'll wait for other issues first before making a new micro release. Kind regards, --Anselm
Re: [dwm] dwm-5.3
2008/12/6 Jeremy Jay [EMAIL PROTECTED]: 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. Glad you investigated further ;) I will test this and wait some days, looks like there will be some 5.3.2 soon ;) Kind regards, --Anselm
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
On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett [EMAIL PROTECTED] wrote:
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
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. 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.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can change
the status when dwm is running and there are no more quitting
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] patch for colored status text
OK I think it's added now, but the preview page isn't working.
Jeremy
On Sat 06 Dec 2008 - 08:50AM, Anselm R Garbe wrote:
What about adding this patch to the wiki?
Kind regards,
Anselm
2008/12/4 Jeremy Jay [EMAIL PROTECTED]:
Another simple patch for anyone interested. Changes the way colors are
defined slighty, allowing you to create more color combinations. Then,
to color the status text from stdin you can simply use the color combo # as
follows:
echo -e \x03 warning low battery -- will be printed with the third color
combo
echo -e \x04 danger will robinson -- will be printed with the fourth
color combo
echo -e normal text \x03 warning \x04 error \x01 normal again
For example, my colors in config.h are:
#define NUMCOLORS 4
static const char colors[NUMCOLORS][ColLast][8] = {
// border foreground background
{ #33, #dd, #33 }, // normal
{ #88, #ff, #88 }, // selected
{ #ff, #00, #00 }, // urgent/warning (black on
yellow)
{ #ff, #ff, #ff }, // error (white on red)
// add more here
};
Which, coupled with my own status script results in things like the
attached image.
Hope someone else finds this handy, I let my battery die one too many
times because I never noticed how low it was...
Jeremy
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 19:20:58 +0100
Guillaume Quintin [EMAIL PROTECTED] wrote:
On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett [EMAIL PROTECTED] wrote:
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
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. 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.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can
change the status when dwm is running and there are no more quitting
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
This is more simple with the popen() function. We could simply get the
shell commands to execute from the arguments passed to dwm or read them
from any file or from stdin only once.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. 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.
Is there any chance you may have recently updated your version of
xorg-server? I know the change just got pushed out recently on
Archlinux, and it seems to have changed some corner cases that people
previously took for granted.
In response to your idea for executing status scripts, that's roughly
how my patched version of dwm does it, though mine takes the status
script name (or possibly even the content) as an argument, and stores
the entirety of argv so that dwm can re-exec itself to restart/change
the script. In any case, the function you're looking for to replace a
fid with another is 'dup2(replacement, to_replace)'.
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything. And I
found something very weird. I told you that in the previous version of
dwm (5.2) with the .xinitrc containing the while | dwm all worked
fine and I am sure of that. I quitted dwm-5.2 many times with a lot of
openned windows and all worked fine. 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.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can change
the status when dwm is running and there are no more quitting
problem. This is just an idea, forgive me not to propose some real
code. Well tell me what you think of this idea.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 14:40:47 -0400
Brendan MacDonell [EMAIL PROTECTED] wrote:
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything.
And I found something very weird. I told you that in the previous
version of dwm (5.2) with the .xinitrc containing the while | dwm
all worked fine and I am sure of that. I quitted dwm-5.2 many times
with a lot of openned windows and all worked fine. 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.
Is there any chance you may have recently updated your version of
xorg-server? I know the change just got pushed out recently on
Archlinux, and it seems to have changed some corner cases that people
previously took for granted.
In response to your idea for executing status scripts, that's roughly
how my patched version of dwm does it, though mine takes the status
script name (or possibly even the content) as an argument, and stores
the entirety of argv so that dwm can re-exec itself to restart/change
the script. In any case, the function you're looking for to replace a
fid with another is 'dup2(replacement, to_replace)'.
On Sat, Dec 6, 2008 at 2:20 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
I just tried the close(0) patch but it does not change anything.
And I found something very weird. I told you that in the previous
version of dwm (5.2) with the .xinitrc containing the while | dwm
all worked fine and I am sure of that. I quitted dwm-5.2 many times
with a lot of openned windows and all worked fine. 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.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can
change the status when dwm is running and there are no more
quitting problem. This is just an idea, forgive me not to propose
some real code. Well tell me what you think of this idea.
--
Kind regards,
Guillaume Quintin.
Yes I pacmaned a new xorg-server and I move from 32 bits to 64 bits
recently.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] [patch] Taskbar
Hi,
Hi,
How about changing the invert parameter in drawtext and
drawsquare to c-isurgent ?
Now that the urgent hint flag is removed when the client is focused
it makes sense. I like it, thanks :) I attach the new patch.
Regards,
Regards,
Nibblediff -r 79bf47074a49 dwm.c
--- a/dwm.c Sat Dec 06 16:20:14 2008 +
+++ b/dwm.c Sat Dec 06 20:58:44 2008 +0100
@@ -487,8 +487,8 @@ die(const char *errstr, ...) {
void
drawbar(void) {
- int x;
- unsigned int i, occ = 0, urg = 0;
+ int x, stx;
+ unsigned int i, occ = 0, urg = 0, vc = 0;
unsigned long *col;
Client *c;
@@ -496,6 +496,8 @@ drawbar(void) {
occ |= c-tags;
if(c-isurgent)
urg |= c-tags;
+ if(ISVISIBLE(c))
+ vc++;
}
dc.x = 0;
@@ -520,12 +522,18 @@ drawbar(void) {
dc.w = ww - x;
}
drawtext(stext, dc.norm, False);
- if((dc.w = dc.x - x) bh) {
+ if((dc.w = vc 0 ? (dc.x - x) / vc : dc.x - x) bh) {
+ stx = dc.x;
dc.x = x;
- if(sel) {
- drawtext(sel-name, dc.sel, False);
- drawsquare(sel-isfixed, sel-isfloating, False, dc.sel);
- }
+ if(sel)
+ for(c = clients, i = 1; c; c = c-next) {
+if(ISVISIBLE(c)) {
+ drawtext(c-name, (c == sel ? dc.sel : dc.norm), c-isurgent);
+ drawsquare(c-isfixed, c-isfloating, c-isurgent, (c == sel ? dc.sel : dc.norm));
+ dc.x += dc.w;
+ dc.w = ++i vc ? dc.w : stx - dc.x;
+}
+ }
else
drawtext(NULL, dc.norm, False);
}
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 19:38:16 +0100
Guillaume Quintin [EMAIL PROTECTED] wrote:
On Sat, 6 Dec 2008 19:20:58 +0100
Guillaume Quintin [EMAIL PROTECTED] wrote:
On Sat, 06 Dec 2008 09:26:25 -0700
Neale Pickett [EMAIL PROTECTED] wrote:
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
I just tried the close(0) patch but it does not change anything.
And I found something very weird. I told you that in the previous
version of dwm (5.2) with the .xinitrc containing the while | dwm
all worked fine and I am sure of that. I quitted dwm-5.2 many times
with a lot of openned windows and all worked fine. 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.
Why don't we change the way dwm gets its status text ? For example
we could use the SIGALRM signal to call a spawn2 :
spawn2()
{
check for a certain shell script .dwmstatus;
if it is not present then return;
create some pipe p[];
(double or simple)-fork;
in the child process
{
close(0);
close(1);
close(2);
set stdout to p[1]; /* I don't know how exactly */
execv(.dwmstatus);
}
/* Here is dwm */
read status from p[0];
display status;
}
This will take only a few LOC, because all the reading p[0] part
will be in fact the reading-stdin code from the run() function which
will not be needed anymore. This has the advantages that one can
change the status when dwm is running and there are no more
quitting problem. This is just an idea, forgive me not to propose
some real code. Well tell me what you think of this idea.
This is more simple with the popen() function. We could simply get the
shell commands to execute from the arguments passed to dwm or read
them from any file or from stdin only once.
This is a little very basic patch that does what I asked above. I tried
this using the SIGALRM signal but I randomly got fatal errors about
memory (un)locks.
I have a dwmstatus script :
~/.dwmstatus
#!/bin/sh
date
and my .xinitrc is :
~/.xinitrc
exec dwm -s ./dwmstatus
And every second I get the status bar text updated. Tell me what you
think about it.
--
Kind regards,
Guillaume Quintin.
--- org/dwm.c 2008-12-06 19:53:57.0 +0100
+++ dwm-5.3/dwm.c 2008-12-06 21:50:55.0 +0100
@@ -23,6 +23,7 @@
*
* To understand everything else, start reading main().
*/
+#define _POSIX_C_SOURCE 2
#include errno.h
#include locale.h
#include stdarg.h
@@ -30,6 +31,7 @@
#include stdlib.h
#include string.h
#include unistd.h
+#include time.h
#include sys/select.h
#include sys/types.h
#include sys/wait.h
@@ -204,8 +206,10 @@
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
static void zoom(const Arg *arg);
+static void getstatustext(void);
/* variables */
+static char sscript[256];
static char stext[256];
static int screen;
static int sx, sy, sw, sh; /* X display screen geometry x, y, width, height */
@@ -1184,55 +1188,16 @@
void
run(void) {
- char *p;
- char sbuf[sizeof stext];
- fd_set rd;
- int r, xfd;
- unsigned int len, offset;
+ int t,xfd;
XEvent ev;
/* main event loop, also reads status text from stdin */
XSync(dpy, False);
xfd = ConnectionNumber(dpy);
- offset = 0;
- len = sizeof stext - 1;
- sbuf[len] = stext[len] = '\0'; /* 0-terminator is never touched */
+ getstatustext();
+ t = time(0) + 1;
while(running) {
- FD_ZERO(rd);
- if(readin)
- FD_SET(STDIN_FILENO, rd);
- FD_SET(xfd, rd);
- if(select(xfd + 1, rd, NULL, NULL, NULL) == -1) {
- if(errno == EINTR)
-continue;
- die(select failed\n);
- }
- if(FD_ISSET(STDIN_FILENO, rd)) {
- switch((r = read(STDIN_FILENO, sbuf + offset, len - offset))) {
- case -1:
-strncpy(stext, strerror(errno), len);
-readin = False;
-break;
- case 0:
-strncpy(stext, EOF, 4);
-readin = False;
-break;
- default:
-for(p = sbuf + offset; r 0; p++, r--, offset++)
- if(*p == '\n' || *p == '\0') {
- *p = '\0';
- strncpy(stext, sbuf, len);
- p += r - 1; /* p is sbuf + offset + r - 1 */
- for(r = 0; *(p - r) *(p - r) != '\n'; r++);
- offset = r;
- if(r)
- memmove(sbuf, p - r + 1, r);
- break;
- }
-break;
- }
- drawbar();
- }
+ if ( time(0) = t ) { t = time(0) + 1; getstatustext(); }
Re: [dwm] dwm-5.3
On Dec 6, 2008, at 10:20 AM, Guillaume Quintin wrote: Why don't we change the way dwm gets its status text ? For example we could use the SIGALRM signal to call a spawn2 : --snip-- This will take only a few LOC, because all the reading p[0] part will be in fact the reading-stdin code from the run() function which will not be needed anymore. This has the advantages that one can change the status when dwm is running and there are no more quitting problem. This is just an idea, forgive me not to propose some real code. Well tell me what you think of this idea. I'm not sure that changing the status script when dwm is running is a big advantage. I'm already used to recompiling if I want to change any setting. :) The disadvantage of this approach is that the status script would have to do a lot of work to maintain any state. Most people run date, acpi and other commands once a second, this would be fine for them. My status text includes the weather (updated only every 15min to avoid hammering their servers), and the time (updated once a minute, on the minute, to reduce my wakeups-per-second in PowerTOP). For me, this SIGALRM and spawn2 would require that I store some temporary data somewhere between invocations. Here's my status script in case anyone would be interested. It basically merges different status areas with arbitrary update intervals for each. status.lua Description: Binary data
Re: [dwm] dwm-5.3
On Sat, 6 Dec 2008 14:52:55 -0800 Donald Chai [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 10:20 AM, Guillaume Quintin wrote: Why don't we change the way dwm gets its status text ? For example we could use the SIGALRM signal to call a spawn2 : --snip-- This will take only a few LOC, because all the reading p[0] part will be in fact the reading-stdin code from the run() function which will not be needed anymore. This has the advantages that one can change the status when dwm is running and there are no more quitting problem. This is just an idea, forgive me not to propose some real code. Well tell me what you think of this idea. I'm not sure that changing the status script when dwm is running is a big advantage. I'm already used to recompiling if I want to change any setting. :) The disadvantage of this approach is that the status script would have to do a lot of work to maintain any state. Most people run date, acpi and other commands once a second, this would be fine for them. My status text includes the weather (updated only every 15min to avoid hammering their servers), and the time (updated once a minute, on the minute, to reduce my wakeups-per-second in PowerTOP). For me, this SIGALRM and spawn2 would require that I store some temporary data somewhere between invocations. Here's my status script in case anyone would be interested. It basically merges different status areas with arbitrary update intervals for each. Then use another solution. I posted a patch some hours ago, which requires the time.h and execute a script every second but you choose to execute it every hour if you like you just have to modify : int what_you_want; t = time(0) + what_you_want; Moreover I thought of another solution more simple for which you won't to modify any status script or store any data between calls. It is late, I am tired so I won't write a patch but I think we proceed as follow : You don't need any time.h functions. Before the main loop in the run() function you call popen(yourscript,r); and within the main loop, you keep select(); and fgets(); when necessary and display it. On breaking the main loop you pclose(); Tomorrow I will try this unless someone write it during the night. -- Kind regards, Guillaume Quintin.
[dwm] DWM 5.3.1 and Xinerama
Sorry to bother with this question I have been using DWM for a year or so now but never needed to connect my laptop to a projector till today. I realized I had no idea how to do this with DWM. After some research I found that DWM uses Xinerama and not xrandr. I got as far as compiling DWM with Xinerema support and then getting lost. What's the next step? I plan to put a how to in the DWM page once I get this up an running. THanks, AMit
Re: [dwm] dwm-5.3
That's how my version currently works. Unfortunately, mine likely
wouldn't be much good to you because there is a massive amount of
overhead that I added to fine-tune process controls - and I can't
merge into my github repository to demonstrate until the daily
mercurial mirror updates. Of course, your idea is actually as simple
as using popen, the non-standard function fileno, and dup2 to replace
stdin if you wanted to minimize the amount of code you touch, ie.
(somewhere in main()):
FILE *dwmhelper;
...
if(argc == 2) {
dwmhelper = popen(argv[1], r);
if(f) dup2(fileno(dwmhelper), STDIN_FILENO);
}
run();
pclose(dwmhelper);
Actually, I'm unsure that dwm didn't actually work this way by default
at one point. I seem to recall finding it somewhere in the source in
some long-lost revision once when I went repository-diving.
On Sat, Dec 6, 2008 at 10:44 PM, Guillaume Quintin
[EMAIL PROTECTED] wrote:
Then use another solution. I posted a patch some hours ago, which
requires the time.h and execute a script every second but you choose to
execute it every hour if you like you just have to modify :
int what_you_want;
t = time(0) + what_you_want;
Moreover I thought of another solution more simple for which you won't
to modify any status script or store any data between calls. It is
late, I am tired so I won't write a patch but I think we proceed as
follow :
You don't need any time.h functions. Before the main loop in the run()
function you call popen(yourscript,r);
and within the main loop, you keep select(); and fgets(); when
necessary and display it. On breaking the main loop you pclose();
Tomorrow I will try this unless someone write it during the night.
--
Kind regards,
Guillaume Quintin.
Re: [dwm] dwm-5.3
On Dec 6, 2008, at 1:02 PM, Guillaume Quintin wrote: This is a little very basic patch that does what I asked above. I tried this using the SIGALRM signal but I randomly got fatal errors about memory (un)locks. Your code looks like an idle loop; I recommend you read the man page for select(). The last argument is a timeout, which is what you want to use instead of alarm(1), and will avert the random errors.
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.1 and Xinerama
If you are using a recent version of xorg, and don't have your screen resolution hardcoded in xorg.conf, it should be autodetected. For example, the last time I had to do a presentation, I plugged in the projector, restarted X, and it auto-detected the right resolution to use. Jeremy On Sat 06 Dec 2008 - 07:21PM, Amit Uttamchandani wrote: Sorry to bother with this question I have been using DWM for a year or so now but never needed to connect my laptop to a projector till today. I realized I had no idea how to do this with DWM. After some research I found that DWM uses Xinerama and not xrandr. I got as far as compiling DWM with Xinerema support and then getting lost. What's the next step? I plan to put a how to in the DWM page once I get this up an running. THanks, AMit
Re: [dwm] DWM 5.3.1 and Xinerama
On Sun, 7 Dec 2008 01:14:45 -0500 Jeremy Jay [EMAIL PROTECTED] wrote: If you are using a recent version of xorg, and don't have your screen resolution hardcoded in xorg.conf, it should be autodetected. For example, the last time I had to do a presentation, I plugged in the projector, restarted X, and it auto-detected the right resolution to use. Jeremy Yeah I think its quite recent. I'm using debian lenny and xorg 7.3 and xserver-xorg-core 1.4.2. I will try what you said and restart xserver...And how does dwm behave in this case? does it just mirror the screen?
Re: [dwm] DWM 5.3.1 and Xinerama
On Dec 6, 2008, at 10:32 PM, Amit Uttamchandani wrote: On Sun, 7 Dec 2008 01:14:45 -0500 Jeremy Jay [EMAIL PROTECTED] wrote: If you are using a recent version of xorg, and don't have your screen resolution hardcoded in xorg.conf, it should be autodetected. For example, the last time I had to do a presentation, I plugged in the projector, restarted X, and it auto-detected the right resolution to use. Jeremy Yeah I think its quite recent. I'm using debian lenny and xorg 7.3 and xserver-xorg-core 1.4.2. I will try what you said and restart xserver...And how does dwm behave in this case? does it just mirror the screen? BTW, restarting X is not necessary: the *whole purpose* of Xrandr is to avoid doing this. Just plug in your external display and run xrandr --output VGA --auto or whatever your external display is called. dwm is already set up to receive configure events, and will do The Right Thing.
