Refactor, robustness/correctness, plugins

[ppenguin]

I realise this is a huge PR, but if acceptable I think it would be preferrable to include everything, since it would be time-consuming to break it down into smaller parts.

The changes in this PR should be completely backward compatible in terms of the script's original behaviour for pre-existing arguments/flags.

The goal/result of the changes is as follows:

1. add enkei for setting wallpaper
2. implement wallpaper processing plugins (-infrastructure)
3. implement core function override plugins (-infrastructure)

[thevinter]

Hi, thanks for the PR. Going on holiday atm so won't have to check it for a couple of weeks. Had a quick glance and looks good to me but I have a few reservations:

1 - Enkei support is great, but I couldn't help but notice that we're starting to get a flag bloat. There should be a better way to do this. I.e. pointing at the binary or introducing a .config (actually the latter feels like a good idea)
2 - Plugins are interesting but I feel like they're beyond the scope of the application. What I would do instead is just provide a post-process hook where a user can register any script of his choice. Seems more clean and generic. I would really like to avoid maintaining plugins as well

Let me know what you think and I'll come back to you in a couple of weeks. Thanks!

[ppenguin]

Thanks for your feedback.

I started with enkei, but realised the same thing as you: "flag bloat". That is in fact the main motivator for plugins: one could conceive to have all set-wallpaper functions outsourced to plugins, the infrastructure for that is actually within the PR (and implemented in the hyprpaper plugin.

My reason to prefer plugins over external scripts:

1. provide/define a common interface for the core functionality of styli.sh, i.e. rules-based downloading of wallpapers and setting them (i.e. the user can access all functionality via flags (and later maybe env vars too)).
2. allow for self-contained distribution with entirely optional extension (i.e. it would be very easy to distribute some core plugins if they can be maintained, and allow for external plugins e.g. from a community repo or some such.

The post-process hook could be a way, but you'd have to have a way to both pass arbitrary arguments to the script call and pass styli.sh variables (like WALLPAPER) to it as well.
If we also want to keep being able to define all behaviour with flags (which I think is a fair requirement, see below), this will be difficult and very unwieldy to accomplish. With plugins we get to define the interface (i.e. which variables are passed) clearly, which greatly improves integration.

Personally I'm not a fan of config files, especially not for scripts/programs that are intended to be executed from other scripts, systemd units or have their invocations defined in config files themselves (e.g. in a compositor: exec_once = styli.sh ...). This leads to cascaded configs which is a bad UX: one would typically want to define all behaviour of a core function (setting the wallpaper) in one place, in this case the invocation command of styli.sh. (Being on NixOS myself increases the significance of this paradigm¹, but I think it makes for a better config UX anyway in most cases).

So going forward I'd propose I first do the following:

1. make this PR draft
2. remove enkei (or move to plugin)
3. optionally (as a PoC proposal): move all set wallpaper commands to the plugin interface
4. optionally (as a PoC proposal): define and implement different plugin categories with different flags, something like
   • -w| --wallpaper: command to set wallpaper
   • -f | --filter: postprocessing filter
   • -c | --config-hook: here alacritty_change() would go, which is arguably also non-core functionality

In this way handling wallpaper downloads from different providers is clearly defined as core functionality, and all other things can be easily implemented additionally as plugins.
This would be easier if backward compatibility (cli-interface flags) is not a requirement (anymore), I'm not sure whether this would be acceptable (userbase?).

There's no hurry, as I will only occassionally do a litttle work on this, it's one of several side projects and quite busy otherwise too. First enjoy your holiday!

Footnotes

1. I declaratively define a systemd service with a timer that uses one styli.sh Exec to download a wallpaper, overlay a logo, and change it ↩