When the bar is getting input from a loop with a pause, there can be a noticable delay to visually updating the bar on click events. By letting bar call an input command it can now update instantly on a click event and still have a delay so it's not an idle hog.
Something like:
while true; do date; sleep 10; done | bar -d
Now becomes:
bar -d -c "date" -t 10
Either option may be ommited and the bar will still perform as before. If a command (-c) is given but not a timeout (-t) then the timeout defaults to 5 seconds.
I don't know how much of an issue this is, but i had to change the compiler standard from c99 to gnu99 to use popen()/pclose(). This still works with both clang and gcc.
I've discovered a serious issue with this. If bar daemonizes it spams the command in popen. I'm not sure why, it behaves as expected while running in the foreground.
When the bar is getting input from a loop with a pause, there can be a noticable delay to visually updating the bar on click events. By letting bar call an input command it can now update instantly on a click event and still have a delay so it's not an idle hog.
Something like:
while true; do date; sleep 10; done | bar -d
Now becomes:
bar -d -c "date" -t 10
Either option may be ommited and the bar will still perform as before. If a command (-c) is given but not a timeout (-t) then the timeout defaults to 5 seconds.
I don't know how much of an issue this is, but i had to change the compiler standard from c99 to gnu99 to use popen()/pclose(). This still works with both clang and gcc.