Hi Lukas,

Thank you for the PR.

It seems the PR removed the color trait and replace it with the crate completely. I have a few concern about it.

First, one of the reason for having built-in color representation is I want to keep a minimal required dependency. Although it's not important for most of the case, but if you are creating a WASM application, this might be a matter.

Second, after the removal of Plotters' color layer, Plotters is now directly coupled with Palette crate, and I have some concern about this. Since one of the guideline for creating this crate is make the core Plotter code as small as possible and easy to extend. (P.S. You can see both font and color implementation can be replaced easily. And I am currently looking for a replacement for current font implementation, because the crate isn't in good quality and causing memory leak.) This is why those "unnecessary" trait exist in the code base. But removing that Plotters will lose the flexibility on color representation.

Third, One of the plan in the future is make the color description also supports gradient. Or allows the actual color determined by it's value etc. This is another reason a color abstraction is needed in the crate, but removing the trait makes it harder to extend the crate supports that. a color descriptor might be extend to some texture descriptor in the future, but the guideline is do not block any future extensions.

Finally, this is a breaking change which may cause problems. I know the existing color system isn't good and needs a lot improvement but making a huge change without backward compatibility doesn't seem ideal.

The reason why I keep use reference to pass color descriptors, since it may become a huge data structure and needs to pass by ref. As I previously mentioned, the color descriptor may extend to texture, gradient, hot map, etc ....

I think it's great is the underlying color data is using this crate since it's much better implemented than the builtin impls. It should be as easy as make change inside the color.rs file. Again, I do really want to have such a well maintained color crate used in Plotters.

What I am concerning is the PR is getting rid of possibility for future extension and introducing breaking change.

I am open to discussion, please let me know if you don't think what I said make sense.

Thanks you !

Ah yes, I get your points regarding this. So if I get this right a plan for now would be to just allow palette colors to interface with the Color trait and probably even feature gate it(being a default feature or not would be question then as well)? This would allow it to have minimal dependencies as well since its opt-in(or opt-out). Or is there anything else I missed from your write up that can be done without much discussion/thinking about for now?

While making this PR I already expected serveral discussion points since I made drastic changes here and there, partially due to experimentation as well, which is why I didnt ask a lot in the issue itself.

That sounds good. I like the idea making the palette crate default implementation of color while people want to minimize the code size can use the builtin version (which enabled if the crate is opt-out)

And I think it's nice to have palette crate behind the color interfaces. And I am open to replace RGBColor, HSLColor ... with the crate while default implementation is used. It seems really awesome.

To clearify what I don't want to merge into Plotters is:

• Huge breaking change (maybe some minor breaking change is fine)
• Removal of color abstraction layer

Besides that I really like the idea. I should have more discussion with you before you start working on it. If you have any idea, please let me know. Also, any ideas on the color abstraction layer itself is welcome. I am open to change (but not remove) it as well.

Thanks again, really appreciate for your help!

Alright, I'll think some more about it tomorrow and get back to you then. 👍

Okay so I'm just gonna try to integrate the palette structures into this crates color system through its traits for now so you can easily use the palette colors instead. This should make it a smaller PR which should also be easier to reason about. Basically implementing the conversion from palette colors to the internal ones.

The only breaking change I might consider is to change the color structs defined here
https://github.com/38/plotters/blob/40e35e1bb0d5ae4e02a4fbb4b8b4211fc90d1e0d/src/style/color.rs#L96-L129

to be just all RGBAColors contain its actual color values making it possible to declare all these special colors as constants instead. Reason for that would be to allow to replace those definitions with palette colors if the palette feature is enabled. One downside to this is that this would mean the API of the special color constants changes depending on whether the feature is enabled or not which seems rather fishy.

So what I would ideally propose is to still allow me to make the breaking change as to change those colors all to constants but expose the same special colors implemented as palette colors in a different module so people can explicitly choose those colors instead when they use the feature. then switching is as easy as changing the module import while not having the a feature change create unexpected problems.

On that Note, I would also propose to remove the SimpleColor trait and change the Color traits alpha function to have a default implementation that returns 1.0 cause it's currently not being used at all and I don't see a reason as to why one would use it. Though this is just a small side note, you will definitely know better than me whether this trait has a purpose or not in the future.

