search

rydmike / flex_color_picker

A highly customizable Flutter color picker.
BSD 3-Clause "New" or "Revised" License
200 stars 42 forks source link

Exposing onColorChangeStart and onColorChangeEnd for Sliders #9

Closed osaxma closed 3 years ago

osaxma commented 3 years ago

I was wondering if it's possible to expose these two callbacks for the color sliders in a similar manner to the Slider Widget.

An example use case is when the application is keeping track of operations history (undo/redo). With a Slider widget, registering every change can be avoided by doing the following:

Slider(
  onChangeStart: (_) {
    controller.trackChanges = false;
  },
  onChange: (value) {
    controller.updateData(value);
  },
  onChangeEnd: (value) {
    controller.trackChanges = true;
    controller.updateData(value);
  },
)

So it'd be nice to have these two callbacks exposed.

osaxma commented 3 years ago

By the way, since I'm using the dialog picker, my work around is to stop tracking changes before showing the dialog and resume tracking changes after the dialog is dismissed. So I'm not even tracking changes for anything until select is pressed.

Though, if the colorPicker isn't shown as a dialog but as a part of the same screen, it'd be difficult to stop tracking every changes, specifically for the slider/wheel.

rydmike commented 3 years ago

Thanks for the suggestion @osaxma.

Yes I was about to mention too that if you use it in the dialog you can do like the Web example already does, store the start color value, return it if user closed the dialog with cancel or barrier click and then only keep it if OK/SELECT was chosen, and then track the change, just like you said already in 2nd comment.

If using it outside a dialog, yes indeed a solution like you mention would be nice in order to not track hundreds of changes on the wheel control. The other pickers are just one click, so they don't really start and end, but then again, while there might be tens of them while users play around with color selections, it is not hundreds, like for the wheel (its wheel slider and surface thumb tracker) so for it it would be very useful.

Right now you would have to implement "a use selected color confirmation" button to avoid all that tracking from happening and that is not nice UX.

I will try to get this into the next release I'm working on now. It will be added to null-safe version. Depending on when null-safety goes main stream, I might or might not back port some of the new features I'm adding now to it as well, but leaning more and more towards not adding new features to the none null-safe version, unless they are really critical for someone that won't be able to move the null-safe version yet.

With Web and desktop becoming more mainstream, it is more plausible that the color picker would be used in a none dialog use case, so this would be a good feature to have. It is also useful in full screen dialogs on mobile, where you might just have back option and no cancel.

Off topic

Bunch of new features coming to the null-safe version. Taking the opportunity to add features since it is anyway a new major release. Trying to keep breaking change to a minimum though, other than what null safety entails. Still there will be some minor ones.

What's in the works

Adding your onChangeStart onChangeEnd event suggestions now as well to the above list.

Later I'm also planning to add

Other

osaxma commented 3 years ago

Thank you @rydmike for the detailed response and the information about what's coming up.

Opacity slider & entry support for color values is coming as well.

I believe this feature is great to have.

OK/Cancel as buttons in a dialog top toolbar instead of bottom CANCEL / OK.

What's the motive for this change? (I actually don't have a preference here, just curious).

p.s. I appreciate your work and I'm enjoying using the package -- it's simple to use, easy to customize and has excellent documentation. I'll look forward for the coming updates.

rydmike commented 3 years ago

Regarding ok / cancel icon buttons in a toolbar, it is just an another option, use it as an alternative or use the current version, can even use both, if so desired.

The onColorChangeStart and onColorChangeEnd are btw working well already in my dev version. I like the feature.

Some new gesture detection improvements in Flutter also enabled me to improve the color wheel gesture handlers so it reacts better than before on taps and drags.

Noticed the ways to improve them while adding the start and end callbacks, so got a double benefit from looking into it.

rydmike commented 3 years ago

This feature is now available starting from the pre-release ^2.0.0-nullsafety.1 https://pub.dev/packages/flex_color_picker/versions/2.0.0-nullsafety.2/changelog

You can try and play with the features in the latest web demo as well: https://rydmike.com/flexcolorpicker The web demo source code is available in the latest package release as well.

These features are still new and still in pre-release status. I expect to migrate 2.0.0 over to stable channel soon after the dust settles from Flutter Engage.

Let me know if you notice anything that needs further tweaking.

Closing this feature request as it is now implemented. 😃