Proposal: Interop with other style systems (Base9)

[joshgoebel]

Pulling this out from a separate thread because it's easily what I'm been talking about a few places:

---

I imaging the north star is that base9 use base16 as a library. base9 handles color mixing magic, deciding what color to use for different semantics, including different shades, such as diff_added, diff_added_background, current_line_highlight. base9 then passes this information to base16 and uses base16 to generate actual themes for apps.

Originally posted by @lijiaqigreat in #7 (comment)

---

This is a perfectly valid request and not even that difficult. I imagine a executable builder rather than a library, but the effect is the same in either case. The simplest form of interop (with very little effort needed to support) with out ecosystem would be "masquarading as another supported style system"... ie base9 might FIRST generate a Base24 yml file, and then run that through builder - and would immediately have access to our ENTIRE ecosystem of targeted applications.

Ultimately we'll need a "open" interop format such as BaseX or Base99 or something that doesn't put any caps on the colors - some theming systems don't have arbitrary caps. Thankfully, none of our output templates care about color caps (once they go semantic) - that's a system/input concern... so it'd be easy to just say "this is an interop scheme" and that would mean that the number of colors would be ignored, and otherwise it would be treated as a valid Base17 system. We might call this system interop.

Also: A special system isn't even necessarily if builders had a --relax mode to turn off a few sanity checks... so if you ran Base17 in --relax mode and there happened to be 54 colors, the builder would just keep on doing it's thing as if that was normal. I think this is the simplest way to get builder support quickly to try this out.

And I think the builder usage complexity is still pretty high (having to setup an entire folder structure before you begin)... this thread can talk about both of these concerns together and how to improve things. (I'm assuming the desire to quickly build one scheme against many templates, perhaps a scheme being auto-generated of the flu, etc - not necessarily coming from a static collection of schemes).

[forrestli74]

I'm taking this as a low priority for base9. And I think you should too. It's more important to go agile (for me at least) by prioritize building and iteration than specing.I'm taking this as a low priority for base9. And I think you should too. It's more important to go agile (for me at least) by prioritize building and iteration than specing. And I don't think base9 should even consider to use base17 for until base17 reaches "1.0".

[joshgoebel]

Well, it's not just base9 I'm thinking about... you could substitute any other ambitious theming system for "base9" here, but I'm not in a hurry to build tooling for imaginary users... so if you aren't currently in a position to want to pitch in and help discuss/push this forward, that's fine. It'll wait until you have time or the next theming system comes along that's interested.

I don't think base9 should even consider to use base17 for until base17 reaches "1.0".

I wouldn't worry about numbers. I am interested in hitting 1.0 (vs staying at 0.2 like base16 has forever)... but the first release we issue should be amazing and useful - regardless of whether we decide to call it 0.1 or 1.0... waiting for an arbitrary version # would be a mistake IMHO.

What you may want to wait for is template support. A lot of the work we're doing only truly comes to fruition when templates start to update - that's far more important than an arbitrary version number.

[belak]

Thanks for the idea, but we're dropping this for now - the updated 0.11.0 spec provides values a scheme system needs to provide for the builder to use, but doesn't define a way to integrate them at this time.

We are going to stay focused on palette-based systems for the time being, and maybe branch out in the future.