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 Wed Jul 30 2008 - 19:49:15 UTC
This archive was generated by hypermail 2.2.0 : Wed Jul 30 2008 - 20:00:04 UTC