Re: [dwm] save cpu cycles - bar status and wrapper scripts

Works like a champ! Here is my script setup (please let me know if I
can improve anything):

.xinitrc:
----------
...
rmdir /tmp/dwm-bar-script-lock
dwm-statusbar &
dwm-launch

dwm-statusbar:
----------------------
#!/bin/bash
#Incrementing numbers are just for testing.

LOCK=/tmp/dwm-bar-script-lock

if mkdir $LOCK; then
        i=0
        while [ -e $SHOWBAR ]; do
                ((i++))
                echo "$i [`date '+%a %b %d %I:%M%P'`]"
                sleep 1
        done > /tmp/dwmpipe
else
        rmdir $LOCK
        killall dwm-statusbar
fi

dwm-launch:
-----------------
#!/bin/bash

DWM_PIPE="/tmp/dwmpipe"

if [ ! -e $DWM_PIPE ]; then
        mkfifo $DWM_PIPE
fi

while true; do
        cat $DWM_PIPE
done | dwm

config.h:
------------
...
static const char *barcmd[] = { "dwm-statusbar", NULL };
...
static Key keys[] = {
        { MODKEY, XK_b, spawn,
{.v = barcmd } },
        { MODKEY, XK_b, togglebar, {0} },
...

Now I don't have to patch DWM at all... well... at least not for this
feature, haha :)

Cheers,
Alex

On Wed, Jul 30, 2008 at 12:49 PM, Kurt H Maier <karmaflux_AT_gmail.com> wrote:
> Maybe you could not run the script in the loop, and instead trigger it
> when you activate the bar. Something like this:
>
> static const char *barcmd[] = { "/path/to/script > /path/to/pipe", NULL };
> ...
> static Key keys[] = {
> ....
> { MODKEY, XK_b, spawn, {.v = barcmd } },
> { MODKEY, XK_b, togglebar, {0} },
>
> The problem is that it will trigger the script again when you _close_
> the bar, but that's got to be better than just burning cycles the
> whole time.
>
> # Kurt H Maier
>
>
>
> On Wed, Jul 30, 2008 at 2:34 PM, Alex Matviychuk <alexmat_AT_gmail.com> wrote:
>> Thanks for the suggestion. I tried it out by wrapping the FD readin
>> block with if(showbar) and it suppressed the output of the while loop
>> to the dwm bar.
>>
>> However, to test it out I put an incrementing value in the while block
>> of my dwm wrapper script and when I re-enable the bar, the value seems
>> to have kept incrementing since I last disabled the bar. When I first
>> re-enable, the value is set to the value it was when I disabled the
>> bar, but on the next iteration jumps to a value that has been
>> incremented many times since I disabled the bar. So it seems the
>> output of the while loop is blocked, but the execution continues.
>>
>> I dug around on google and couldn't find much more info about blocking
>> the while loop by not reading in from the pipe. The docs just say the
>> output is "blocked", but I think it means the output is suppressed
>> while the command continues to run.
>>
>> So this is definitely less code and more elegant, but doesn't quite work.
>>
>> Cheers,
>> Alex
>>
>> On Wed, Jul 23, 2008 at 9:54 PM, Monsieur Pinocchio <cchinopio_AT_gmail.com> wrote:
>>> On Sat, Jul 19, 2008 at 7:02 PM, Alex Matviychuk <alexmat_AT_gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I have a wrapper script for dwm that checks a bunch of devices running
>>>> on my laptop. I was thinking that a lot of times I don't even have the
>>>> dwm bar up (i tend to hide it often for full screen work) and so why
>>>> should the wrapper script constantly poll for status bar info if I
>>>> can't see it. Long story short, I made a small change to write out a
>>>> file to /tmp whenever the status bar is visible. Any thought if this
>>>> is the right approach? Is there a less barbaric way to alert my dwm
>>>> wrapper script that the bar is hidden?
>>>>
>>>> Diff is attached. I also added a config param to specify the filepath
>>>> for the file that gets written.
>>>>
>>>> Cheers,
>>>> Alex
>>>
>>> How about just not polling the input fd when bar is disabled? This will
>>> basically just block the write of the external command which is sending data
>>> into dwm and cause the external command to go to sleep thus automatically
>>> stopping it (and resuming it once the bar is shown again).
>>>
>>> --
>>> Pinocchio
>>
>>
>
>
Received on Thu Jul 31 2008 - 01:43:33 UTC