Make more methods public

[dvkch]

Hi there,

Would it be possible to make more components public, or add public extension methods, mainly to obtain the HSLuv components of a UIColor/NSColor object ?

Thanks for considering

[boronine]

Fellow contributors - @robotive @stphnclysmth @jaywardell @nickswalker - could you offer advice?

I looked at this repo again after receiving a PR with more initializers: https://github.com/hsluv/hsluv-swift/pull/17 (cc @jaywardell)

Why are we monkey-patching platform APIs (UIColor, NSColor) instead of exposing our conversion functions? Is this idiomatic Swift? I am tempted to get rid of all platform code and make this library pure and buildable on Linux / Windows and not dependent on XCode or Apple.

Instead of monkey-patched initializers we can just offer instructions in the README like this:

import HSLuvSwift

let rgb = hsluvToRgb(hue, saturation, lightness)
let color = UIColor(red: rgb.R, green: rgb.G, blue: rgb.B, alpha: 1.0)

Thoughts?

[jaywardell]

From my perspective, making the conversion functions public would work just as well as my additions. Of course, it’s easy enough to do both: make the functions public AND offer conditionally compiled extensions on platform-specific types.

[jaywardell]

If you wanted to expose the conversion functions, I could make a separate package that imports hsluv-swift and offers the platform-dependent initializers. It would mean removing functionality from the original framework, but it would be easy enough to point folks to the second package.

We could separate functionality between:
hsluv-swift: core functionality
hsluv-UI: platform-dependent initializers

When I was doing the SwiftUI initializers, it occurred to me that there could be a more idiomatic SwiftUI way to do things (eg using the Angle type) if I weren’t trying to maintain consistency with the other initializers. If the packages were split, that would be simpler to do.

lmk

[boronine]

@jaywardell

could make a separate package

We should definitely avoid that.

I just fixed the build (https://github.com/hsluv/hsluv-swift/actions), I'm thinking this roadmap:

2.1.0 - current version
2.1.1 - maybe @jaywardell's initializers (can we test them on GitHub Actions?)
3.0.0 - Adding support: Linux (with exposed public APIs), Dropping dependencies: XCode, iOS, macOS, cocoapods, carthage

[boronine]

I published the cross-platform swift version here: https://github.com/hsluv/hsluv-swift/

This repo has been renamed to hsluv-apple. I won't be able to maintain it because I struggle automating Xcode tests.