Hi,

Thank you for the detailed proposal. I really like it. Please see the comment inline below.

Really appreciated for your help.

Thanks,

Okay so I'm just gonna try to integrate the palette structures into this crates color system through its traits for now so you can easily use the palette colors instead. This should make it a smaller PR which should also be easier to reason about. Basically implementing the conversion from palette colors to the internal ones.

This sounds really good, and should have less work needs to do as well.

to be just all RGBAColors contain its actual color values making it possible to declare all these special colors as constants instead. Reason for that would be to allow to replace those definitions with palette colors if the palette feature is enabled. One downside to this is that this would mean the API of the special color constants changes depending on whether the feature is enabled or not which seems rather fishy.

And if this is the case, could we just keep the predefined colors as what it is. I understand if the predefined color is using the platte crate, then we need to change everything to constant. But if we just keep this definition, that won't causing any compatibility issue, right ?

Ah, I see if a compatible module will be introduced, I think it's Ok to do that.

So what I would ideally propose is to still allow me to make the breaking change as to change those colors all to constants but expose the same special colors implemented as palette colors in a different module so people can explicitly choose those colors instead when they use the feature. then switching is as easy as changing the module import while not having the a feature change create unexpected problems.

That sound good, as long as the API doesn't change, the only difference is importing another module.
We are also able to import it into prelude module and this could make the breakage minor.

On that Note, I would also propose to remove the SimpleColor trait and change the Color traits alpha function to have a default implementation that returns 1.0 cause it's currently not being used at all and I don't see a reason as to why one would use it. Though this is just a small side note, you will definitely know better than me whether this trait has a purpose or not in the future.

And for this one, the alpha function is used when you make a color and adjust it's alpha value. So remove that would cause other part break.

Okay, so to summarize what this PR does(I pushed before your comment already which is assume you already saw):

We have this module which implements the Color traits for all of the palette colors
and we have this new module which defines all the predefined colors.

The only breakage here now is that all the predefined colors are constants instead of structs which also changes the character cases of them(this is what makes the PR so chaotic since it replaces all the predefined color uses with the new constant names).

In the lib.rs file we then reexport the palette crate. Whether this is really needed or not is preference since it has advantages and disadvantages. Advantage being that if for some reason the end user has multiple versions of palette(which shouldnt happen since this is not a crate that is being used often by other crates) he can easily use the exact version needed through the reexport in their code. Disadvantage being upgrading palette could incur a version bump for plotters since the palette api might change itself, but i believe this would be needed even if we were to not reexport it.

The wasm sample seems to compile but i cant run it properly cause wasm-bindgen fails for me due to

thread 'main' panicked at 'remaining data [23]', C:\Users\Lukas\.cargo\registry\src\github.com-1ecc6299db9ec823\wasm-bindgen-cli-support-0.2.49\src\descriptor.rs:107:9 .

This panic happens with the palette_ext feature as well as without it though.

The wasm sample seems to compile but i cant run it properly cause wasm-bindgen fails for me due to

thread 'main' panicked at 'remaining data [23]', C:\Users\Lukas\.cargo\registry\src\github.com-1ecc6299db9ec823\wasm-bindgen-cli-support-0.2.49\src\descriptor.rs:107:9 .

This panic happens with the palette_ext feature as well as without it though.

I have tried this and seen the similar error message. When I try to update my wasm-bindgen-cli, the error seems gone.

Unfortunately I am on the most recent version so updating isnt an option for me to fix this.

Unfortunately I am on the most recent version so updating isnt an option for me to fix this.

It's panic in the wasm-bindgen itself. My guess this is either due to compiler version or the OS ...
If you don't want to dig into that, I can find a chance to try it on Windows and fix it.

But I think I tried it works on my Linux machine. So I guess it's ready to merge, or you want to dig into that. It's up to you :)

Nah, its probably OS specific then and I havent really dug into wasm stuff myself anyways. I'd say it's ready to merge then if it works for you on linux.

Alright, I am merging the PR. Thank you for this amazing work!