Closed facelessuser closed 2 years ago
This will be handled in the next major release. Moving forward, the idea is that brand new color spaces should first be added to the default, base color class. This ensures some core features will work with new color spaces. Generally, new color spaces will be stripped down and must support the color(id ...)
CSS format. Custom color classes can subclass added color spaces to provide unique formats for specific file types. This should resolve the last big issue I was aware of.
The last thing that needs to be done though is to ensure that color palettes gracefully handle unexpected colors. Maybe show them in a generic way allowing the user to delete them.
An issue has been created for the palette to handle unknown colors. In most cases, this should not occur, so no need to rush to implement it until after 5.0 release. Ref #222.
Currently, ColorHelper allows for custom color spaces. So far, these are only implemented to provide custom formatting for existing color spaces. If an actual new color space is added, it is likely that some features will break as they are not aware of them. For instance, if you favorite a color, the default color object will not recognize it.
The solution is that we need to be able to define what color spaces exist in the default color object. I'm not sure yet how complicated this will be, but generally, anytime we reference the default color object, it should be acquired in such a way that we can ensure that a user-defined default is pulled in.
I'm working to get closer and closer to a 1.0 release of the underlying coloraide library used to handle all the different color spaces. It is likely that moving forward that the default Color object will not include all color spaces by default. We even have a separate package with a bunch more random color spaces we've implemented: https://facelessuser.github.io/coloraide-extras/colors/. This would allow for a lighter-weight object and allow users to cherry-pick the ones they absolutely need for their task. Not all users of ColorHelper need every color space ever conceived at their fingertips at all times. If it isn't needed we shouldn't bother loading them by default.
This is probably the last big step to enable almost any color space that people could want. There will likely always be some outliers though that will be difficult to implement, and I won't bother going into details here, but this should cover most exotic color spaces that don't require a great amount of context related to the environment in which the color is being viewed.