How to "translate" pywal themes?

[GideonWolfe]

Maybe it's because I don't fully have my head wrapped around how base16 schemes work, but I'm trying my best to adapt a theme made with wal (hellwal specifically) to work with stylix.

At first this didn't seem too complicated. I used to use pywal frequently, and I noticed that the theme template i'm referencing is using colors 0-15.

My confusion is that the same hex values seem to be different "bases" depending on the tool. Here is the base16 and the hellwal theme to compare, both of Gruvbox Light Medium.

• Both schemes assign the fbf1c7 to the 0 slot (either color0 or base00), this makes sense.
• But with a value like 9d0006, it is assigned color9 by hellwal and base08 by Stylix.

By all accounts, the stylix implementation seems to be correct. The base16 scheme even has a comment that says the value should be "red", which falls in line with the guidance here.

[trueNAHO]

I never used pywal or any of its variants. I believe the only relevant information for this discussion is that it overrides configuration files, resulting in application themes updating when running pywal again with different inputs.

AFAIK, this is not immutable and relies on applications supporting hot reloading. This goes against the immutable Nix philosophy and may lead to partially applied themes when hot reloading is not supported.

Could you elaborate what you mean by "translate"? Do you mean that the initial pywal output is used by stylix.base16Scheme? Otherwise, take a look at #371. It has also somewhere been discussed to use Nix specializations to somewhat support hot reloading by swapping Nix configurations at runtime.

[danth]

Do you mean that the initial pywal output is used by stylix.base16Scheme?

I believe that's what this issue is referring to.

[danth]

I too am not familiar with pywal so I can't offer much advice here.

[GideonWolfe]

Apologies for the confusion surrounding my framing, I don't really have any confusion related to pywal, I used the tool in the past, but fully moved over to Nix + Stylix, because as you said, it fits the philosophy.

I was simply using it as an example for comparison, because I am still confused about a ground source of truth when applying my colors to other programs.

I understand that all bets are off when using a colorscheme generated by a wallpaper or image, and there's no guarantee that any specific color will correspond to any specific ${base}. But for handmade themes, they supposedly follow the conventions outlined here, which I find holds true for the base16 themes, and alignes with the spec here.

So my logic is, if I find somewhere on the internet someone is making a theme for a program that I want to theme, except they happen to use pywal (or a fork of pywal), and it generates the same amount of colors, and they're using an identical handmade theme (like Gruvbox), the colors defined by pywal and the colors defined by stylix should be a 1:1 match.

Sometimes, this holds true. 99% of the time, base00 for stylix corresponds to color0 for pywal, which is the "background" color. But for the other colors seem to be far less consistent, and I was wondering if there was some pattern I was not seeing, or I just have to try mixing around the colors until I find the right "match"

TL;DR when I use a handmade theme with stylix, I can be confident that base08 is going to correspond to red. I thought this was inherent to the spec, is there a reason that other tools name them differently? is there a pattern?

[danth]

It looks like the colors in the input theme are listed in a different order in tinted-theming/schemes (commonly used with Stylix) vs pywal. I'm not too sure why this is the case, but you could compare these two files to determine which colors you need to swap.

[trueNAHO]

So my logic is, if I find somewhere on the internet someone is making a theme for a program that I want to theme, except they happen to use pywal (or a fork of pywal), and it generates the same amount of colors, and they're using an identical handmade theme (like Gruvbox), the colors defined by pywal and the colors defined by stylix should be a 1:1 match.

It should be possible to have a pywal to Stylix conversion script, although its complexity hardly justifies it being implemented. Either way, this would become even more complex with base24 support and somewhat impossible once Vim highlight groups are implemented.

Unless danth's hint does not always help, you might have to manually convert:

It looks like the colors in the input theme are listed in a different order in tinted-theming/schemes (commonly used with Stylix) vs pywal. I'm not too sure why this is the case, but you could compare these two files to determine which colors you need to swap.

[GideonWolfe]

Thanks for taking the time to look into this! So excited about all the changes in the pipeline. The particular feature about "named colors" like "foreground" would definitely remove a lot of the confusion when picking colors for themes. Out of curiosity, what is meant by Vim Highlight groups? Aren't we already able to generate arbitrary lua/vimscript files containing highlight group definitions with colors provided by Stylix?

[trueNAHO]

what is meant by Vim Highlight groups? Aren't we already able to generate arbitrary lua/vimscript files containing highlight group definitions with colors provided by Stylix?

As mentioned in #477 (comment), the Vim highlight groups are essentially an attribute set of named colors, whose purpose is to self-document the style guide and hopefully resolve styling inconsistencies. It is not to implement the actual highlight groups inside Vim, although this would be trivial to implement once we have this.