search

Biont / sway-launcher-desktop

TUI Application launcher with Desktop Entry support. Made for SwayWM, but runs anywhere
GNU General Public License v3.0
607 stars 28 forks source link

Support switching between different provider configs #15

Closed s-hamann closed 4 years ago

s-hamann commented 4 years ago

This PR adds support for switching between multiple provider configurations. The environment variable PROVIDERS_FILE can be used to select which file sway-launcher-desktop uses. If not set, the currently hardcoded providers.conf is used.

Being able to select from different sets of providers enables setting up several launchers for different purposes (e.g. to run applications, open bookmarks, copy passwords or OTP tokens, ...).

I changed the history file name to include the name of the provider config file. This is a slight incompatibility with current master. However, mixing histories between providers that supply different commands does not make much sense in general, so this seems necessary.

Biont commented 4 years ago

Thanks! This was pretty high up my todo list, but I wanted to get the providers feature out first and not get caught up in an endless loop of trying to make it perfect from the start. So again: Thanks for crossing an item off my list :)

That said, I did think about implementing this right away, but then held off because I wanted to think about option handling in general for a bit longer: How much I want to rely on environment variables now that I introduced the first configuration file.

My idea was to add a general config file later, where things like the TERMINAL_COMMAND could be stored more conveniently. Then this could also be used to de-hardcode some of the fzf-params

Obviously, dynamically switching providers is not something you can configure in a static config file, which is exactly the reason this is a separate file to begin with (even if there is not even a main config file right now)

The question that remained for me is whether or not I want to keep using environment variables and what benefit the introduction of a getopt-loop for per-instance config overrides could have.

Anyway, I am probably just rambling a bit, but maybe you can share your opinion if you want. I had a look at your PR and like what I see, but still need to test it myself.

s-hamann commented 4 years ago

I also considered a command-line option. I went with the environment variable because

  1. it fits nicely with TERMINAL_COMMAND
  2. it is easily implemented. I did not want to implement a (however simple) parser for command-line options just for this. Additionally, the option would need to be passed to the various self-invocations of sway-launcher-desktop.sh. That requires a bit of thinking and code and is fairly error-prone. Doable, but not exactly a no-brainer. The benefit, at this point, seems marginal to me. From a user's perspective, I only have a slight preference for parameters over environment variables (at least when the software in question is bound to a hotkey).

+1 on the general config file, though

Biont commented 4 years ago

Having a just a slight preference for arguments, but struggling to justify the required effort is pretty much what I am left with as well.