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

ProcessMouseButtonDown does not return consumption state unlike other event processing functions #570

Closed
Paril opened this issue Jan 14, 2024 · 4 comments
Labels
discussion Meta talk and feedback

Comments

@Paril
Copy link
Contributor

Paril commented Jan 14, 2024

I was hoping to add an override for right-click to act as the 'back button' - something that we did for other games (like Quake II). It seems that ProcessMouseButtonDown doesn't return the consumption state, though, and will instead always return false if the mouse is in an interactable state regardless of if the call performed any action. Conversely, all of the other main Process functions do return the consumption state (ProcessMouseWheel, etc).

The return value of the call is obtainable by simply calling IsMouseInteracting separately after the call, and I don't know in practice how many people use the return value as-is, but it would be a breaking change unless there's some other approach you can think of that I've missed? (not including attaching a click handler to every menu that I want to be backoutable)

@mikke89
Copy link
Owner

mikke89 commented Jan 15, 2024

This function can dispatch many different types of events, or none at all, so it's not obvious what we should return. The current behavior essentially tells you whether the mouse pointer is interacting with the UI, which in my view is just as valid as other approaches I can think of here. See the discussion in #124 for more background on the current behavior.

Have you considered attaching a capture phase event listener to the body or context?

@mikke89 mikke89 added the discussion Meta talk and feedback label Jan 15, 2024
@Paril
Copy link
Contributor Author

Paril commented Jan 16, 2024

Oh right I always forget about capture event listeners. The only piece of information I really need from the result is if there was actually an interaction from the output, it seems kind of a waste to re-do all of the "can I click this element" work in the event handler though.

@mikke89
Copy link
Owner

mikke89 commented Jan 16, 2024

Right, I wouldn't be worried about that from a performance standpoint. However, I understand it in the sense of avoiding code replication. But generally, I don't feel like making a behavioral change here is justified. And I don't think we could find an exact behavior that everyone would agree upon for their use case. Thus, for now, I believe this belongs in user land.

@Paril
Copy link
Contributor Author

Paril commented Jan 16, 2024

Fair enough

@Paril Paril closed this as completed Jan 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Meta talk and feedback
Projects
None yet
Development

No branches or pull requests

2 participants