A strange sounding issue I know...
I sync config between my desktop and laptop, 1 of which doesnt have a battery. Because of the missing battery, the entire bar fails to load.
IMO the nicest solution would be for the block not to render. However some people may want it to display NO BAT or similar, which could probably be user configured?
Here's a solution using a shell script to generate the config conditionally from templates:
https://faq.i3wm.org/question/1367/anyway-to-include-in-config-file/%3C/p%3E.html
It would be nice to provide a way to do this without an external shell script. I believe @greshake had an idea about this with "profiles" or something.
Yea... At first I assumed this is a rather rare issue but now I'll consider moving to a solution for this more quickly. I still have not decided which solution makes sense; There are elegant solutions (e.g. profiles) that fix this but require significant implementation effort and I fear overcrowding the project with features that solve rare use cases and thereby diminishing maintainability in the long run.
@greshake Has there been any progress on this? What about adding an option for the blocks to silently fail? Users could specify the battery block to not render if the battery was not found.
I think the same issue applies to the backlight block. I thought about implementing a fail_silently = True option for those. Do you think that would suffice for our use case?
I think failing silently would fix a lot of things across the board.
I think we could implement something similar to the Weather block fallback. That is, we show an 脳 when the battery appears to be missing. I'd prefer this to hiding the block, because otherwise users with errors/typos in their configurations will be confused when the block is simply missing. An 脳 provides some visual feedback to those users.
In addition, this would be a pretty easy change to make, because the battery device already returns Result<T> for its sysfs queries.
That would permanently take unused space in case there is no battery/backlight. An explicit hint for users about what the option fail_silently does shouldn't lead to such problems, I think.
As for the implementation, what about returning a SilentError when the block is initialized? That way we could completely remove the block, saving computation time.
Another approach would be to support includes in the configuration. That would allow for making separate configurations without code duplication. Also, include statements for configurations help having a clean configuration overall.
I agree: simply allowing to specify per-block an on-fail behaviour (giving the three options "fail all bar", "leave empty", "show constant string") would be perfect (and I would personally put option three as default for all blocks).
I would prefer not to have only hide or only 脳.
Hide is useful because for instance for disk space: I might put all my "normal" mountpoints in all my PCs, so that those that don't exist in one machine simply don't show up.
脳 instead would be good for "extraordinary" mountpoints, like USB keys or fuse stuff.
Alternatively, or even better, in addition, a for-hosts option for all blocks, interpreted as a regexp, and then the block is shown only if the hostname matches the regexp.
I believe this can now be avoided by setting device = "DisplayDevice" with UPower. Is this incorrect?
I tried to use device = "DisplayDevice" with UPower but when I have my battery unplugged I get the error Error in block 'battery': UPower device is not a battery.
Ok, so I guess it鈥檚 not a fix, then.
I'm using a one liner awk program in a custom block like this.
[[block]]
block = "custom"
command = "upower -i $(upower -e | awk /BAT/) | awk '/percentage/ {bat = $2} END {print (length(bat) == 0) ? \"AC\" : bat}'"
interval = 10
Maybe someone find it useful waiting for a fix.
Hi, I would like to contribute a patch for this issue. What is the conclusion of the community?
Could the solution be something like hide_missing in the net block?
Is there any chance for one of the PR #585 or #233 to be merged in master or are they currently incomplete somehow or have issues ? (the single check passes for both completely)
Most helpful comment
Alternatively, or even better, in addition, a
for-hostsoption for all blocks, interpreted as a regexp, and then the block is shown only if the hostname matches the regexp.