search

greshake / i3status-rust

Very resourcefriendly and feature-rich replacement for i3status, written in pure Rust
GNU General Public License v3.0
2.88k stars 475 forks source link

Add signal support for all blocks #1036

Closed ammgws closed 3 years ago

ammgws commented 3 years ago

Right now only the Custom block supports setting an update signal, however other blocks should be able to use it too as mentioned in https://github.com/greshake/i3status-rust/pull/822 (and there are requests for that e.g. https://github.com/greshake/i3status-rust/issues/1015).

GladOSkar commented 3 years ago

IIUC #1015 is click related and not about signals?

ammgws commented 3 years ago

Related in this way: adding both on_click_right support and signal support would achieve their use case

MaxVerevkin commented 3 years ago

But what are the use cases for sending signals to blocks (except for custom)?

ammgws commented 3 years ago

To force updates early. For example the pacman block could have an interval of 1 hour but if you send a signal you could trigger an update without waiting.

MaxVerevkin commented 3 years ago

Well, I still don't get it. Is writing pkill -SIGRTMIN+x i3status-rs simpler that just checkupdates? I know, I can set a keybinding to send a signal, but still.

It is already possible to update every block with USR1 signal, right?

ammgws commented 3 years ago

I originally thought of it as a way to solve https://github.com/greshake/i3status-rust/issues/1015 without introducing any block-specific stuff. In that case, the on_click for the diskspace block could be set to run pkill -SIGRTMIN+x i3status-rs and the signal set appropriately to catch it. Another way without using signal might be to overhaul on_click and give it some special syntax so you can choose to force update the block instead of running a custom command, but the signal way seemed the easier way to go (yet could be seen as a bit hackish)

So if it can be generically implemented for every block like on_click then I don't see the harm in signal also having the same treatment. Depending on the config, reloading every block in the bar can take some time so I can see the point of being able to pinpoint force update a block. So basically the argument is, if it can be implemented fairly trivially then it seems like a good way to allow power users finer control over their i3status-rs bar.

MaxVerevkin commented 3 years ago

and give it some special syntax so you can choose to force update the block instead of running a custom command

IMO, every block should always update when clicked, even if on_click is set.

ammgws commented 3 years ago

Interesting idea, though I could imagine misclicking on a long blocking block might be annoying (though not so bad if it was async?)

Also, would that just be for left clicks, or any button click? Ignore scrolling?

MaxVerevkin commented 3 years ago

Also, would that just be for left clicks, or any button click? Ignore scrolling?

I'm not sure.

Maybe it worth adding additional on_click_sync or something like that to run the command, wait for it to finish and then update the block.

Use case: keyboard_layout: on click command may toggle layout, and it would be nice if the block updated.

By the way, that's how https://github.com/MaxVerevkin/swaystatus works (almost, I didn't implement the "wait" part yet, but it'll be super easy since it's async).

MaxVerevkin commented 3 years ago

though not so bad if it was async?

Yep.

ammgws commented 3 years ago

OK so I will remove this from the 0.2 milestone because:

1) As mentioned, signal functionality isn't really useful for blocks other than Custom. 2) The whole bar can be signalled to update, which is probably good enough to cover any expected use-cases. 3) Forcing updates per-block can be better achieved through the on_click feature