Option to make Move event fire Change event for Flat mode

[jordandh]

When using the color picker in flat mode I usually want to have the value change as the user moves the selected color around.

In my example I hide the buttons and display the color picker in flat mode. When displayed this way the user expects changes to occur as they modify the color.

Can you add an option to update the input's value on move?

In the mean time I have implemented this by adding the updateOriginalInput method to the spect object. I then call the updateOriginalInput method whenever the move event is triggered.

[bgrins]

ccing @marcandre and @artificeren since we have been talking about similar things here.

So, this used to be available (as changeOnMove IIRC). It caused all sorts of problems with reverting and clicking out of the colorpicker (and made the code more complicated), so it was removed. There may be a way to carefully add functionality like this back in, but I'd like to know the use case.

I know this issue is opened wrt to flat pickers only, but I'd like to get a picture of the usage from everyone here (feel free to answer whatever you think is relevant):

• Are you using flat or normal picker?
• If normal, then what does clickoutFiresChange not do for you?
• Do you want the change event to fire so you can handle both moves and changes with the same function, or are you more concerned about the input's value updating?
• What is your desired behavior if a user clicks 'cancel' after moving around a bunch (and the input being updated)?

[artificeren]

Are you using flat or normal picker?
I'd switch to flat in a second if it was needed to support continuous updates.

If normal, then what does clickoutFiresChange not do for you?
In my scenario, I have a GM_Config (greasemonkey configuration plugin) modal popup in a userscript. This popup contains a couple color pickers and has its own save/apply and cancel/close buttons. With clickoutFiresChange set, if a user chooses a color, clicks in whitespace, and then clicks save, it all works. but if they go straight for the save button while the picker is open, the input is not updated before the save event. I'm not sure if it's a race condition with click events being trapped or something, but it's there, nonetheless.

Do you want the change event to fire so you can handle both moves and changes with the same function, or are you more concerned about the input's value updating?
certainly just about ensuring the input's value gets updated.

What is your desired behavior if a user clicks 'cancel' after moving around a bunch (and the input being updated)?
After briefly thinking about that, perhaps either "cancel" gets removed, or it gets renamed to "reset" and reverts to the value seen when the plugin was first initialized.

[artificeren]

Perhaps continuous update should just be the default whenever the cancel/choose buttons are hidden? Is that a problem somehow?

[marcandre]

Are you using flat or normal picker?

Normal picker

** If normal, then what does clickoutFiresChange not do for you? **

I think it's not directly related to the issue. We currently need to fire the change event when moving around, irrespective of if clicking outside cancels or validates the dialog.

** Do you want the change event to fire so you can handle both moves and changes with the same function, or are you more concerned about the input's value updating? **

I'd say both. Changes to our input are monitored to update other elements on the page. While we could use spectrums callbacks to do this, I feel it's much better if spectrum is decoupled. So we have spectrum's callback move manually fire a change event. Other listeners to change update the rest of the page. The fact that submitting the form at that point submits the updated colour is a small bonus. Note that we need to do more than this because the newer spectrum interferes with our alpha setting (#182), so we actually have to also "reset" the colour on every move callback.

** What is your desired behavior if a user clicks 'cancel' after moving around a bunch (and the input being updated)? **

Ideally for us, it would have the same effects of clicking on the original colour (in the palette or spectrum) and clicking Ok, i.e. fire a move and a change with the original colour.

Basically, ideally would be that any change to the colour swatch -> change event. I think we would not need to use any of spectrum's callbacks in that case, listening to change would be sufficient.

HTH