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
Conversation
Hi @thadcodes, sorry for the delay. I will look at those changes, but they look outstanding. Thanks. |
There was a problem hiding this 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:
- Can you do the brightness value change in a separate PR as its conflating the PR a bit.
- 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@riggaroo Updated based on your feedback. Will open the brightness bar PR as soon as this is merged |
There was a problem hiding this 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 -> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
README.md
Outdated
onColorChanged = { hsvColor -> | ||
currentColor.value = hsvColor.toColor() | ||
extraColors.value = hsvColor.getColors(colorHarmonyMode = harmonyMode.value) | ||
onValueChanged = { color -> |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
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 |
ok @ffgiraldez updated, sorry about the wasted review cycle. 🤦♂️ |
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 |
@thadcodes LGTM now, I need to check why the signing is failing on CI😓 |
@@ -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) |
There was a problem hiding this comment.
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 -> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 🤦♂️
There was a problem hiding this 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
app/src/main/java/com/godaddy/android/colorpicker/ClassicColorPickerScreen.kt
Outdated
Show resolved
Hide resolved
@thadcodes Thanks - that is fixed! 🎉 One last request - can you update |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @thadcodes! LGTM
Waiting for #49 to merge this. Sorry for all of this @thadcodes |
This should resolve issue #18, at least for the HarmonyColorPicker. It looks like the Classic one should already support programmatically updating itself.