Repository navigation
Update dependency com.github.skydoves:colorpicker-compose to v1.3.0 - #1039
Merged
Merged
Conversation
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
1.2.0→1.3.0Release Notes
skydoves/colorpicker-compose (com.github.skydoves:colorpicker-compose)
v1.3.0Compare Source
Upgrading
ColorPickerControllerno longer takes aCoroutineScope. The constructor parameter defaulted toGlobalScope, and the only thing the scope was used for was collecting the color flow, whichColorPickerlaunched withDispatchers.Main. On desktop that dispatcher only exists when something on the runtime classpath bringskotlinx-coroutines-swingalong, so a picker in a plain Compose Desktop window went down on a missing Main dispatcher the moment it composed. Pickers and sliders now collect on the composition's own scope throughrememberCoroutineScope(), which is the scope that was already the right answer.rememberColorPickerController()is unchanged, so most code needs nothing. A color change still arrives asynchronously; it is dispatched by the composition rather than posted toDispatchers.Main.Two behaviours changed in ways a test might notice. A tap on
ImageColorPickerthat lands beside a letterboxed palette, or on a pixel with an alpha of zero, now reports nothing at all instead of the nearest edge pixel. And a tap at a given x on a slider maps to a slightly different value than it used to, because the track now reserves the thumb radius at each end; the two ends are exactly0fand1f, and the midpoint is still0.5f.Added
onColorPickingFinishedonHsvColorPickerandImageColorPicker.onColorChangedfires for every step of a drag, so there was no way to tell a live preview apart from a finished choice, and analytics events piled up dozens deep per gesture. The new callback fires once, when a tap lands or a drag ends, carrying theColorEnvelopethe pick settled on. Same shape asonValueChangeFinishedon the Compose slider. (#142)orientationon every slider.AlphaSlider,BrightnessSlider,HueSliderandSaturationSlidertakeorientation: SliderOrientation,Horizontalby default. AVerticalslider fills the height it is given and runs bottom to top, the way a fader does, so theModifier.rotate(-90f)inside aclipToBounds+wrapContentSize(unbounded = true)box that the issue thread had been passing around is no longer needed. The gesture detector, the gradient shader and the thumb position all follow the orientation. (#15)onColorChangedonAlphaSlider,BrightnessSliderandSaturationSlider. OnlyColorPickercollectedcontroller.getColorFlow(), so a slider used without a picker beside it never reported anything to its caller. (#148):demo:desktopApp, and the wasm demo moved under:demo:wasmAppso every platform runs the sameMainScreen. The demo picks images through a multiplatform file picker now, which is what made a desktop image picker possible at all. Thanks @sproctor. (#182)commonTestcovers the color math, the geometry helpers and the controller;desktopTestcomposes the real components in a headless Skiko scene throughrunComposeUiTest, drives them with touch input, and reads pixels back out ofcaptureToImagefor the things that are only visible once drawn. Every fix below ships with a test that fails without it. CI runs them on every pull request, including one stacked on another.HueSliderandSaturationSlider, which both shipped in 1.2.0 with no page on the documentation site.Fixed
canvasSizesetter carried the selected point across a resize by scaling it, and on the very first assignment the previous size isSize.Zero, so0f * width / 0fproducedOffset(NaN, NaN). That is exactlyOffset.Unspecified, andOffset.getXthrows on it.setup()normally overwrote the point a moment later, butselectByCoordinatereturns early whileenabledis false, so withcontroller.enabled = falseset during composition the NaN survived intoCanvas.drawCircleand the app crashed on launch withIllegalStateException: Offset is unspecified. The setter now centers the point when there is no previous size to scale from. (#116)ImageColorPickerre-runscontroller.setup { }whenever the palette's identity changes, and a palette built inline in the composable, which is whatbitmap.asImageBitmap()in aLaunchedEffect-free body does, is a new instance on every recomposition.setup()then re-selected its initial position, so the indicator jumped to the middle of the image every time the selected color drove a recomposition. Only the firstsetup()moves the selection now; a later one keeps the point and re-resolves the color under it. (#115)initialColorkeeps its value and its alpha.HsvColorPickermapped the initial color to a hue and saturation coordinate and stopped there, and the palette color at a coordinate is alwaysColor.hsv(h, s, 1f).applyHSVFactorsonly consultsbrightnesswhen aBrightnessSlideris attached, so thevcomponent was dropped and every initial color came back at full brightness:Color(0xFF000080)displayed as0xFF0000FF, which is why the report was phrased as blue being forced toFF. It affected any color whose largest channel was below1f. The picker replays the whole color after setup now. (#123)selectByColorbefore the first layout is applied instead of dropped. Called from aLaunchedEffect(Unit), which is where a text field bound to a hex code naturally puts it, there was no canvas to map the color onto and no coordinate function installed yet, so the call silently did nothing and the picker then overwrote it with its own initial position. The controller holds the request and replays it as soon as a picker registers itself. The coordinate math for the colors in the original report,(0, 1, 1)and#​55aa00, was already correct after the multiplatform rewrite; this was the part that was still broken. (#52)wheelImageBitmaprepaints.ColorPickerhanded the bitmap to the controller exactly once, insideif (!initialized)on the first layout pass, so a caller rebuilding the wheel per frame to follow the selected color kept seeing the very first one.controller.wheelBitmapis snapshot state now and is kept in step with the parameter, so writing it invalidates the canvas.BrightnessSlidernever had the bug because it draws its wheel straight from the parameter. (#124)PaletteContentScale.FITleaves bands above and below, or beside, itself, and the picker used tocoerceIna point in one of those bands into the bitmap and report the nearest edge pixel, so tapping empty space handed back a color. Fully transparent pixels came back as a selection too. Both now leave the selection where it is. This is what the original Android-only version did through itsColor.Transparentguard, and restoring it resolves the transparent pixel TODO the multiplatform rewrite left behind. The pixel lookup also moved fromroundToInttofloor, so a canvas point names the pixel actually drawn under it rather than the one half a pixel over. (#69, #145)position * width, so at0fand1fhalf of it hung off the end and theRoundedCornerShapeclip cut it away, which is the half circle in the screenshot on the issue. The track reserves the thumb radius, or half the wheel bitmap's width, at each end now, and the tap and drag mapping uses the same travel so the value under the thumb is the value you get. (#77)controller.pureSelectedColor, which isColor.Transparentuntil something is selected. A slider used without a picker was therefore painted at alpha zero: the whole control was invisible except its thumb, which reads as the slider doing nothing. The shader supplies every color the track draws, so the paint no longer takes one from the controller.BrightnessSlideralso assumed full saturation when building its gradient and painted a black to red ramp where a controller with nothing selected should give black to white, which is exactly the greyscale case the request was about. (#148)isAttachedAlphaSliderand its two siblings were set totruefrom aSideEffectand never set back, so a slider hidden behind a switch kept its last value folded into every color the picker reported afterwards: with a brightness slider dragged to0.05and then hidden, tapping full red on the wheel still producedColor(0.047, 0, 0). The sliders report their lifecycle through aDisposableEffectnow, and the controller hands the component back to the palette color when the last one leaves. Thanks @Azerlag for the fix. The controller counts the sliders rather than flagging them, because a flag goes wrong as soon as two sliders of the same kind share a controller and the first one out clears it while the other is still on screen. (#195)AlphaTilebackgrounds are no longer rebuilt on every recomposition, and the slider no longer writes controller state from insidedrawIntoCanvas. The backgroundImageBitmaplived in a plain local that was null after any recomposition until the next remeasure, and theinitialColorbootstrap ran in the draw phase.HueSlider'sonColorChangeddocuments the range it actually reports. The KDoc said0f..360f; the callback has always been handed the position along the slider in0f..1f. The value is coerced now, so a drag past the end no longer reports above1f. The documented range was corrected rather than the value, because changing the number would break anyone who wrote against what shipped in 1.2.0.Changed
compileSdk 37. Spotless 8 brings a newer ktlint, which needs telling that a@Composableis named like a type.Docs
setPaletteContentScalewas replaced by a parameter onImageColorPickerat some point, and neither surface was updated, socontroller.setWheelRadius(40.dp)and friends were unresolved references. Thanks @iprashantpanwar. (#192)wheelRadius,wheelColorandwheelAlphaas parameters ofHsvColorPickerandImageColorPicker, which are controller properties, and left outdrawOnPosSelected,drawDefaultWheelIndicator,previewImagePainter,onStartandonFinishentirely.Full Changelog: skydoves/colorpicker-compose@1.2.0...1.3.0
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.