You may want to ditch using the ScrollBox for this purpose, it’s really there for the simple usecases, with this many interconnected concerns you may need a widget with more knowledge. You probably want to take the Tile/ListView wrapper which is marked as experimental, and make your own version based on that. It has much better support for handling the kinds of cases you’re going to need to care about. For example, do you always want to insert at the end of the list? Or do you want the ability to determine the zone, so that you can insert between two items?
Up to you though - you may want to just make a brand new scrolling panel that does exactly what you want if you can’t bend them to your will - let me know though, I’d love to improve these controls so their better suited for mobile out of the box of possible.
But I think there’s a way you can make the scrollbox work, will take some improvements to the scrollbox, and maybe a new API to slate/widgets:
Scrolling + Dragging based on direction is going to be tricky. Thinking about it, my gut says there needs to be a new flag when capturing the ‘mouse’.
The first problem is, the item HAS to capture the mouse. There’s no way around it. Not capturing the mouse on the item, opens up a whole host of frustrations from users feeling like they Dragged A, but instead B gets dragged, because your finger drifted onto another item during the swipe, or left before drag was detected.
The issue that opens up, is that now because the item captured the mouse, the scrollbox can’t scroll. Not only that, if the item says, nope, not a drag, nevermind, it’s now too late for the scrollbox to function the way it normally would, and begin scrolling. But it could be patched to correctly deal with the case.
The flow (in my head) would basically run like this,
Item gets mouse down - Captures mouse
Item gets movement - monitors for directional, are they dragging up and out?
A) Item Detects intent to drag, issues DetectDrag, waits for DragDetection callback. Stops looking for intent.
B) Item fails to identify intent, and releases mouse capture.
IF B) Scrollbox, suddenly starts seeing mouse movement data, BUT it does not have mouse capture, and it never received a mouse down. This is the critical bit - what should be the behavior of the scrollbox? Because normally you don’t want a scrollbox to start moving just because someone pressed the mouse down outside of it, and then dragged into it, that would be terrible.
My gut says there needs to be a way parents of mouse capturing widgets need to some how remain notified of events occurring over them, but not through some path they would mistaken as being something they could handle.
You might be able to get PreviewMouseButtonDown, to assist in this area, as it could be used on a scrollbox to know when there’s intent to press coming, but if I remember correctly, there’s no way of accurately knowing when the capturing widget releases capture. There almost needs to be an event like, ChildWidgetCaptureBegin/ChildWidgetCaptureEnd, so you’re in the know when they release it, and can then pick it up, in the case of the scrollbox.
I don’t believe we simulate a mouse enter/leave on touch devices, so I don’t think you’d be able to rely on that.