Feature request: the script module should support poll-interval #67

Closed
opened 5 months ago by sagotsky · 1 comments

I'm not sure if this request is an unpopular opinion or just a spicy take.

I switched to yambar from polybar last week and am overall delighted with it. I don't have everything ported yet and have been slowly working through the accumulation of customizations I've made over the years.

One pattern that emerged when I was porting scripts is that my scripts are now responsible for staying alive and polling when appropriate. I'm doing this in my gmail script and my scripts for disk, cpu, and memory usage. I even tried setting up my module as watch with my script as an arg, but I couldn't make that work since watch was stripping the empty newlines at the end.

I realize that avoiding polling is one of the goals of yambar, but I think it's appropriate for each of these scripts, and a couple others still in my todo list. If the battery module can have poll-interval, why can't script?

I'd argue that putting the burden of polling on each script is a tad disingenuous on the part of yambar. My yambar + scripts system is still polling for data. Polling hasn't been avoided, it's just been moved out of the config and into a shell script. I'd like to have one long running process that occasionally spawns other short lived processes. Instead I'm left with a yambar process plus 5 script processes. What if one of my scripts dies? What if I restart my wm and end up running duplicate scripts? That was a major pain point prior to polybar, when I used xmobar.

Thanks!

I'm not sure if this request is an unpopular opinion or just a spicy take. I switched to yambar from polybar last week and am overall delighted with it. I don't have everything ported yet and have been slowly working through the accumulation of customizations I've made over the years. One pattern that emerged when I was porting scripts is that my scripts are now responsible for staying alive and polling when appropriate. I'm doing this in my gmail script and my scripts for disk, cpu, and memory usage. I even tried setting up my module as `watch` with my script as an arg, but I couldn't make that work since watch was stripping the empty newlines at the end. I realize that avoiding polling is one of the goals of yambar, but I think it's appropriate for each of these scripts, and a couple others still in my todo list. If the battery module can have poll-interval, why can't script? I'd argue that putting the burden of polling on each script is a tad disingenuous on the part of yambar. My yambar + scripts system is still polling for data. Polling hasn't been avoided, it's just been moved out of the config and into a shell script. I'd like to have one long running process that occasionally spawns other short lived processes. Instead I'm left with a yambar process plus 5 script processes. What if one of my scripts dies? What if I restart my wm and end up running duplicate scripts? That was a major pain point prior to polybar, when I used xmobar. Thanks!
Owner

I think this is a reasonable request. It is absolutely correct that if polling is necessary, then it's better to consolidate that into one place - yambar itself.

We can call the current implementation the first iteration, and I wanted a design that ensures script are in control of how and when things are updated. Now that we have that, adding support for "server" side polling makes sense.

I think this is a reasonable request. It is absolutely correct that if polling _is_ necessary, then it's better to consolidate that into one place - yambar itself. We can call the current implementation the first iteration, and I wanted a design that ensures script are in control of how and when things are updated. Now that we have that, adding support for "server" side polling makes sense.
dnkl added the
enhancement
label 5 months ago
dnkl referenced this issue from a commit 5 months ago
dnkl closed this issue 5 months ago
dnkl referenced this issue from a commit 5 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.