mikke89 / RmlUi

RmlUi - The HTML/CSS User Interface library evolved
https://mikke89.github.io/RmlUiDoc/
MIT License
2.77k stars 304 forks source link

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

Closed Paril closed 8 months ago

Paril commented 8 months ago

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 commented 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?

Paril commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

Fair enough