Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to change color programmatically #27

Merged
merged 10 commits into from Oct 24, 2022

Conversation

thadcodes
Copy link
Contributor

This should resolve issue #18, at least for the HarmonyColorPicker. It looks like the Classic one should already support programmatically updating itself.

@ffgiraldez
Copy link
Collaborator

Hi @thadcodes, sorry for the delay. I will look at those changes, but they look outstanding. Thanks.

Copy link
Collaborator

@riggaroo riggaroo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for the contribution towards fixing the programmatic color change!

Two requests:

  1. Can you do the brightness value change in a separate PR as its conflating the PR a bit.
  2. The API needs to return a Hsv Color so as not to lose those individual properties, for instance the color black can be represented in many different HsvColors: Right now on launch, the color black is broken with this change as it doesn't allow the picker to move around on the palette. Also its defaulting on launch to have the whole color wheel as black, where as before it was brightness = 1
    Thanks a lot!

harmonyMode: ColorHarmonyMode,
color: Color = Color.Red,
fixedBrightness: Float? = null,
onValueChanged: (Color) -> Unit
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't be changed to a Color at this point, the API should return a HsvColor otherwise color information is lost, as multiple HsvColors map to the same Color value. This will break for users who need individual color parts of information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. I did that because I wanted to make the input and value changed output match. So I'll create one where color: Color becomes hsvColor: HsvColor instead.

modifier = modifier,
harmonyMode = harmonyMode,
color = color,
onValueChanged = { HsvColor.from(it).let(onColorChanged) }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the other comment, this should be reverted as it'll lose specific color detail.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@riggaroo I believe I fixed this. Please let me know if that isn't the case

…matically and adds the ability to suppress the brightness bar with a fixed brightness value adjustment
@thadcodes thadcodes reopened this Sep 26, 2022
@thadcodes thadcodes changed the title Add the ability to change color programmatically and remove brightness bar with fixed brightness value Add the ability to change color programmatically Sep 26, 2022
@thadcodes
Copy link
Contributor Author

@riggaroo Updated based on your feedback. Will open the brightness bar PR as soon as this is merged

Copy link

@ffranco-godaddy ffranco-godaddy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minimum change for LGTM, great work thanks.

