Potential merge/inter-operation with base9 #7
Comments
|
I'm going to tag @FredHappyface who created https://github.com/Base24/base24 since this topic quite related to them too. |
|
i think it's also important to keep it backward compatible at the same time (so such changes wouldnt instantly make all existing but not actively updating themes or templates obsolete) as i understood from base24 page it's there:
|
|
as for base9 - i think instead of literally merging with them we could borrow the idea of having lightness/saturation/etc variations of colors, similar to existing: |
|
(both approaches would solve my personal concern of not able to generate full linux terminal palette from base16 color theme) |
|
I'd also be happy to work towards a potential merge and am happy to collaborate as I do not see the need to duplicate efforts. The reason I created base24 was to solve the following issues
For me, once the following issue is resolved then there is no need for base24 |
|
Just wrote vision for base9. Based on the current discussion of base16, I think it's going towards a different direction. These are just based on my perceived vision of base16, let me know if I misunderstood. Who does it serve forBase16's primary audience is template writer and theme writer. It aims to provide a precise API for them to talk to each other. While I want Base9 to really be for the end user and really enable the user to specify its own theme easily and apply them easily. There is a conflicting need here: The template developer need a lot more than 16 colors, and need a computer readable config file. If an end user without background knowledge wants to design a new color theme, it certainly doesn't want to specify more than 16 colors. In my opinion, 16 is even too much, that's why I reduced it to 9, I'm also considering further reducing it to 4. You could also argue that writing a config file is too daunting for the end user. How to deal with breaking change.Base16 tries to make sure all changes are non-breaking or have a smooth migration. Since it already has a large audience, we don't want things to stop working. Base9 is a new project and tries to solve legacy problems that base16 by a new code base and standard. In my opinion, most of base16 is very boilerplate and is far easier to rewrite than to migrate if there is a breaking change. ConclusionIf this is accurate, I think both have reasons to exist. I'll keep my base9. And feel free to close the issue. |
|
I'm not sure Base9 (or something similar) couldn't be built on TOP of Base16... as a tooling/ease of use layer... Many base16 themes could likely easily be upgraded/downgraded to Base9 themes easily enough in an automated/computer color science way. But I think we're also fine if the project has it's own goals/ideas and wants to be it's own thing. I don't think Base16 is trying to gobble up things just cause... only if we could perhaps solve the reason for the fork in the first place. |
|
I'm assuming I understand the base16's vision correctly.
Makes sense, only if the second point is addressed. For that reason, I'm considering changing the name from base9 to baseN or something completely different, like omnitheme. I also think the legacy style guide is put in without enough thought. Those legacies are more of a burden than an asset. I think the builder side of things are much better, but still has room to improve. But the "simple" builder is easy to rewrite. The only thing that's hard to port over is the universal builder. By having base9, we can discard the legacy problems and only copy what's good. In my opinion, that's far easier than migrating base16 gracefully. (As I said, the only part of the effort that is wasteful is the universal builder) P.S. |
Wait, what? I thought you wanted 4 or 9? Or do you mean including computed variations? I'm personally ok with us having a few limited filters - esp like opacity... which could allow for easy "variants" of colors (light, dark), etc... though I'm not sure how anyone else feels about that. But I feel like we should stick to "max 8-16 hues" or else our names starts to mean nothing...
😵💫
This is indeed a serious legacy problem and I see no easy path here... other than to provide better style guide/better tools - and then let the theme maintainers come back and submit newer, better themes.
Why? It could be like 20-30 line script/wrapper around simple builder...
I'm really not expecting you to persuade us to close up the Base16 shop and come over to Base9... but no ill-will either. I think Base16 is the "established brand" so even if it's a slog we'll probably stick around and make an attempt to fix it proper... I think more than anything it just requires a good plan and some time... I totally agree with a lot of your critiques of Base16 and would like to think now that the project is active again we'll resolve many of them. |
i think we should just allow any int in 255 range instead of having hardcoded hues also would be nice to have some way to mix two colors together with a given ratio |
We don't have hardcoded hues... I was referring to that we only allow 16 colors/hues. |
Yes, including computed variations.
Ok. You just gave one more reason to go to base9.
All it takes is to convince a few key members like you and the rest will follow 🙂 . I agree that brand reputation is a huge issue. A lot of people already know base16 and it a huge asset for base16. Another issue is ownership, I think a lot of people hate to say it (including myself), but we all like to have ownership over what we work on. Assuming you agree that the legacy problems are technically easier to solve by having a completely new design than patching existing specs.
|
base9 have hardcoded hues (or whatever are those modifiers, p125, p150, etc) - instead of being fixed they should just allow any integer value instead of 125 or 150 this will allow base16 to still have only 16 main colors, while will allow more color variations of them inside the templates |
Check back in a year... if Base16 is floundering around and hasn't really solved any of these problems or moved forward then we should talk... but that would certainly be a large disappointment to me. I have high hopes, and it seems we have a lot of interested/motivated people.
I don't think making a new project from scratch is the only way to get that... I feel like I have some degree of ownership here now (though the concept is always a bit nebulous)... but a year ago I didn't... first I decided to build Base16 themes into Highlight.js, then I built a template, then I hacked on a builder, then because it wasn't maintained I became maintainer, etc, etc, etc... and time goes by and now I'm involved in the reboot efforts.
I don't think the things I've proposed require breaking changes... legacy debt of existing schemes isn't the same as breaking changes... and moving to a new BaseXYZ format doesn't solve that problem anyways. Unless you consider just throwing them away a solution - and we don't need a new format to adopt that "solution".
I guess I don't agree? Esp when we haven't even tried solving them yet... we just started the discussion days ago. |
|
Fair, fair.
Fair, fair. My entire premiss depend on this. And the answer is not clear yet. I think I've pitched for base9 enough and don't want to keep this issue open for too long. I'll revisit this after a while and see where things are going. Thank you for indulging me. Closing the issue in a few days unless there are other comments. |
Awesome. Having a project that's "all your own" is a fun thing for sure.
Also awesome! I'd encourage you to perhaps pick your best idea (that we lack) and propose it as it's own discrete issue... or perhaps most compatible idea?... and see how that goes. :-) |
|
I would echo what @joshgoebel said - bringing up issues you see with base16 and proposing improvements would be a great place to start. One other possibility would be sharing common tooling - we could start building out some common tooling which could be shared (rather than maintaining a separate fork of builders, CI setups, etc). I've already got a PR out adding support for base24 to base16-builder-go - is there anything like that we could do to help support base9? |
|
Helps are great. One thing I really would like is to mention Base9 in base16 docs once Base9 reaches "1.0". The other thing is to make sure it's a MIT license, so I can copy code from base16 when I need to. I'm against supporting Base24 in base16 builder, unless we plan to officially support 24 colors as a part of base16. But that's a separate issue to discuss. |
|
@lijiaqigreat Since #51 we've pivoted a bit. It seems Base16 is Chris's baby and that he wants to keep it that way... so the organization is going broader/wider... we want to help develop alternative styles systems (so that the entire ecosystem can continue to grow) as well as more universal tooling. The end goal still being "all your favorite themes, in all your fav apps" or something like that. I'd like someone to be able to use node-builder to build:
Base24 is planning to move into our org, but it will still be Base24. Obviously base16 is not interested in moving into the org, but our build tooling can still support it as a discrete format. Base9 could live here (we'd be happy to have it), or in your own repo, but I'm more interested than ever in "what is base9" and how might it fit into the larger ecosystem.
First, there is no single "base16 builder" there are ~10 of them (including the two here)... and soon there will be no base16-builder-node... as it already supports both Base16, Base17 draft, and Base24 the I also thing long-term this thinking is backwards (and a bit controlling)... I think in a perfect world style systems would support builders, not builders supporting style systems... it flips the power dynamic. If you want to invent Base9, you write a style guide, your write a builder module that understands how to build your system - then that plugs into the larger ecosystem. IE, there would be no more "gatekeepers" of the builders. I don't know how to make that a reality yet, but that's the future I'd love to see. So if you'd like to rejoin the discussion as part of the bigger picture, we'd love to have you! |
|
I'm glad the vision is more clear now. Thank you for the invite. I'll probably move base9 once this universal tool reaches "1.0". But before that, I'll keep base9 independent. Reopening. Will close once comments settle down, since I think this org already has too many open topics and should benefit from a more focused discussion. |
|
Well perhaps I've misunderstood what Base9 is (and I've read a lot of it too)... if it's just about "build one scheme you like" I'm not sure how it fits exactly - though that doesn't mean you're not welcome. Most people building theming systems are hoping people will show up - make themes for them - and then you have a theme database (all built around your theming system). What I personally would like to see us do is help aggregate good style systems and good theme databases (when compatible)... so lets say you're looking for a terminal theme... you shouldn't be limited to just base16... you should be able to pick from a consolidated database of all the best: base16, base24, ansi16, iTerm2-Color-Schemes etc... Yep I thru a source in there that has nothing to do with baseX at all... but if someone is looking for an ANSI terminal theme - why not draw from the best sources out there? At the end of the day I think it's all about "all your favorite themes in all your favorite apps"... So if base9 has no theme database to share... I'm not 100% sure how it fits in that picture? Am I confused about base9? I'm assuming that 98% of users are consuming the final themes, not authoring them. |
That's because authoring theme is too hard, and base9 aims to make it so easy that average user can do it in a few minutes.
It is anti-goal for base9. I want to make it as easy (if not easier) to design a new theme than to pick from a list of existing themes. Although I do plan to have some database, so that the user can pick a starting point.
Because color theme is a matter of personal taste and users could prefer to design its own theme than picking from existing ones. I have finished implementing the user flow for vscode. I highly encourage you to try it and hopefully see what I mean:
Since base9 targets the end user rather than the theme developer, it prioritizes ease of use over the ability to customize.
|
Ah, then yes I did understand properly - you're doing something very different (and quite ambitious) indeed. :-) Another thing I'd like to work on long-term is interop (between style systems) but it also seems like currently that's probably a non-starter with base9 because there seems to be no easy way to map your 54 generated colors into 16, or 24... at least not unless we introduced a concept similar to your own How does That said personally I'm still super interested to see where you take the project. If you think of a way we could help, let us know. |
The
Yes
Yes. Here are a few things I can think of: (totally ok if the answer is no)
Sorry for keeping using base16, since we haven't decided on a new name yet. |
|
One small correction, there are currently (9-1)*6+1=49 colors in base9, as |
Well we aren't "base16" anymore.... and right now I'm not sure where we'd put you exactly, but I'm open to suggestions... right now we list all style systems we support as part of the larger ecosystem, but as already mentioned your kind of the odd duck in that regard as our tooling is kind of incompatible right now with what you're doing. I'm not sure if there is some other list we could add you to in the README... perhaps. If you see a spot, point it out.
Chris's base16 is MIT (again) and all our key stuff is MIT AFAIK.
I have enough on my plate personally, but if you meant our community - sure... hopefully you'll find some other people who are interested to help out.
You'd have to elaborate... If you mean implement It's hard when we have multiple builders... |
Based on current discussions, I think we have different goals and therefore should be two independent projects. (again assuming I correctly understood the goal of base16) As for how we fit together, I will explain in a few lines below.
I will send PR once base9 reaches "1.0".
I have not been keeping up with base16's discussions. So I don't know how exactly base9 could fit in. Hopefully there will be a section in the readme to explain base16's goal better once things settle down. Roughly, 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 Again, intentionally incorrectly using the word base16 to mean whatever this org is building, since there is no new name for it yet. #38 |
Of course! Thanks for sticking with me, now I can help. :-) I haven't given as much thought to interop as other things or I'd have realized this... we don't need to support you on the backend (templates) if you do the color mixing all yourself we could just support you on the front-end... you can "pretend" to be a regular old Base17 scheme (that's the only interop so far). And everything would "just work". Base17 is still draft but here's how you'd do it with node builder - just follow the instructions in the README, but first you need to generate a "cooked" base9 scheme... When I say a "cooked" base 9 scheme I mean you take your base9 colors, do all your magic and you split out a valid base17 scheme... at that point we're just building a base17 scheme, same as we would any other. And any templates that support base17, now they support base9 as well... |
I never even considered this, you should jump in on the semantic thread reading what we should support. #24 |
|
Closing. If/how to merge with base17 is not a concern in the short term. |
joshgoebel
changed the title
|
Merging was probably the wrong name all along, I've changed this to interop for future reference to reflect the later discussion points... |
forrestli74
changed the title
Given the stranded history of base16, I wrote my own version of base16: base9...
Some of the differences, I think, are fundamentally incompatible with base16.
Here is the about page:
https://base9-theme.github.io/about#how-its-different-from-base16
As proof of concept, I made a vscode extension
The main incompatible difference is that base9 mixes user specified colors to produce more colors for templates to use. This way, users need to specify less colors (16 to 9, or potentially even less in future versions), but templates can be more flexible and modern.
On one hand, I like the improvement I made, and some of the incompatible changes are probably never going to be a part of base16.
On the other hand, now that we have base16 rebooted and base9, splitting the effort would be wasteful.
I basically want to know what are your thoughts?
Do you come to base9?
Do I come to base16?
Do we happily coexist, and have a healthy competition?
If base16 continues to move forward, do you think the improvement I made is good to be ported back to base9?
The text was updated successfully, but these errors were encountered: