Tracking Issue for `v0.9`

[ripytide]

This is a tracking issue for work on v0.9.

[ripytide]

Okay, I've finished trawling through every issue both closed and open in the issue tracker and itemizing the actionable improvements I agree with in the tracking list above. Some improvements didn't yet have their own issues (particularly many of the points brought up in #39) so I opened some new ones for them. There were also some new improvements I came with, such as #65 and #66, not previously discussed as far as I am aware.

What do you think @kornelski? Specifically it would be useful to me if you'd state which of the listed improvements you'd accept or reject so I don't have to spend time implementing things you'd reject.

[kornelski]

Approvals

• [x] #63
• [x] #14
• [x] #21
• [x] #25
• [ ] #46
• [x] #65
• [x] #66
• [x] #67
• [x] #68
• [x] #69
• [x] #70
• [x] #72
• [x] #73

[ripytide]

I've decided that I'll be shifting my focus from working on a 0.9 of this crate to creating a new crate due to the decision that this crate will not making any semver-trick incompatible changes. See #83 and #84 for more discussion on this issue.

I'll leave this tracking issue open in case anyone else wants to pickup where I left off.

[ripytide]

After more discussion in #85 I am now happy to continue development on v0.9, I did make a crate called pixeli but I'll deprecate that now for this crate.

[kornelski]

Great. Thanks.

[kornelski]

• [x] Bring back fn new() for sensible-order RGB types. The type literal requires a lot of shift-pressing. Maybe fn new_bgr(b,g,r) too?
• [ ] Aliases for RGB8/RGB16. Type hints are repetitive, and other forms require turbofish.
• [ ] Convenience methods for bytemuck? slice.as_rgba() vs bytemuck::cast_slice::<Rgba<u8>>(slice).
• [ ] Add prelude::*? There's a bunch of traits.