Read Stylix font externally

[TheColorman]

When Stylix builds a theme, the palette is saved to /etc/stylix/palette.json. This allows program on your system to read this file for information about the colors used in the current Stylix theme. Is there something similar for the Stylix font? I want to make an Obsidian plugin that, on launch, reads the Stylix theme and generates a theme file for the Obsidian vault to use, and while I'm able to get the colors by reading the palette.json file, I'm not sure how to get the current font.

[trueNAHO]

When Stylix builds a theme, the palette is saved to /etc/stylix/palette.json. This allows program on your system to read this file for information about the colors used in the current Stylix theme.

AFAIK, these palette files are only generated to avoid palette reevaluation or improve development experience:

• https://github.com/danth/stylix/blob/7cdbd128172d7c4ec63f5073d49da5d0e7d6396c/stylix/palette.nix#L139-L145
• https://github.com/danth/stylix/blob/7cdbd128172d7c4ec63f5073d49da5d0e7d6396c/stylix/palette.nix#L156-L157

@danth, is that correct?

Is there something similar for the Stylix font?

I don't think so.

I want to make an Obsidian plugin that, on launch, reads the Stylix theme and generates a theme file for the Obsidian vault to use, and while I'm able to get the colors by reading the palette.json file, I'm not sure how to get the current font.

Would it not be easier and more maintainable to write a Stylix Obsidian module? That way others would also benefit from this.

[trueNAHO]

Would it not be easier and more maintainable to write a Stylix Obsidian module? That way others would also benefit from this.

I did consider this, but Obsidian keeps theming on a per-vault basis ("vault" being a directory with markdown files and Obsidian configuration, linked to by the user configuration) with no NixOS options, which means a Stylix module for Obsidian would have to first find the user config for obsidian, determine the paths of every Obsidian vault and then create a theme.css file in each vault's themes folder. This feels like a lot of moving parts that could break pretty easily.

What about Stylix wrapping the Obsidian binary, such that it creates the desired theme files in the vault's directory upon launching it? Would that be possible? Creating a theme file if it does not already exist seems to be a negligible performance hit.

[TheColorman]

What about Stylix wrapping the Obsidian binary, such that it creates the desired theme files in the vault's directory upon launching it? Would that be possible? Creating a theme file if it does not already exist seems to be a negligible performance hit.

I don't think it'd be impossible, but Obsidian is closed source so it would definitely be tricky. The program either launches outside of a vault (first launch or second instance) or inside vault (first instance after creating your first vault). A wrapper would have to both be able to tell whether Obsidian was opened in a vault, while also getting its path, all without access or modification to its source code (sadly none of this information is available in the stdout).

[trueNAHO]

What about Stylix wrapping the Obsidian binary, such that it creates the desired theme files in the vault's directory upon launching it? Would that be possible? Creating a theme file if it does not already exist seems to be a negligible performance hit.

I don't think it'd be impossible, but Obsidian is closed source so it would definitely be tricky. The program either launches outside of a vault (first launch or second instance) or inside vault (first instance after creating your first vault). A wrapper would have to both be able to tell whether Obsidian was opened in a vault, while also getting its path, all without access or modification to its source code (sadly none of this information is available in the stdout).

I was thinking about adding the following obsidian wrapper to $PATH:

# TODO: Set correct values.
readonly current_vault_path="$(echo "Does a reliable result exist?")"
readonly theme="$(echo "What is the name of the theme file?")"

if ! [[ -f "$current_vault_path/$theme" ]]; then
  # TODO: Create '$current_vault_path/$theme'.
fi

# TODO: Call the next 'obsidian' command in '$PATH' that is not this wrapper
# script to avoid infinite recursion.
obsidian

However, when launching Obsidian from the wrong path or creating another vault from within Obsidian, this wrapper will not be very helpful.

What would your plugin solution look like? Is it a vault-specific theme that needs to be manually added per vault? If Obsidian does not support a global configuration file, then accessing palette.json would indeed be the better solution. Otherwise, consider requesting a global configuration at Obsidian, if this does not go against their design philosophies.

[danth]

The /etc/stylix files are mainly for debugging purposes, yes. They also exist at ~/.config/stylix (or elsewhere if $XDG_CONFIG_HOME is set), which may be relevant when only Home Manager is in use.

The line in the docs is referring to the config.lib.stylix.colors attribute set within Nix code. Admittedly that's not made very clear.

Personally, I would solve this as follows:

• Generate the theme in Nix, using writeFile or similar
• Inject the path to this file into the plugin code (this could also use an environment variable or ~/.config to avoid rebuilding the plugin for theme changes, if it requires compilation)
• Then all the plugin needs to do is copy or symlink the file whenever a vault is opened

[TheColorman]

What would your plugin solution look like? Is it a vault-specific theme that needs to be manually added per vault? If Obsidian does not support a global configuration file, then accessing palette.json would indeed be the better solution. Otherwise, consider requesting a global configuration at Obsidian, if this does not go against their design philosophies.

Plugins in Obsidian are vault-specific. I imagine a plugin that you install into a vault. Every time the vault is then launched, the "global palette" is fetched, and the local vault/themes/Stylix/theme.css is overwritten if needed. The user can the select Stylix from the list of themes to switch to it, which will apply the theme from the file and listen to changes.

The /etc/stylix files are mainly for debugging purposes, yes. They also exist at ~/.config/stylix (or elsewhere if $XDG_CONFIG_HOME is set), which may be relevant when only Home Manager is in use.

The line in the docs is referring to the config.lib.stylix.colors attribute set within Nix code. Admittedly that's not made very clear.

Gotcha, makes sense.

Personally, I would solve this as follows:

• Generate the theme in Nix, using writeFile or similar
• Inject the path to this file into the plugin code (this could also use an environment variable or ~/.config to avoid rebuilding the plugin for theme changes, if it requires compilation)
• Then all the plugin needs to do is copy or symlink the file whenever a vault is opened

Oh yeah, generating the theme file on build makes a lot more sense than having the plugin do it. I don't think injecting code would work, but environment variables or a ~/.config would. I personally lean towards something in ~/.config/obsidian/ since Obsidian already has a global config, but I'm not sure if adding third-party files is against some conventions.