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

Add flags for setting icons, sink names #34

Merged
merged 28 commits into from
Oct 25, 2020

Conversation

OJFord
Copy link
Contributor

@OJFord OJFord commented Oct 13, 2020

For example:

polybar-pulseaudio-control --sink-icon='⇉ ' \
  --sink-name-from='device.description' --vol-icon-low='πŸ”ˆ ' \
  --vol-icon-mid='πŸ”‰ ' --vol-icon-high='πŸ”Š ' listen

Towards #26. I haven't added options for everything since I thought it'd be better to get some early feedback, and, frankly, these are the ones that I care about πŸ˜„.

Sink nicknames from a pulseaudio property is a bit of a departure from the way it works setting within the file, but it seemed like it's be easier to use, and on my system at least has pretty usable results (to the point I almost want to suggest device.description as a default instead of numbers) - and perhaps there's a pulseaudio-wide way of overwriting descriptions (or other properties) that might be better than maintaining a separate list of polybar nicknames? Haven't looked into that yet.

In fact, it's surely possible, since I can change device.description & bluez.alias together for bluetooth devices by renaming them in blueman.

For example:

    polybar-pulseaudio-control --sink-icon='⇉ ' \
      --sink-name-from='device.description' --vol-icon-low='πŸ”ˆ ' \
      --vol-icon-mid='πŸ”‰ ' --vol-icon-high='πŸ”Š ' listen

Towards marioortizmanero#26.
Note that this is a change in behaviour - previously the `--output` was
incorrect and the usage was displayed as though an error but it was
ignored.

It seems clear that the intention was the `output` subcommand,
so I've left that in rather than remove it, or change the `--`-parsing
behaviour to exit with status 0 on a bad argument in order to continue
to allow it. I've also changed it to a single line output instead of the
full `usage` - since this makes it clearer what's wrong in polybar,
where it may occur if typo'd in config, for example.
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
@marioortizmanero
Copy link
Owner

marioortizmanero commented Oct 14, 2020

I like your idea about --sink-name-from, but what if, instead of applying it with setNickname at the beginning of the script, we read the property as a fallback before it's displayed in getNickname? That way, if a new sink is added we'll get its description as well.

@OJFord
Copy link
Contributor Author

OJFord commented Oct 14, 2020

Yes that's actually a problem I encountered running it today - no description when I connected my Bluetooth earphones.

I was thinking the solution would be setting interval to something reasonable (and putting up with that as a maximum period of no nice name) - but I prefer yours. Coming.

Previously a newly connected device wouldn't have its prop read.
@marioortizmanero
Copy link
Owner

Great! I think the base implementation is quite good already. If you have time, you can add the rest of the flags now (and update the README if possible) πŸ‘

@OJFord
Copy link
Contributor Author

OJFord commented Oct 16, 2020

Done, and I realise now forgot the readme (sec) - though I confess I haven't tested them all (some I'm not set up to) but they were pretty straightforward with the parsing already there.

