Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should wob really exit due to invalid input? #22

Closed
primeos opened this issue Nov 16, 2019 · 4 comments
Closed

Should wob really exit due to invalid input? #22

primeos opened this issue Nov 16, 2019 · 4 comments

Comments

@primeos
Copy link
Contributor

primeos commented Nov 16, 2019

I don't have a strong opinion on this but I was wondering if it wouldn't be better to just ignore invalid input (and print a warning to stderr or show some graphical indication of a failure, e.g. a red overlay bar or error message).

An advantage of the current behaviour (exiting) is that errors in scripts etc. become more apparent, but it might also be annoying when testing scripts as one would possibly need to restart wob quite often. Or if users aren't aware of this behaviour and don't see the output (e.g. when started via sway's exec) they might think that it did crash for another reason.

If there where some graphical indication that invalid input was received this might be better / more comfortable. Or one could introduce a flag to let the user choose the behaviour.

@bwiercinski
Copy link

I would also rethink behaviour for inputs out of range [0;100]. It is not something unimaginable that I want to set my volume to 150%... Ultimate solution would be displaying the bar as if it were set to 100% with the text in the middle 150. Displaying text is also handy for values below 100.

Of course all of these would be set via flags so I'm proposing:

  • accept values above 100 (default allow)
  • ignore invalid input (default true)
  • display text (default true)

Temporary solution

some_command | grep -P '^([0-9]{1,2}|100)$' > /path/to/wob.fifo

@francma
Copy link
Owner

francma commented Dec 31, 2019

You can set maximum value via -m flag to allow values above 100. I think there is always some kind of maximum value - sound/brightness doesn't go up to +inf. I have not come across situation where it wasn't possible to feed wob only valid values. Maybe you provide some examples where this might happen.

One thing I want to add is to print input that caused wob to exit. With startup command like this, it should give you some hints about what went wrong.

exec mkfifo $SWAYSOCK.wob && tail -f $SWAYSOCK.wob | wob 2> ~/.wob.log

@NilsIrl
Copy link

NilsIrl commented Feb 9, 2020

Temporary solution

some_command | grep -P '^([0-9]{1,2}|100)$' > /path/to/wob.fifo

My solution is this: $(($volume > 100 ? 100 : $volume))

@Brod8362 Brod8362 mentioned this issue Feb 12, 2021
@francma
Copy link
Owner

francma commented May 28, 2021

Implemented in #67

@francma francma closed this as completed May 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants