Open thatcomputerguy0101 opened 4 months ago
Hmm. Yeah, it's the usual conversion problem (exactly the same issue with the math library, people use different libraries and have to convert from one type to another). Probably I shouldn't have introduced yet another color type, but I think I wouldn't choose ecolor
, it's a bit too tied to egui. Maybe palette
crate or something? Implementing color conversions means that I have to do a feature with the ecolor
dependency only for that. Seems like a bit too much. Using raw array of colors is also an option, but I think it's nice with some kind of color implementation.
Instead of implementing a custom
Srgba
type, compatibility with theegui color picker
(and possibly others) would be increased if theColor32
type from the ecolor crate is used instead. This would be a breaking change for all places where the currentSrgba
type is created/accessed, so an alternative solution would be to add conversion traits to/fromColor32
. A workaround for my own needs is to use the array form as an intermediary, since both sides support converting to/from arrays. I think it would be better to entirely remove the existing color type since that also gives easy access to all ofColor32
's constructors, but also understand if making that switch is undesired. I'd be willing to help implement either of the two solutions.