README.md Outdated
onColorChanged = { hsvColor ->
currentColor.value = hsvColor.toColor()
extraColors.value = hsvColor.getColors(colorHarmonyMode = harmonyMode.value)
onValueChanged = { color ->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We must keep both HarmonyColorPicker and HarmonyColorPicker the same naming, onValueChange or onColorChange. I don't have a strong opinion about which one to choose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little unclear, are you talking about the two HarmonyColorPicker functions or did you mean ClassicColorPickerScreen and HarmonyColorPicker needed to use the same naming?

If it's the two versions of HarmonyColorPicker I'll note the reason I changed from onColorChanged here to onValueChanged is because the passed in field name changed from color to value to keep the signatures for the Color old version and the new version that takes in HsvColor instead. I will note that the version with onColorChanged is deprecated with a replace with to make it easy to migrate to the new version for upgraders.

In case the issue is the inconsistency between classic and harmony I'm making a push that changes them to be consistent in the non-deprecated version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought I just updated it to use the old naming for both. I think the better distinction between deprecated and non-deprecated is useful because it can help prevent someone from using the old one by mistake. But I don't feel anywhere near strongly enough to leave it that way

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little unclear, are you talking about the two HarmonyColorPicker functions or did you mean ClassicColorPickerScreen and HarmonyColorPicker needed to use the same naming?

yes between ClassicColorPicker and HarmonyColorPicker a copy & paste error from my side sorry 😓

in this PR the non deprecated Composables are defined in this way

@Composable
fun ClassicColorPicker(
    modifier: Modifier = Modifier,
    hsvColor: HsvColor = HsvColor.from(Color.Red),
    showAlphaBar: Boolean = true,
    onColorChanged: (HsvColor) -> Unit
) {

@Composable
fun HarmonyColorPicker(
    modifier: Modifier = Modifier,
    harmonyMode: ColorHarmonyMode,
    value: HsvColor = HsvColor.from(Color.Red),
    onValueChanged: (HsvColor) -> Unit
) {
   

We should keep the parameter names in sync.

On second thought I just updated it to use the old naming for both. I think the better distinction between deprecated and non-deprecated is useful because it can help prevent someone from using the old one by mistake. But I don't feel anywhere near strongly enough to leave it that way

Agree with that please update ClassicColorPicker to match HarmonyColorPicker with value/onValueChange.

@thadcodes thadcodes requested review from riggaroo and ffgiraldez and removed request for riggaroo and ffgiraldez September 30, 2022 13:24
README.md Outdated
onColorChanged = { hsvColor ->
currentColor.value = hsvColor.toColor()
extraColors.value = hsvColor.getColors(colorHarmonyMode = harmonyMode.value)
onValueChanged = { color ->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little unclear, are you talking about the two HarmonyColorPicker functions or did you mean ClassicColorPickerScreen and HarmonyColorPicker needed to use the same naming?

yes between ClassicColorPicker and HarmonyColorPicker a copy & paste error from my side sorry 😓

in this PR the non deprecated Composables are defined in this way

@Composable
fun ClassicColorPicker(
    modifier: Modifier = Modifier,
    hsvColor: HsvColor = HsvColor.from(Color.Red),
    showAlphaBar: Boolean = true,
    onColorChanged: (HsvColor) -> Unit
) {

@Composable
fun HarmonyColorPicker(
    modifier: Modifier = Modifier,
    harmonyMode: ColorHarmonyMode,
    value: HsvColor = HsvColor.from(Color.Red),
    onValueChanged: (HsvColor) -> Unit
) {
   

We should keep the parameter names in sync.

On second thought I just updated it to use the old naming for both. I think the better distinction between deprecated and non-deprecated is useful because it can help prevent someone from using the old one by mistake. But I don't feel anywhere near strongly enough to leave it that way

Agree with that please update ClassicColorPicker to match HarmonyColorPicker with value/onValueChange.

}

/**
* Color Picker that programmatically updates.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] this comment does not add too much value from a user perspective, the opposite of the comments in ClassicColorPicker.

I suggest removing it(as it was previously) or updating it like the ClassicColorPicker

@thadcodes
Copy link
Contributor Author

Sorry @ffgiraldez I pushed my changes to the wrong branch that's why you are not seeing them, I'll have them up on the right branch.

I can see the argument on the Color Picker that programmatically updates. I actually wrote that when I was going to have two versions before just deprecating the old one. I am fine doing that as the comment should be in the deprecation warning now that they are not both correct versions

@thadcodes
Copy link
Contributor Author

ok @ffgiraldez updated, sorry about the wasted review cycle. 🤦‍♂️

@thadcodes thadcodes requested review from ffgiraldez and riggaroo and removed request for riggaroo and ffgiraldez September 30, 2022 14:33
@ffgiraldez
Copy link
Collaborator

You probably will punch me, but please, could you update the example in the README to match real param names?

@thadcodes
Copy link
Contributor Author

You probably will punch me, but please, could you update the example in the README to match real param names?

@ffgiraldez LOL no not at all, that's what I get for assuming IntelliJ would rename it here too and not checking. Fixed and pushed. Lucky you found that because I also had an error in the example that wasn't just renaming

@ffgiraldez
Copy link
Collaborator

@thadcodes LGTM now, I need to check why the signing is failing on CI😓

@ffgiraldez ffgiraldez requested review from ffranco-godaddy and removed request for ffranco-godaddy September 30, 2022 14:54
@@ -47,17 +72,16 @@ fun HarmonyColorPicker(
.fillMaxHeight()
.fillMaxWidth()
) {
val hsvColor = remember { mutableStateOf(HsvColor.from(color)) }
val updatedOnColorChanged by rememberUpdatedState(onColorChanged)
val color by rememberUpdatedState(color)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is shadowing the color parameter. Maybe rename to updatedColor?

@@ -65,7 +67,7 @@ fun HarmonyColorPickerScreen() {
harmonyMode = harmonyMode.value,
modifier = Modifier.defaultMinSize(minHeight = 300.dp, minWidth = 300.dp),
onColorChanged = { hsvColor ->
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to be compiling for desktop, is it working for you on desktop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the issue and have pushed it @riggaroo. Sorry I didn't notice the desktop runner at all 🤦‍♂️

Copy link
Collaborator

@riggaroo riggaroo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @thadcodes this is much better - its just not compiling on desktop, can you double check that it is for you?

… HarmonyColorPicker and fixed backwards compatibility case for the default value where it never updated the latest value
@riggaroo
Copy link
Collaborator

riggaroo commented Oct 9, 2022

@thadcodes Thanks - that is fixed! 🎉 One last request - can you update ClassicColorPickerScreen for the desktop build as that is using the deprecated version?

@thadcodes
Copy link
Contributor Author

@thadcodes Thanks - that is fixed! 🎉 One last request - can you update ClassicColorPickerScreen for the desktop build as that is using the deprecated version?
@riggaroo sorry for the delayed response. This latest update should address your concerns

Copy link
Collaborator

@riggaroo riggaroo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @thadcodes! LGTM

@ffgiraldez
Copy link
Collaborator

Waiting for #49 to merge this. Sorry for all of this @thadcodes

@ffgiraldez ffgiraldez merged commit b86ca4b into godaddy:main Oct 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants