kornelski / rust-rgb

struct RGB for sharing pixels between crates
https://lib.rs/rgb
MIT License
97 stars 19 forks source link

Rollup of a few PRs #102

Closed ripytide closed 2 months ago

ripytide commented 2 months ago

Combination of PRs: #98, #99, #100 and this one.

98

Adds a lot more flexibility to the GainAlpha and LoseAlpha.

The coolest part of this for me was changing the bound on the associated type of GainAlpha from type GainAlpha: HetPixel; to type GainAlpha: HasAlpha, that felt so cool and will actually be useful in generic functions for using methods from HasAlpha after calling a method on an impl GainAlpha type!

99

Conversions between Luma <-> Gray and GrayA <-> LumaA are also provided as well as all the other implementations for all the other pixels as normal.

It's a bit annoying how when introducing the legacy feature we'll also have to annotate lots of the various implementations macros for Gray and GrayA will have to be annotated with #[cfg(feature = "legacy")] but I think that's probably the best way.

100

This adds back all the legacy functionality excluding the traits which can be left in v0.8 due to the orphan rules.

It passes cargo-semver-checks:


❯ cargo semver-checks --release-type minor --all-features
Parsing rgb v0.9.0 (current)
Parsed [   0.830s] (current)
Parsing rgb v0.8.37 (baseline, cached)
Parsed [   0.069s] (baseline)
Checking rgb v0.8.37 -> v0.9.0 (assume minor change)
Checked [   0.012s] 69 checks; 68 passed, 1 failed, 6 unnecessary

--- failure trait_missing: pub trait removed or renamed ---

Description: A publicly-visible trait cannot be imported by its prior path. A pub use may have been removed, or the trait itself may have been renamed or removed entirely. ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.32.0/src/lints/trait_missing.ron

Failed in: trait rgb::ComponentSlice, previously in file /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rgb-0.8.37/src/internal/pixel.rs:3 trait rgb::AsPixels, previously in file /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rgb-0.8.37/src/internal/convert/mod.rs:15 trait rgb::ComponentBytes, previously in file /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rgb-0.8.37/src/internal/pixel.rs:37 trait rgb::FromSlice, previously in file /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rgb-0.8.37/src/internal/convert/mod.rs:69 trait rgb::ComponentMap, previously in file /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rgb-0.8.37/src/internal/pixel.rs:70 trait rgb::ColorComponentMap, previously in file /home/ripytide/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rgb-0.8.37/src/internal/pixel.rs:79 Summary semver requires new major version: 1 major and 0 minor checks failed Finished [ 0.925s] rgb



## This PR

This makes the `Gray` and `GrayAlpha` types only compile with the `legacy` feature so that now everything not wanted for `1.0` is now only compiled with `legacy` and everything on by default is wanted.
ripytide commented 2 months ago

I've closed the other PRs for this one so I don't have to keep re-basing them :smile:

kornelski commented 2 months ago

https://octodon.social/@rust/112649024087585199

kornelski commented 2 months ago

Gray.v for value is not terrible…

ripytide commented 2 months ago

Luma.l seems to have won the poll, but I dislike that a lot due to Luma vs Luminosity which may not have been an obvious discrepancy to a lot of people taking the poll.

I am just as happy with Gray.v as I am with Gray.l so if you prefer Gray.v (and it just about came 2nd in the poll whereas no-one seems to like Gray.l) then shall we go with Gray.v as a final final final decision?

I can't wait to not ever have to think about naming consistency of pixel types ever again :laughing:

ripytide commented 2 months ago

Do you have any other concerns other than the pixel naming on this PR? If not could we merge this one and change the Luma naming in a future PR? I have some more changes (adding doc-tests, and various other minor tweaks) I'd like to make but don't want to add them to this PR in fear of making it too large and so making it harder to review.