Replies: 1 comment
-
A small change of plans. The traits and the default feature set will be released as they are for now. This is so the release isn't delayed for eternity. The other points are either in or on the way. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
For the sake of transparency and to not sit on all the plans, here are the main points I would like to do before making a version 0.7.0. It's also to make it easier if anyone would like to help out with moving it forward. I have been extra slow recently, but that's just because I have needed a break from programming on my free time. My energy for that comes and goes a bit.
I'll add anything I may have forgotten later, but these are pretty much the show stoppers for now.
Fixing up the traits
I have been refactoring and reworking the traits in the library to be more consistent and flexible. I'm also trying to remove default implementations (unless they are trivial and don't require any additional traits) in favor of blanket implementations where suitable. Or neither of them if not. This can break a lot of code so I want to get it all done in one release if possible.
The general pattern is like this:
self
and returnSelf
. It's up to the user to clone their values if needed.&mut self
.self
are named after their main action or capability and has a single purpose, as much as possible. For exampleLighten
has a methodlighten
and do only that.&mut self
have the same name as theirself
counterparts but with anAssign
suffix, and their methods have an_assign
suffix. This is modeled after thestd::ops
traits, such asAdd
andAddAssign
.WithSomething
for theself
trait andSetSometing
for the&mut self
trait. For exampleWithAlpha
can add transparency to an opaque color andSetAlpha
can modify it.An important goal, in addition to everything above, is that someone who want to use the trait in generics should only need a simple
T: DoThing
bound and not have to mention more ofDoThing
's dependencies than necessary.Getting
Okhsl
,Okhsv
andOkhwb
inThey are currently sitting in #282 and need some fleshing out and brushing up before being merged. Not much to say, other than that I think it would be great to add them to the release.
Removing or deprecating
Gradient
As discussed in #218, I would like to remove the gradient. It's pretty bad and adds to the maintenance burden. I'm also leaning more towards removing the named gradients too, instead of keeping the data. It makes more sense for an external crate to have them and many more.
The gradient is however quite popular so I may just deprecate it for this release.
Reducing the default feature set
Related to #286, I would like to make it less necessary to add
default-features = false
. The ideal would be if it can be reduced to only containstd
.Beta Was this translation helpful? Give feedback.
All reactions