[Feature Request] Native support for both mouse wheel and drag-to-scroll with inertia on desktop

[zhaoxue5]

(This issue was translated by AI — please excuse any awkward phrasing.)
Currently, RMLUI_BACKEND_SIMULATE_TOUCH converts all mouse events to touch events, which breaks normal desktop interactions like hover, clicks, and mouse wheel scrolling.
This forces a choice: either full mouse behavior, or touch-like drag scrolling with inertia — but not both.
Request: Please add a built-in way to use mouse wheel (for smooth scrolling) and left-click drag (for inertial/momentum scrolling) simultaneously on desktop, without breaking standard mouse interactions.
Use case: Desktop apps with scrollable content (settings panels, galleries, file browsers) increasingly expect both input methods to work together, just like modern web browsers and creative tools.

[mikke89]

Just for clarity, RMLUI_BACKEND_SIMULATE_TOUCH is only meant for testing, not for production usage. I believe touch screens should work on desktop together with a mouse, although I haven't really tested this setup.

Is the use case here that you want the mouse cursor to act like it was a touch screen on desktop? I don't think web browser come with this feature, I believe such creative tools you mention are normally scripted manually. Or is there some feature here I am not aware of?

If you want something like this, then I believe you should already be able to either (1) script a solution manually to allow dragging, or (2) simulate the touch events to the context manually in a modified backend. I think such a use case is better left implemented on the user side, rather than having something built-in to the library.

[zhaoxue5]

@mikke89 To clarify, my main use case is as follows: I want to implement a scrollable text box that needs to respond to both the mouse wheel for scrolling up/down, and left-click-and-drag for vertical movement. What would be the recommended way to implement this?

[mikke89]

You could use some custom logic for that, although it might be a bit tricky since it will interfere with text selection and dragging. But you should be able to do this from the user side: Detect that the user is interacting with a text field, and intercept the inputs accordingly. Scroll the text box manually instead. See e.g. WidgetTextInput::MoveToCursor for an example of how the text box is scrolled internally.

[zhaoxue5]

@mikke89 I already tried that earlier — it's a huge pain to implement. And even if we got it working here, it'd only solve one specific use case; native support is still way better. But I noticed something: if you map mouse click to ProcessTouchStart, mouse up to ProcessTouchEnd, and have mouse move trigger both ProcessTouchMove and ProcessMouseMove at the same time, it seems to work perfectly.

[zhaoxue5]

Would you be able to test whether this approach works? Then, could you implement a unified function that combines the functionality of ProcessTouchMove and ProcessMouseMove? (This is just my speculation.)