Any way to make overlapping widgets gain interaction when interactivity is non-overlapping?

[trivigy]

I am using ScrollArea with some buttons inside of the scroll viewport that need to capture click interactivity. However when those are clicked the dragging (scrolling) no longer works. Is there anyway to cascade the dragging interactivity while take the clicking interactivity for the buttons?

EDIT: Reading through the sources of information I found this seems that one proposed idea is to somehow use an Area or a higher layer_id. However in this situation I am not positive it will work due to the scroll area containing it's content.

[trivigy]

Related: #980 #459 #2244

[trivigy]

@emilk Would greatly appreciate your comments here as I am trying to solve this issue for my use-case. At the moment I could not even come up with a user side workaround and at this point I am messing around with the egui code base.

After much investigation I understand that with the current implementation only one Rect which was created last through the ctx.interact() function ends up receiving the interactivity. Specifically the code HERE causes hovered to become false and therefore cancels the interaction processing of rects that were generated earlier in the code. Furthermore, it seems that in general there is only one memory.interaction structure per Context which kind of makes it impossible to interact with multiple things at the same time if they were somehow overlapped. I had some marginal success with tricking ctx.interact() using the following code, although that in itself caused a bunch of bugs.

let id = ui.make_persistent_id("ae35d739");
ui.with_layer_id(LayerId { order: Order::Background, id }, |ui| { /* code */ })

Luckily the Interaction component separates between captured click_id and drag_id CODE. Thus, when employing the trick above for two overlapping rects where one only cares about drag and the other about clicks I was able to "sort of" make overlapping widgets work. But not really adequately well. Additionally, in my current implementation I am working only with clickable rects inside of a scroll area however I do have a requirement for adding a drag-able component inside of the scroll area as well, which will introduce an even further complexity.

Currently main outstanding questions:

1. If this mechanism was to be modified, how should it be done? Not as much from the technical stand point but rather more interested in design ideas.
2. On a mobile device (I am working with Android), what would it even mean in terms of interactivity, to have a drag-able widget inside of a scroll area which is drag-able in itself?

EDIT: commenting here on my own question. After some investigation how other interfaces handle such functionality I came to the following thought. Long hold (click + hold) on the internal drag-able widget gives it the interactivity where-as short click + drag gives the interactivity to the higher scroll area. Thoughts on how that might be possibly integrated into the current implementation of ScrollArea are much needed.