Drag scrolling implementation.

[dkosmari]

This adds built-in support for drag scrolling interaction, using the io.ConfigDragScroll flag.
It's meant to be used with the io.ConfigWindowsMoveFromTitleBarOnly flag.

The context has a new flag, DragAction, set by some widget code when they use mouse drag interaction, such as sliders, scrollbars, color picker, etc. This flag is used in the HandleDragScroll() function to ignore any scrolling in this situation.

Some widgets are forced to use PressedOnClickRelease because a single press or single release would cause false activation during a drag scroll action.

[ocornut]

Why not reusing the existing mouse wheeling infrastructure?

Some widgets are forced to use PressedOnClickRelease because a single press or single release would cause false activation during a drag scroll action.

This is going to break many things and should be avoided. Have you ran the imgui_test_suite with your changes and your flag enabled?

[dkosmari]

I'm not sure how you'd use the wheeling code to implement kinetic scrolling.

No, I have not tested the test suite with the flag enabled. Do you have drag scrolling tests, or are you expecting the drag scrolling code to handle interactions not meant for drag scrolling?

[ocornut]

There are no tests specific to drag scrolling but it would likely catch issues related to the change of button behavior on other widgets.

[dkosmari]

Changing button behavior is inevitable for touchscreen interaction. No GUI compatible with touchscreens will activate buttons or menus on just button-down or button-up events. They all wait for a full "down, don't move, up" cycle, save for a few exceptions. Otherwise you would never be able to scroll through a menu, without activating items the instant you touch it to drag.

For the few widgets that could not simply be patched to change the click interaction (like text inputs), I just disabled the drag scroll entirely. I do not think it's possible nor even desirable to make every widget compatible with touch screen interactions, since some interactions are optimized for one type of input device.

The application can also disable the drag scroll flag at any point during the frame, since all the logic happens at the end. So a developer can both avoid widgets that are not good experience for touchscreens (such as multi-level menus), or switch the drag scroll off for specific purposes.