Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow overlapping interactive widgets #2244

Merged
merged 11 commits into from
Nov 7, 2022
Merged

Allow overlapping interactive widgets #2244

merged 11 commits into from
Nov 7, 2022

Conversation

emilk
Copy link
Owner

@emilk emilk commented Nov 6, 2022

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.

@emilk emilk marked this pull request as ready for review November 6, 2022 19:43
@emilk emilk merged commit d5eb877 into master Nov 7, 2022
@emilk emilk deleted the overlapping-widgets branch November 7, 2022 11:44
@emilk emilk mentioned this pull request Nov 16, 2022
yrns added a commit to yrns/transit that referenced this pull request Dec 5, 2022
@trivigy
Copy link

trivigy commented Dec 8, 2022

@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
Copy link
Contributor

Kryptos-FR commented Jan 20, 2023

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):
egui_regression_0 19

after (0.20):
egui_regression_0 20

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

Kryptos-FR added a commit to fragcolor-xyz/shards that referenced this pull request Jan 21, 2023
shouya added a commit to shouya/malakal that referenced this pull request Jul 31, 2023
yrns added a commit to yrns/transit that referenced this pull request Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Overlaping widgets
3 participants