Allow overlapping interactive widgets

[emilk]

Closes #980

By interactive widget, I mean any widget with Sense::click or Sense::drag (or both).

This design is based on the idea that the latest added (which usually mean the top-most) widget gets the interaction.

For instance: say you have a big interactive canvas and on top of that put some widgets. If you hover the widgets, they get all the input. If you hover the canvas outside of the widgets, the canvas gets the input.

This is done by storing where all interactive widgets are, frame-to-frame. When a new interactive widget is added, we check if there is anything interactive above it (=added later in the previous frame), and if there is, the first widget gets hovered=false.

This change required some changes to ScrollArea, Area and Window to make sure they were properly layering interaction back-to-front.

There may be other looming bugs I haven't found yet.

Most user code should be unaffected, unless the user has added layers of interaction on top of each other.

You can visualize this using style.debug.show_blocking_widget and style.debug.show_interactive_widgets.

[trivigy]

@emilk This PR introduces a usability issue for ScrollArea. Note this is related to Mobile issue where touch is used to scroll rather than a mouse scroll.

use-case: If a scroll area has interactive widgets such as buttons which occupy majority of available space then, because those end up being places after the scrolling interactivity (in content function) and therefore steal interaction, it is impossible to actually scroll.

use-case: text-editor filling the entirety of a scroll area. When clicking on the text editing space the editing starts working but it is impossible to scroll with the finger when dragging the text editor.

I am currently trying to figure out a solution/workaround and the only possible solution I imagine is to use ctx.input directly inside of the scroll area rather than ui.interact() in order to prevent the scroll area interactivity to use the memory.interaction entirely altogether.

[Kryptos-FR]

edit: never mind. I fixed it by using Area instead of coming up with custom code.

---

original comment:

Most user code should be unaffected, unless the user has added layers of interaction on top of each other.

I am exactly in this situation. What is the workaround to still allow that?

Basically my scenario is: I have a some kind of graph with nodes represented as boxes which can have DragValue inside (to input some integer). Before 0.20.0, I could implemented dragging the whole boxes by just allocating a UI of the same size on top of the rest, sensing Sense::click_and_drag(), getting the drag_delta and apply that to some value that will then be used the next time to draw the shape. Now because this takes the whole area, I can move the shape but the underlying DragValue can't get the mouse focus to input value anymore. This is a big regression.

What was the rationale behind that change? I can't see the benefit of not allowing it any more.

before (0.19):

after (0.20):

Note: example of crate that is broken: egui_node_graph (if upgrading to egui 0.20+).