Move to Tinted Theming future maintenance and dev?

[JamyGolden]

Hey @Misterio77 :)

base16-shell has a very basic manager (it has hooks and supports switching to themes of fzf, tmux, sublime-merge, vim, etc). I build and maintain it and as I've been expanding I've decided to write it in something that's not bash 😅 I've been very interested in rust for a while and thought it was a good time to learn it. So I've been building base16-shell-manager. It's still in early repo phases and I don't have a readme setup yet, but it's in a working state with hooks set up.

If I were to continue building base16-shell-manager I think it would turn into something quite close to flavours. So that got me thinking, why not just continue with flavours dev under tinted-theming since you've mentioned that your focus is now on nix-colors and the nix world. If this did happen it would still be good to get your input on some of my ideas and input on the first few pull-requests to make sure I'm understanding things properly.

What are your thoughts?

[Misterio77]

Hey Jamy, hope you're well! Sorry for taking too long to respond!

I love your idea and I'm super happy with you building an alternative.

I'd be happy to hand flavours over, but I think building on top of it is not worth it at all: the code is not in a very good state, but that is fixable; the main issue is I accepted contributions very liberally, did not write any regression tests, and now there's way too much specific (and undocumented) behaviour that make significant changes to flavours very, very hard to do without breaking someone's workflow. I blame this on Chris' messy approach to base16; the fragmentation was insane and very hard to deal with, specially if you realize that most people want to customize templates but not schemes (thus they being co-located is terrible). Tinted theming fixed this very nicely, but, as mentioned, porting flavours to it is very, very hard (see #79 (comment)). Band-aiding over these fundamental design problems is not fun at all (really, takes away most of my motivation of working on flavours), and I would rather you focus on making the best design instead!

I think the only way forward is a rewrite with breaking changes, but ideally this would be done all at once and with an easy migration path, which is, unsurprisngly, very hard to do.

Would you be interested perhaps in developing yours as flavours' successor, and, when it's ready for prime time and handles most of flavours use cases, we can perhaps deprecate flavours and point users to it? This way, you won't have to build your solution with backwards compat holding you back.

[JamyGolden]

Thanks for detailed response! 😄 It makes sense how things can get a bit out of control with contributions added uncritically.

I've been building things up with Tinty (new name) since I sent the initial message to you and I think it's pretty close in terms of features:

• flavours apply mocha -> tinty apply base16-mocha
• flavours info mocha -> tinty info base16-mocha
• flavours current -> tinty current
• flavours update -> tinty setup
• flavours --config -> tinty --config
• flavours --directory -> tinty --data-dir
• Very similar config.toml structure including [[items]] tables with hook properties

There are two distinct differences between tinty and flavours and I'm not sure if you feel this is too big of a difference to be a successor of Flavours.

Outside of initial goals of a simple (base16 and now base24) manager, my general intention is to keep it simple and expand on functionality when there is a use case that can't currently be easily achieved and it makes sense for the tool to do. (The hook being run makes it quite extensible)

No builder and therefore no image scheme generation

I don't currently have a builder in Tinty, but I do plan on adding one in future. I've spoken to the maintainer of base16_color_scheme (rust crate used to build in flavours) and they said they would update it to adhere to the latest builder spec. Until then I won't have a building functionality included in tinty.

Tinty currently clones templates set in config.toml in the [[items]] with tinty setup and when tinty set base16-mocha is executed, it runs through the [[items]] tables and copies the relevant theme file from the template repo to the local data dir. So all template repos provided must have the theme files already generated; Most base16 template repos have them already generated and all tinted-theming template repos are synced with the latest schemes weekly.

Theme generation based on and image is a really nice feature of Flavours, but I would first need to have a builder integrated before I could look at this feature.

---

I just wanted to mention these differences so you were fully aware before making the decision to deprecate and link to Tinty. I've updated the readme so things are a lot more clear than they were before. I've also added a Migration from Flavours section describing a little of the above as well as giving examples of converting config files across.

[JamyGolden]

I've just created a basic Rust library to create schemes from images. https://github.com/tinted-theming/tinted-scheme-extractor-rs

Something I wanted to change was to keep the red, orange, yellow, green, cyan, blue, purple, brown as (base08-base16) To help get a more consistent scheme. So I used some of your code to generate base00-base07, and then for base08-base16 I look for the closest colors to the target colours and do some other things to create colours that would work for those values even if they aren't in the image.

I've still got a bit more work to do on it, but I'll add it Tinty and then Tinty will have at least all the features Flavours does.