search

greshake / i3status-rust

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

Add blinking indicator so we can tell if the bar froze #1470

Open noodlor opened 2 years ago

noodlor commented 2 years ago

This morning I was late to a meeting because my i3status-rust clock said 8:48 and I believed it, but actually the clock had stopped and the whole bar was frozen and it was 9:15 am.

Debugging the freezing issue is a question for another day; until then, I wonder if it would be possible to have the colon separator in the clock blink, so that it's easier to notice at a glance that the bar is frozen. Or some other simple animation would also work.

MaxVerevkin commented 2 years ago

I wonder if it would be possible to have the colon separator in the clock blink

A more generic solution would be to add optional config settings format_alt and alt_interval (or interval_alt, IDK), which, if set, will alternate the format every N seconds. WDYT?

noodlor commented 2 years ago

Good idea!

ammgws commented 2 years ago

add optional config settings format_alt and alt_interval

Sounds useful to me!

MaxVerevkin commented 2 years ago

Do you think it's better add alt_interval or using one interval for both updates and blinking indicator is good enough?

noodlor commented 2 years ago

Personally I keep the update interval to no less than 10s (heard that's a good idea to keep it from updating too frequently?) so an option to blink every 0.5s would be nice.

MaxVerevkin commented 2 years ago

heard that's a good idea to keep it from updating too frequently?

The call to update current time is cheap (~20 microseconds on my laptop - measured with Instant::elapsed(), so not sure how reliable this data is). It is a good idea to avoid too small (0.5s is ok) intervals, because i3bar protocol does not provide a way to re-render only one block, thus each update will cause the whole set of blocks to be serialized, printed to stdout, deserialized by the bar, and rendered.

ammgws commented 2 years ago

@noodlor Are you on sway or i3?

noodlor commented 2 years ago

i3

ammgws commented 2 years ago

Hmm OK. I've seen the bar freeze on sway before, but had always assumed it was due to a bug in swaybar.

Have you had a look at https://github.com/greshake/i3status-rust#signalling? Do you think it could be affecting your bar?

noodlor commented 2 years ago

I don't think it happens when I do something fullscreen, but I just built a fresh copy and I'll try running with --never-stop and see if that makes a difference. It's hard to reproduce the freeze reliably; it happens every few days with no apparent triggering event.

ammgws commented 2 years ago

I just had the bar freeze on me in sway again and ended up late for something.

I think it happened after issuing SIGUSR2 to reload the bar... managed to reproduce it only once so can't debug further.

Anyway I ended up adding seconds to my time block and just updating refresh interval to 1s to make it more obvious next time it happens.