Ideas on how to implement drawer style widget

Development Programming & Scripting C++
1

Hey guys,
I wonder if any of you have suggestions on how to possibly implement a swipeable drawer widget (or in other words: scrollable panel widget) that can have input consuming children (Buttons, Listviews, Scrollboxes, etc) whilst being able to have it’s own input for swiping it up and smoothly blending from Widget A to Widget B.

Like the typical app drawers on android:

But because of the nature/design of slate of bubbling from the children up to the parent, only if FReply::Unhandled is set the input would reach the drawer.
There would be the need of subclassing every class and overwriting the onMouseMove function to send an Unhandled FReply, for those which would be allowed to be placed inside the drawer. But that’s ridiculous.
And I need to write inside the Drawer class’ onmousemove something like this:
(pseudo code)



if(StartTouchLoc.Y - CurrentTouchLoc.Y > SomePixels) // Let's say 16 Pixels
{
     DisableChildWidgetInput(); // So the contained Listview and Buttons won't react anymore
     StartBlendingWidgetAToWidgetBWithCurrentFraction(CurrentFraction) // Fade Widget A out and Widget B in
}

I want to use this in a scenario, where I have a scrollable horizontal Listview with items, and with swiping this View up to view the whole inventory.
Any ideas/suggestions? (I’m totally fine with slate)

2

Start with the drawer open, then use a render transform to close it. Make sure when it’s closed that you disable hit-test though since the clickable areas don’t move with it.

3

Thanks for the answer, but when it’s closed/ hit test disabled, how can I open it by swiping up? The problem is not the fading/switching between Widget A and B, but more that I can not have a parent widget that decides which child currently is now actively using the touch input, because it’s the children which consumes it before the parent. For that drawer thing, it would be easier to be the other way around…
The small bar with the horizontal listview at the bottom must be horizontal scrollable and as soon as I scroll it vertically (up) it should start to fade in, etc.
If I would use a button, the whole thing would be extremely easy, but also destroys the native feel for mobile/touch devices. :confused:

4

I use a button to open the drawer, but you could quite easily write a bit of gesture recognition.

There is also some kind of swipe recognition in the engine but I’ve never tried it.

I don’t think you’ve thought about this enough if you’re stuck on input consumption. Keep working on it, try out some ideas.

5

The gestures inside slate are seemingly not implemented, except LongPress, as far as I remember, but have my own solution for that.
And the standard gesture reckognizer, doesn’t work with ui stuff either, either way, the thing is not about gesture recognition, wrote my own solution for that too for the gameplay layer.

2d/slate stuff does not forward the mouse/touch event (functions which return FReplys) to the parent widget, if the FReply got already handled (what buttons and scrollbars do) - thats my problem
Think there was a little missunderstanding here.
If I touch a child button/Scrollbar, the drawer never gets the chance to handle the mouse/touch, because the FReply is already handled.
I alredy spend a lot of thought, otherwise I wouldn’t asked in the forum. :slight_smile:

6

Found a solution by using an overriden OnMouseEnter and the RegisterActiveTimer function.
OnMouseEnter works even with already consumed inputs.
The OnMouseEnter has some checks inside and saves the start position & GetPointerIndex(to differentiate between multiple fingers) then registers an timer/tick function which gets executed as long as EActiveTimerReturnType::Continue is returned;

In that timer function I can query the cursor position and use the delta position and do whatever I want with it, without blocking any buttons/listviews inside. :slight_smile: