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

Option to make Move event fire Change event for Flat mode #173

Open
jordandh opened this issue Feb 4, 2014 · 4 comments
Open

Option to make Move event fire Change event for Flat mode #173

jordandh opened this issue Feb 4, 2014 · 4 comments

Comments

@jordandh
Copy link

jordandh commented Feb 4, 2014

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.

This was referenced Feb 19, 2014
@bgrins
Copy link
Owner

bgrins commented Feb 19, 2014

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
Copy link

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
Copy link

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

@marcandre
Copy link
Contributor

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

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

No branches or pull requests

4 participants