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

New widget interaction logic #4026

Merged
merged 36 commits into from
Feb 17, 2024
Merged

New widget interaction logic #4026

merged 36 commits into from
Feb 17, 2024

Conversation

emilk
Copy link
Owner

@emilk emilk commented Feb 11, 2024

The interaction code is now done at the start of the frame, using stored WidgetRects from the previous frame.

The intention is that the new interaction code should be more accurate, making it easier to hit widgets, and better respecting the rules of overlapping widgets.

There is a new style::Interaction::interact_radius controlling how far away from a widget the cursor can be and still hit it. This helps big fat fingers hit small widgets on touch screens.

This PR adds a new Context::read_response which lets you read the Response of a Widget before you create the widget. This can be used for styling, or for reading the result of an interaction early (to prevent frame-delay) for a widget you add late (so it is on top of other widgets).

⚠️ BREAKING CHANGES

Memory::dragged_id, Memory::set_dragged_id etc have been moved to Context.
The semantics for Context::dragged_id is slightly different: a widget is not considered dragged until egui it is sure this is not a click-in-progress. For a widget that is only sensitive to drags, that is right away, but for widgets sensitive to both clicks and drags it is not until the mouse has moved a certain distance.

TODO

  • Fix panel resizing
  • Fix scroll hover weirdness
  • Fix Resize widget
  • Fix drag-and-drop
  • Test all of egui_demo_app
  • Change is_dragging API
  • Consistent naming of start/stop or begin/end drag
  • Test egui_tiles
  • Test Rerun
  • Document
  • Document breaking changes in PR description
  • Test one final time

Saving for a later PR

I think both these can be fixed if each Ui registers themselves as a WidgetRect, with the possibility to interact with it later, as if the interaction was under all widgets on top of it.

@emilk emilk mentioned this pull request Feb 16, 2024
5 tasks
@emilk emilk marked this pull request as ready for review February 17, 2024 09:17
@emilk emilk changed the title WIP: new window interaction code New interaction logic Feb 17, 2024
@emilk emilk changed the title New interaction logic New widget interaction logic Feb 17, 2024
@emilk emilk merged commit ca8c879 into master Feb 17, 2024
35 checks passed
@emilk emilk deleted the emilk/hit-test branch February 17, 2024 14:48
emilk added a commit that referenced this pull request Mar 11, 2024
For instance: `Window::new(…).resizable([true, false])` is a window that
is only resizable in the horizontal direction.

This PR also removes a hack added in
#3039 which is no longer needed since
#4026
hacknus pushed a commit to hacknus/egui that referenced this pull request Oct 30, 2024
* Closes emilk#3936
* Closes emilk#3923
* Closes emilk#4058

The interaction code is now done at the start of the frame, using stored
`WidgetRect`s from the previous frame.

The intention is that the new interaction code should be more accurate,
making it easier to hit widgets, and better respecting the rules of
overlapping widgets.

There is a new `style::Interaction::interact_radius` controlling how far
away from a widget the cursor can be and still hit it. This helps big
fat fingers hit small widgets on touch screens.

This PR adds a new `Context::read_response` which lets you read the
`Response` of a `Widget` _before_ you create the widget. This can be
used for styling, or for reading the result of an interaction early (to
prevent frame-delay) for a widget you add late (so it is on top of other
widgets).

# ⚠️ BREAKING CHANGES
`Memory::dragged_id`, `Memory::set_dragged_id` etc have been moved to
`Context`.
The semantics for `Context::dragged_id` is slightly different: a widget
is not considered dragged until egui it is sure this is not a
click-in-progress. For a widget that is only sensitive to drags, that is
right away, but for widgets sensitive to both clicks and drags it is not
until the mouse has moved a certain distance.

# TODO
* [x] Fix panel resizing
* [x] Fix scroll hover weirdness
* [x] Fix Resize widget
* [x] Fix drag-and-drop
* [x] Test all of egui_demo_app
* [x] Change `is_dragging` API
* [x] Consistent naming of start/stop or begin/end drag
* [x] Test `egui_tiles`
* [x] Test Rerun
* [x] Document
* [x] Document breaking changes in PR description
* [x] Test one final time

# Saving for a later PR
* [ ] Fix emilk#4047
* [ ] Specify what the response order for e.g. `ui.horizontal` is

I think both these can be fixed if each `Ui` registers themselves as a
`WidgetRect`, with the possibility to interact with it later, as if the
interaction was under all widgets on top of it.
hacknus pushed a commit to hacknus/egui that referenced this pull request Oct 30, 2024
For instance: `Window::new(…).resizable([true, false])` is a window that
is only resizable in the horizontal direction.

This PR also removes a hack added in
emilk#3039 which is no longer needed since
emilk#4026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Do all widget interaction at the start of the frame Windows cannot be resized when in front of a plot
1 participant