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

Colour picker doesn't close on selection #2544

Closed
NeilFraser opened this issue Jun 5, 2019 · 6 comments
Closed

Colour picker doesn't close on selection #2544

NeilFraser opened this issue Jun 5, 2019 · 6 comments
Labels
component: fields help wanted External contributions actively solicited type: regression

Comments

@NeilFraser
Copy link
Contributor

Click on a colour picker.
Click on a colour.

Expect colour picker to close (like angle picker, or dropdown). Instead the picker remains open.

@BeksOmega
Copy link
Collaborator

I think the default behavior for editors that are rendered inside the DropDownDiv is that they stay open until the user clicks outside of them. So it seems like the angle picker may be the one with deviant behavior.

@NeilFraser
Copy link
Contributor Author

Until now, all widgets have closed immediately upon a selection. For reference:
https://3-dot-blockly-games.appspot.com/
(compiled from Blockly 'develop' on 19 Feb 2019)

Colour (movie), angle (bird), notes (music), dropdowns, context menus, and flyouts are all consistent in how they behave.

@BeksOmega
Copy link
Collaborator

I agree that this is how all widgets acted before, and I also agree that there should be consistency in this area. But I don't believe forcing the DropDownDiv to act like the WidgetDiv is the best way to create consistency.

Firstly, forcing the DropDownDiv to act like the WidgetDiv would not work for all types of editors. For example this turtle field works very well with the default DropDownDiv behavior, and wouldn't work at all with WidgetDiv behavior:

DropDownDiv_Turtle

Secondly, forcing the DropDownDiv to act like the WidgetDiv would /create/ inconsistency whenever a new field was created. Outside developers would have to spend time writing custom code to make it conform to Blockly's design, whereas if Blockly's DropDownDivs used the default behavior, outside developers wouldn't have to worry about this issue.

I believe that since the DropDownDiv has a very distinct look, it is reasonable to give those editors their own internally consistent behavior, and that it will not be confusing to users.

I think that the angle field could be easily changed so that you click and drag the selector, rather than having it activate on hover, which would make it easy to move to the default DropDownDiv behavior. Overrall it may be a small thing, but I believe it will make life easier for future developers.

(Ok I'll drop this now, but if you do decide to force the DropDownDiv to act like the WidgetDiv you may want to update the Date field as well)

@RoboErikG
Copy link
Contributor

For reference, the angle field still closes on click because Rachel added a click handler that hides the DropDownDiv

A few thoughts:

  • Defaulting to staying open seems like a better API. It's cleaner to add a dismiss call than to prevent one.
  • You have to modify a field for it to use the DropDownDiv, so it should be fine to use a different default.
  • Colour and Music pickers I don't have a strong opinion on their specific behavior. If we want to keep old behavior we could add a hide call like Angle picker has.

@NeilFraser , am I missing a reason to change the default behavior or do you just want the Colour field fixed?

@NeilFraser
Copy link
Contributor Author

I don't have any opinions on the default API. I just don't want a "click-happy" interface where simple picker widgets need to be clicked closed. Colour pickers and date pickers should close after a selection is made, just like dropdowns.

@NeilFraser
Copy link
Contributor Author

Fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: fields help wanted External contributions actively solicited type: regression
Projects
None yet
Development

No branches or pull requests

4 participants