Support KDL for (de)serialization of color types

[Walther]

Description

Support for serde for (de)serialization of color types was requested here #83 and implemented here #90.

I'm opening this issue to ask if support for KDL (de)serialization would be a desired optional feature. The most likely path for implementation is the knus crate, which provides a serde-like derive macro experience.

Motivation

General motivation

KDL is a pretty neat format, with a high focus on readability and write-ability by humans. The document language specification has just reached 2.0 and "no further changes are expected". A bunch of projects both within and outside the Rust ecosystem are adopting KDL for configuration files and more. The palette library provides wonderful strongly typed colors, and it would be great to be able to leverage them in any KDL-based files that deal with colors.

Personal motivation

I have a path tracing rendering engine project, where I use palette heavily. Thank you so much for creating such an amazing library 🧡 It has helped me immensely with making my implementation easier, more correct, and even made me find some bugs in published research papers.

I am currently planning to move my scene files from being based on JSON to KDL. The scene files describe objects, their materials, and thus also colors.

I would like to attempt adding support KDL for palette, and wanted to open the issue to ask first if this would be okay. Being mindful of the call for co-maintainers, I understand that new feature requests might not be the highest priority.

[Ogeon]

Hi, thanks for the kind words and for posting this suggestion! I had a look at KDL and knus just now and tried to understand what it would take to implement it, and there are a few things to take into account:

• We have to decide on one format (likely properties).
• It has to handle PhantomData fields and preferably not accept them.
• Alpha requires special treatment, since it's a wrapper, and may need manual implementation. May be a case for flatten, if it works better than in serde.

Those points are probably solvable, but it would probably need a prototype. In addition to that, adding a dependency and feature has a maintenance cost.