Tinted Theming

[JamyGolden]

Hey @forrestli74, I've been going through all the base16-project (Tinted Theming now, not sure if you've been following) that have been closed and read through the discussion of you describing the intention of base9 and agreeing that the direction of base9 isn't in the same direction of the then base16-project.

I don't actually think the goal was different then, but it turns out these concepts are quite difficult to communicate. At the time of the discussion the concept of "managers", a different concept to "templates" and "schemes", wasn't really understood well or talked about and it seems to me what you wanted to be focusing on most was a "manager" concept to give the best experience to the user and allow them to easily create a personalised theme themselves with minimal effort.

At least in the space Tinted Theming is now, I think we could integrate base9 into Tinted Theming and have a "manager" focus on the user experience to bring your vision/goals into Tinted Theming.

I actually think that without a "manager", base9 lacks a bit since it can become difficult to change the theme everywhere. Going to the website, generating colours, getting the vim snippet, paste that into your config and reload vim and do the same with all the different base9 "templates" is a cumbersome process imo (and is also cumbersome for any scheme system since it's not designed to make it simple for users, the system is built for designers and template maintainers, while managers are specifically built for users).

My proposal

1. Create a base9 directory in our schemes repo (alongside base16 and base24) and bring across your curated colours there as base9 schemes
2. Add base9 support to our builders so they accept a base9 scheme file with a template and it builds the themes. I've recently built tinted-builder-rust which currently builds base16 and base24 and I imagine would be quite simple to move your rust builder code into that.
3. Create and/or bring across your vim and vscode templates to our template repos, eg tinted-vscode, vim (currently still base16-vim but we'd rename to tinted-vim), shell, tmux, etc.
4. Work on our "manager" Tinty(also rust) by adding a subcommand which generates base9 (or any target scheme system) from user input, saves the schemes locally and builds all linked templates with that new personalised scheme. It could look something like this:

   tinty add-scheme "My favourite" "base9" "2D2D2D-CCCCCC-6C99BB-BED6FF-A5C261-D25252-F9A959-FFC66D-D197D9"
   tinty build-templates
   tinty apply base9-my-favourite

   Just example of what we could do, maybe it's 1 command, but the point is a user adds something like that and suddenly their vim, shell, tmux, etc all change at once. Maybe we launch a browser to base9 website so they can copy those colours and paste into Tinty, maybe create a TUI so they can see what's going on during their base9 scheme creation, etc.

Schemes: For designers Templates: For developers and maintainers Managers: For users

What are your thoughts? :smile:

[forrestli74]

tl;dr: Adding base9 support for tinted manager sounds interesting, but I don't have bandwidth right now. I don't want to move/copy anything else from base9 to tinted.

I agree that base9 lacks function to apply themes across different apps. And it would be nice to reuse tinted manager code base to support this function.

Reasons for adding base9 support for tinted manager: support applying base9 to many apps with much less eng effort or user effort

Reasons against it:

1. base9 aims to encourage users to generate/tweak their own schemes. So storing so many existing schemes locally and having to generate a new file and remember the name is working against that. I intentionally use a simple string instead of a scheme file for this reason.
2. IIUC, tinted does not support "add-scheme" command currently, and is pretty custom to base9.

Either way, I don't have time right now to work on this manager feature.

I think the builder code base and config file that users spent time writing for their set of apps is valuable for base9 to reuse. But things like copying/moving over schemes or vscode plugin over does more harm than good.

IMO, other than manager, structures like this:

base9
  vscode
  builder
  schemes
  templates
base16
  vscode
  builder
  schemes
  templates

is much better than

vscode
  base9
  base16
builder
  base9
  base16
schemes
  base9
  base16
templates
  base9
  base16
  ...

in order to support progress for each scheme system.

For example, if I want to derive a new total white color from base9 and use it on the cursor. If I ported over the schemes and templates to tinted system, imaging how many PR I have to create and how hard it would be to manage that.

[JamyGolden]

I was wondering whether I should build [Tinty] or take over the Flavours repo (currently unmaintained) and the owner suggested I build something from the ground up because the state of Flavours code isn't great for various reasons. Flavours has a subcommand which accepts a path to image and it generates a base16 scheme based on that image, builds all the templates the user has hooked up and it then applies that new scheme. This is the last feature I would add to Tinty to reach feature parity with Flavours. In doing this I'm basically adding the add-scheme functionality I mentioned previously.

As for the other reason against it, your base9 scheme name is essentially a 62 character long string and that only works because base9 isn't hooked up to something that changes different app themes with a single command. The user could maybe save their favourite base9 "schemes"/"names"(62 char strings) as a comment.

// Green one
// let g:base9_palette = '282828-ebdbb2-83a598-bc9864-a1a165-9b9ea3-c7927b-87a67c-ba9496'

// Syntwhave cool one
// let g:base9_palette = '282828-ebdbb2-83a598-bc9864-a1a165-9b9ea3-c7927b-87a67c-ba9496'

let g:base9_palette = '282828-ebdbb2-83a598-bc9864-a1a165-9b9ea3-c7927b-87a67c-ba9496'
colorscheme base9

So I feel like exploring colours is nice, but base9 is a bit difficult when it comes to keeping track of ones you've explored and liked. Luckily there are curated themes for them to choose from, (which have names). So avoiding names in favour of a "simple string" is avoiding a short string in favour of a very long string.

IMO, other than manager, structures like this:

I see pros and cons in both, but I don't think the former example is inherently better for scheme system progress.

If I ported over the schemes and templates to tinted system, imaging how many PR I have to create and how hard it would be to manage that.

I feel like hesitant to the idea and are therefore finding reasons not to do it when I personally feel like this isn't even a blocker, unless I'm misunderstanding something. Repo permissions could be given to you where you are able to make fast changes.

You mentioned 1 pro above, I think visibility of base9 for tinted-theming users is another pro as well as having a community that works on an maintains base9.

(Unrelated to all of this. I've been very involved with reading licenses at the moment and have got cargo about generating on my rust projects to ensure the licenses of the crates I use work with the license of my project. base9 doesn't have a license attached to it and as far as I'm aware that means that it falls under "all rights reserved" and it may be unintentionally dissuading people from contributing to base9)

Thanks for your response though :smile: I think you've done a great job with base9. If you find you have bandwidth in future and you're interested in working with Tinted Theming, let me know! I'd also be happy with doing any work required (even all of it) with expanding Tinty and tinted-builder-rust, etc to support base9 and achieve whatever goals we decide on.