README.md Outdated
```ini
[module/pulseaudio-control]
type = custom/script
exec = "polybar-pulseaudio-control --vol-max=150 --vol-icons='πŸ”ˆ ,πŸ”‰ ,πŸ”Š ' --sink-name-from-prop=device.description --osd"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to be quoted, but GitHub renders it weirdly if it isn't: --vol-max, --vol-icons, and --sink-name-from-prop get highlighted, so it's almost an accidental feature, but then --osd doesn't.

Copy link
Owner

@marioortizmanero marioortizmanero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I've left some suggestions we can discuss before merging this. Sorry if I'm asking for too many changes, I want to make sure it's right :P. Also, by updating the README I meant the "Configuration", "Usage" and "Useful icons" as well. If that's too much work I can take care of it, but it should be easy.

pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
Copy link
Owner

@marioortizmanero marioortizmanero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is actually ready to be merged! Thank you very much for your work :)

I will release a new version with this for those following the repo. Give me a moment to try this myself in my setup first. I'll then make a few changes updating the example module in the README, which is basically what I use.

@marioortizmanero
Copy link
Owner

Also, are you still planning on releasing this on the AUR? If so, let me know when you do. We can add that to the README, and I could help you as an Arch user with a couple packages in there as well.

@marioortizmanero
Copy link
Owner

marioortizmanero commented Oct 25, 2020

  • Should usage be called when an action/option is unrecognized?
  • Should we have a line length limit for the options help message?

I've made some changes I wanted to do. Let me know what you think.

@marioortizmanero marioortizmanero force-pushed the config-args branch 3 times, most recently from e4495f5 to f50ab9b Compare October 25, 2020 16:20
pulseaudio-control.bash Outdated Show resolved Hide resolved
pulseaudio-control.bash Outdated Show resolved Hide resolved
@OJFord
Copy link
Contributor Author

OJFord commented Oct 25, 2020

Also, are you still planning on releasing this on the AUR?

I would like it to be available there yes, happy to package it myself or I'll of course hold off if you'd like to maintain that yourself - you'll always know when there's a new release after all πŸ™‚.

Should usage be called when an action/option is unrecognized?

The reason I didn't was so that there's a single line of output when it's misused - reading nicely in polybar.

When I booted my PC just now for example, since I hadn't changed my main config since making these changes, polybar read 'Unrecognised option: --sink-icon'. If we printed the full usage polybar would just show the first line 'Usage: ...' which is less helpful. I suppose printing usage after the current output would work though (not tested).

Should we have a line length limit for the options help message?

Probably.. actually even the first one (autosync) is a little long compared to where e.g. git & grep wrap. Not sure if there's any pseudo-standard for help text specifically, but I doubt anyone would complain about 80ch.

@marioortizmanero
Copy link
Owner

I would like it to be available there yes, happy to package it myself or I'll of course hold off if you'd like to maintain that yourself - you'll always know when there's a new release after all slightly_smiling_face.

We could just co-maintain the package, if you want (I think that's possible in the AUR).

The reason I didn't was so that there's a single line of output when it's misused - reading nicely in polybar.

When I booted my PC just now for example, since I hadn't changed my main config since making these changes, polybar read 'Unrecognised option: --sink-icon'. If we printed the full usage polybar would just show the first line 'Usage: ...' which is less helpful. I suppose printing usage after the current output would work though (not tested).

Fair enough.

Probably.. actually even the first one (autosync) is a little long compared to where e.g. git & grep wrap. Not sure if there's any pseudo-standard for help text specifically, but I doubt anyone would complain about 80ch.

80 characters is my goto as well. It looks a bit stretched because of how long the arguments are, not sure what you think about that:

image

It uses a single echo from now on because it's much easier to edit and because of the character line at 80 chars. I've also updated the message according to your review, but I'm not sure if that's exactly what you wanted. Let me know otherwise.

I think we should also change the default value so that it's between [ instead of (. The latter might be thought of as part of the explanation, while the former stands out as something different. This is just nitpicking, though.

@OJFord
Copy link
Contributor Author

OJFord commented Oct 25, 2020

We could just co-maintain the package, if you want (I think that's possible in the AUR).

Ah yes, so it is. πŸ‘

πŸ‘ for single echo, I was tempted to do that too.

Screenshot looks ok to me, maybe gets a little hard to read at the bottom over several lines, but then spaces around that and not the others might look weirder. (Also nitpicking though!) Think I agree about [] defaults.

@marioortizmanero
Copy link
Owner

marioortizmanero commented Oct 25, 2020

I've ended up using an indentation of 2 spaces instead of 4 for the help message, which gives just a bit of space more (not sure what else can be done). I'll merge this and we can discuss the PKGBUILD at #35.

Thanks a lot for your help with this PR!

@OJFord
Copy link
Contributor Author

OJFord commented Oct 25, 2020

Awesome, thanks!

@OJFord OJFord deleted the config-args branch October 25, 2020 22:32
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

Successfully merging this pull request may close these issues.

2 participants