Allow themes to have an install.sh file that's offered on install

[dhh]

Would be great if we could allow themes to change more than just colors. What if they could use custom fonts and icon themes? I propose that we allow themes a install.sh file that when the theme is installed we will show on the terminal and ask "Do you want to let theme install these dependencies?". If so, we run install.sh, then set the theme.

[dhh]

Goes together with the new power to set a custom icon theme: 3d22840

[ryanrhughes]

While I like this idea in theory, I feel as though it could become a nightmare rather quickly.

Is there a way we could accomplish the same flexibility via a more robust themeing convention? We could even go so far as allowing a sort of manifest definition to pull in deps but still ensure the core is consistent for compatibility.

I can just see some overzealous theme uninstalling Waybar to bring in AGS or something in their install.sh and then when the user changes their theme again, they're kind of hosed.

[bjarneo]

Created a new PR with lifecycles + thoughts: #629

I can move the discussion here.

This is an issue that either can be overcomplicated, or just go for simplicity for now.

Edit moved the thoughts from the PR to this issue:

As @ryanrhughes mentioned (#433 (comment)), maybe it should be solved somehow else.

1. Should the install be guided
2. Should the theme author be able to do anything

The alternative is to have e.g. a meta.json like this (example with dependencies only).

{
  "name": "NES",
  "author": "Bjarne Oeverli",
  "dependencies": ["ttf-jetbrains-mono"],
}

Example install

#!/usr/bin/env bash
set -e
if [ -f meta.json ]; then
 deps=$(jq -r '.dependencies[]' meta.json)
 for dep in $deps; do
   if ! pacman -Qi "$dep" &>/dev/null; then
     sudo pacman -S --needed --noconfirm "$dep"
   fi
 done
fi

[jwkicklighter]

I think the idea of declaring dependencies (and possibly other metadata) is a better approach than executing bash scripts, mostly from a security standpoint.

It also has the benefit of providing a standard interface so theme makers aren't all implementing their own versions of the same install script. And for items like dependencies, it also opens the door for automatic package removal in the future, rather than depending on theme authors to write that sort of logic in an uninstall script. Of course, it would probably be wise to ask the user if dependencies should be removed so they are left in place if the user wants them for other reasons.

[jamesmcm]

@dhh it would be useful to be able to bundle and specify a whole GTK theme instead of just the icon set (and not have the theme selector override the GTK theme).

Also see #917 re. the default themes taking precedence over some theme settings (fonts, etc.)

Maybe also a full Chromium theme as an unpackaged extension but I'm not sure if we can install that from the CLI?

[dhh]

On second thought, I don't think we want this. It's good that themes are limited and sandboxed in the ways they're installed.