fix: add spotify launcher arguments into config

[windx-foobar]

I need to remove Spotify updates. I can't set this in the file configuration. I have to modify the .desktop file and pass it the --skip-update argument. I thought it might be useful to add these options to the configuration file.

[kllmanu]

@windx-foobar I've set the config in /etc/spotify-launcher.conf and in ~/.config/spotify/spotify-launcher.conf but it has no effect, it still tries to update.

[spotify]
## Pass extra arguments to the spotify executable
## You can test this with `spotify-launcher -v --skip-update --no-exec`
#extra_arguments = []
## On HiDPI displays spotify doesn't pick up the scale factor automatically
#extra_arguments = ["--force-device-scale-factor=2.0"]
## On wayland you might need
extra_arguments = ["--enable-features=UseOzonePlatform", "--ozone-platform=wayland", "--skip-update"]
## How often to try to resume the download until giving up (0 for unlimited)
#download_attempts = 5

[windx-foobar]

@windx-foobar I've set the config in /etc/spotify-launcher.conf and in ~/.config/spotify/spotify-launcher.conf but it has no effect, it still tries to update.

[spotify]
## Pass extra arguments to the spotify executable
## You can test this with `spotify-launcher -v --skip-update --no-exec`
#extra_arguments = []
## On HiDPI displays spotify doesn't pick up the scale factor automatically
#extra_arguments = ["--force-device-scale-factor=2.0"]
## On wayland you might need
extra_arguments = ["--enable-features=UseOzonePlatform", "--ozone-platform=wayland", "--skip-update"]
## How often to try to resume the download until giving up (0 for unlimited)
#download_attempts = 5

Hi!
Please see it README
Need add [launcher] section :)

[kllmanu]

@windx-foobar Ah sorry my fault, didn't check out your code. 🙈

[BCSharp]

This patch is very useful, thanks for proposing it. It would be great if you could also add support for option keyring. The default location of the keyring is in /usr/share/... which is not user-writable. I am using spotify-launcher on a system without root privileges and have to pass --keyring=${XDG_DATA_HOME}/spotify-launcher/keyring.pgp on every invocation. It would be very helpful to be able to put it in ${XDG_CONFIG_HOME}/spotify-launcher.conf and be done with it.

[windx-foobar]

Hi!

It would be great if you could also add support for option keyring

@BCSharp Added :)

[BCSharp]

Thanks, works for me! 👌

However, since this is a PR for a pull into the maintainer's repository, I have a few observations relevant for wider usability. The way how it is implemented now, the keyring value in the config file (if not empty) overrides the value provided with parameter --keyring on the command line. This is not intuitive. Most (if not all) tools use the convention that command line parameters and options have a higher precedence over (override) any values from config files, which in turn have a higher precedence over (override) built-in defaults. I doubt the maintainer will be ready to merge this PR as it is now.

[windx-foobar]

Thanks, works for me! 👌

However, since this is a PR for a pull into the maintainer's repository, I have a few observations relevant for wider usability. The way how it is implemented now, the keyring value in the config file (if not empty) overrides the value provided with parameter --keyring on the command line. This is not intuitive. Most (if not all) tools use the convention that command line parameters and options have a higher precedence over (override) any values from config files, which in turn have a higher precedence over (override) built-in defaults. I doubt the maintainer will be ready to merge this PR as it is now.

Hmm. Thanks. I repair it soon...

[windx-foobar]

Thanks, works for me! 👌

However, since this is a PR for a pull into the maintainer's repository, I have a few observations relevant for wider usability. The way how it is implemented now, the keyring value in the config file (if not empty) overrides the value provided with parameter --keyring on the command line. This is not intuitive. Most (if not all) tools use the convention that command line parameters and options have a higher precedence over (override) any values from config files, which in turn have a higher precedence over (override) built-in defaults. I doubt the maintainer will be ready to merge this PR as it is now.

Done it :)

[lavrentev18]

need to approve this pr