Add flag to suppress errors on startup about i3status-rust

[svmnotn]

@keeslinp I like the idea that

If we can contain failure to an individual component it could add buttons to a dead component to either restart or hide it. That also helps with one-off errors so people don't have to restart all of i3 to get it back up.

Now that we have most things return a Result<_> it should be possible to do, but that should probably be its own issue.

(One off errors should mostly happen due to a lack of extra software, which can be installed without restarting i3. I think)

[jlesquembre]

I'm also sharing the configuration between multiple computers and was bitten by this issue.

I have another suggestion, what do you think about adding a tag for all blocks for a test command? E.g.:

[[block]]
block = "battery"
if_command = "upower -e"

If the command upower -e exits with an error code, the block will not be rendered.

[greshake]

I don't really like the proposed solution, seems hacky and might lead to confusion down the road (issues being openend because error messages are hidden because someone only copy-pasted the config/cmd line args). Also it would just make sense to have separate configs in your use case. But I'll await further judgement from others, maybe there is more demand for this feature than I estimate.

[greshake]

@jheyens @pitkley @keeslinp @svmnotn Any comment?

[michelboaventura]

I understand your point, and maybe I'm the only one sharing the same i3status-rs/i3/entire world of configs between my pcs :)

[svmnotn]

Maybe have all blocks have an optional = false tag that can be changed to true.
That way if the block is optional, any errors will simply cause the block to not be displayed?
That seems like a more complete solution, specially if all blocks default to false so that users would have to opt-in to the feature.

It does seem like this would be sorta useful in some use cases, but I don't think that many users do this?

Also, optional does make some sense for blocks like battery, but something like time may not really need it. So maybe only add that to blocks that could feasibly be ok to fail since they might not exist, like battery and disk_space.

[keeslinp]

I agree that silently failing is probably a bad idea. I haven't updated in a while so I'm not sure about how it's all handled at the moment. I'll try to test some things out this weekend if I get the time (It's been pretty crazy lately) and I'll try to have a more informed opinion.

Two very early thoughts are this:

1. I like the idea of an optional flag that defaults to fail explicitly because it allows people to have more seamless usage across devices without messing with the average user.
2. If we can contain failure to an individual component it could add buttons to a dead component to either restart or hide it. That also helps with one-off errors so people don't have to restart all of i3 to get it back up.

[jheyens]

I definitely would not like to have a global mute switch for all blocks simultaneously.
I am not even sure if I would like an optional switch for all blocks, because there are some, where it doesn't make a lot of sense.
The time block for example (or memory, CPU, LOAD) has zero external dependencies and if that one stops working for some reason, the user shall have to manually interact with the configuration and file an issue.

We could have each block get an `optional´ switch by default with the possibility of an override in a block implementation. But then again, this probably isn't even the trouble and we should just give every block that switch by default.

[greshake]

I have a different suggestion to resolve this issue; Instead of suppressing failing blocks, we could introduce 'profiles' or blacklists that trigger on a command line argument:

[[profile]]
trigger = "desktop" # triggered by the desktop command line arg
blacklist = ["battery"]

If the use-case also uses shared i3conf's we're obviously only shifting the problem. But, you could have something like this in your i3 config as command:
status_command bash -c 'i3status-rs $(cat ~/.is_desktop) status.toml'

By having the .is_desktop file with the trigger as contents in the home directory of the desktop, you can trigger the profile. However we do it, profiles would be a more elegant and flexible solution. But my draft needs polishing :)

[greshake]

I like the idea

[LovingMelody]

Would like to see this implemented as well, the only time I have the battery block is when I'm using a Bluetooth keyboard, this means that this block fails if at any time the keyboard isn't connected. I think setting a block as optional is a good idea.

[ammgws]

I believe the most common issues with respect to batteries and network devices are now non-issues due to the variousallow_missing, hide_missing options that were added to those blocks.