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

Add a pressed interaction and change clicked to fire on release #420

Closed

Conversation

tommyminds
Copy link

Based on the comment here I have changed the Clicked interaction to be set on an entity when you release the mouse button instead of when you press it. The interaction will be "cleaned" up in the next system update.

A new Pressed interaction is now available which is similar in behavior as the current Clicked interaction.

I believe this makes the hover/pressed/click interaction more in line with other UI systems.

@Moxinilian Moxinilian added C-Feature A new feature, making something new possible A-UI Graphical user interfaces, styles, layouts, and widgets labels Sep 2, 2020
@cart
Copy link
Member

cart commented Sep 2, 2020

At first glance I was like "this looks great lets merge it", but I do want to take a step back and think about this for a second.

By adding a "one-frame released" event, we now have time based state transitions. This feels a bit odd to me because all of the other states change solely based on user input. And some people won't care about the "released" event, but with the new api they have to handle the "released" state too, likely by treating it the same as the None or Hovered state. But when we're in the Released state, how do we know if we're None or Hovered?

Can we quick brainstorm some alternatives that resolve these "issues"?

@tommyminds
Copy link
Author

Good points!

Regarding the knowing if you are in None or Hovered state, the user should treat clicked as being in Hovered. You can only go from Hovered -> Pressed and from Pressed -> Clicked. The next frame it will go back to Hovered. Only if you move the cursor outside the bounding box of the node in the exact frame after you release the mouse button it will transition the Interaction to Clicked -> None but in that case I think it should not be a problem to think of the Clicked state as also meaning Hovered.

Regarding having to handle the Clicked interaction I think you make a valid point. Though currently you also have to handle the Hovered / Pressed state even though you might not always be interested in that either.

Besides these two issues, I agree it is a good idea to consider the impact of having time based transitions in general. An alternative could be to keep Interactions always be based on user inputs, and fire off events based on interactions like clicked, doubleclicked, pressed, hover, focus etc.

@tommyminds
Copy link
Author

Closing this PR as I don't think this is the right way to handle UI events/interactions. We should probably look to do something closer to #431

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-UI Graphical user interfaces, styles, layouts, and widgets C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants