Prevent bar being stopped by using signal other than SIGSTOP

[ammgws]

@GChicha Can you see if this makes any difference with regards to the bar being stopped while hidden?

[GChicha]

I just checked and it seems to work perfectly. The bar now runs even when hidden.

[ammgws]

Now to think of any pitfalls of doing this...

Perhaps we could make it opt-in via a command line argument?

[GChicha]

I was wondering about it too. Maybe it's only bad when someone was expecting that stopping behavior (like a great computational task when the bar is visible). In my use case, I just hide the status bar for appearance reasons

I was thinking about a flag in the config.toml, but a opt-in via command line seems more versatile.

[ammgws]

@GChicha Could you please try with the updated code?

[GChicha]

Didn't work for me. Maybe some differences between i3 and sway. I'm getting error reading from status command at the status bar but the i3status-rs is running.

If I run without your argument I'm getting only a raw json at status bar. I have no clue what's going on.

[ammgws]

@GChicha Should run now

[GChicha]

Oh sorry, I forgot to answer you. Unfortunately I only could run using SIGCHLD, other signals didn't work.

[GChicha]

I checked the ps auxf output and seems that even when the bar is visible i3status-rs does not leave the Stopped state (T)

guilher+   53710  0.0  0.0  18684  7476 tty1     S+   19:47   0:00 swaybar -b bar-0
guilher+   53776  0.0  0.0 151824  9356 tty1     Tl+  19:47   0:00  \_ /home/guilherme/.cargo/bin/i3status-rs --never-pause /home/guilherme/.config/i3status/co

[ammgws]

OK so TIL the default action for SIGUSR1/2 is to terminate the process...
I will need to either capture the signal or change it to something else that can be used.
Hoever there's also apparently this issue with assigning handlers to SIGUSR1/2...

The SIGUSR1 and SIGUSR2 signals are set aside for you to use any way you want.
They’re useful for simple interprocess communication, if you write a signal handler for them in the program that receives the signal.
The default action is to terminate the process.

[ammgws]

@GChicha I just changed it to use SIGCONT instead. When SIGCONT is sent to a running process it is ignored by default, which is what we want. Could you please try again?

In the meantime I may try talk to the i3 devs to at least let us turn this feature off so we don't need to come up with hacks like this.

[ammgws]

It appears to be working for me.

[GChicha]

It looks good now. Thank you for your help. And sorry for the late reply.

[ammgws]

I also mentioned this over at i3 and it looks like this PR will end up being the proper solution so I will merge this later on. (Just have to change the signal to '0')