Closed Paril closed 8 months ago
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?
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.
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.
Fair enough
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 mainProcess
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)