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

Fix: Non-resizable Areas now ignore mouse input outside their bounds #3039

Merged
merged 4 commits into from
Jan 7, 2024

Conversation

fleabitdev
Copy link
Contributor

As described in #576, the method Memory::layer_id_at expands the hit-testing region for every Area slightly. This is necessary so that, when the user clicks to resize a Window, the mouse input isn't routed to a different Window.

For non-resizable Areas (such as dropdown menus, context menus, date pickers, and any non-resizable Window), this causes them to be surrounded by a "dead zone" where any underlying widgets can't be hovered or clicked. The effect is particularly noticeable in menu bars.

This commit adds a persisted edges_padded_for_resize property to Area, which is true when the Area belongs to a resizable Window and false for all other Areas. The hit-testing region is only expanded when this property is true.

As described in emilk#576, the function `Memory::layer_id_at` expands the
hit-testing region for every `Area` slightly. This is necessary so that,
when the user clicks to resize a `Window`, the mouse input isn't routed
to a different `Window`.

For non-resizable `Area`s (such as dropdown menus, context menus, date
pickers, and any non-resizable `Window`), this causes them to be
surrounded by a "dead zone" where any underlying widgets can't be
hovered or clicked. The effect is particularly noticeable in menu bars.

This commit adds a persisted `edges_padded_for_resize` property to
`Area`, which is `true` when the `Area` belongs to a resizable `Window`
and `false` for all other `Area`s. The hit-testing region is only
expanded when this property is `true`.
@fleabitdev
Copy link
Contributor Author

I'm a little uneasy about my approach here, because it forces Window to manually keep self.area.edges_padded_for_resize in sync with self.resize.resizable. It would be better to have a single source of truth, but that would probably require Area to be made responsible for resizing, which seems like a much larger change. Any thoughts?

Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit hacky I agree, but I fail to see any obviously better way

@emilk
Copy link
Owner

emilk commented Aug 9, 2023

I'm not sure why the CI isn't kicking in. Perhaps try merging in latest master and see if it helps?

@emilk emilk added the egui label Jan 7, 2024
@emilk emilk merged commit 5432f91 into emilk:master Jan 7, 2024
19 checks passed
@emilk emilk changed the title Have non-resizable Areas ignore mouse input just beyond their bounds Fix: Non-resizable Areas now ignore mouse input outside their bounds Jan 8, 2024
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
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.

2 participants