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

Hover not recognized right next to Area #576

Closed
mankinskin opened this issue Jul 23, 2021 · 3 comments · Fixed by #577
Closed

Hover not recognized right next to Area #576

mankinskin opened this issue Jul 23, 2021 · 3 comments · Fixed by #577

Comments

@mankinskin
Copy link
Contributor

mankinskin commented Jul 23, 2021

Peek 2021-07-23 19-34

This is what the container looks like:

    let area = Area::new(menu_id)
        .order(Order::Foreground)
        .fixed_pos(pos)
        .drag_bounds(Rect::EVERYTHING);
    let mut frame = Frame::menu(&style);
    frame.shadow = Default::default();
    area.show(ctx, |ui| {
        frame
            .show(ui, |ui| {
                //style.visuals.widgets.active.bg_fill = Color32::TRANSPARENT;
                style.visuals.widgets.active.bg_stroke = Stroke::none();
                //style.visuals.widgets.hovered.bg_fill = Color32::TRANSPARENT;
                style.visuals.widgets.hovered.bg_stroke = Stroke::none();
                style.visuals.widgets.inactive.bg_fill = Color32::TRANSPARENT;
                style.visuals.widgets.inactive.bg_stroke = Stroke::none();
                ui.set_style(style);
                ui.with_layout(Layout::top_down_justified(Align::LEFT), add_contents)
                    .inner
            })
    })

The same thing happens on master with the menu:
Peek 2021-07-23 19-38

debug on hover also shows that in that area none of the two overlapping widgets are hovered.

I suspect it is something with Context::interact, but I didn't figure it out yet. Any help would be appreciated 👍🏻

required for #543

@mankinskin
Copy link
Contributor Author

seems to be caused by Context::layer_id_at https://github.com/emilk/egui/blob/master/egui/src/context.rs#L730

@mankinskin
Copy link
Contributor Author

So the issue is context.options.style.interaction.resize_grab_radius_side which catches the hover in an area designated for dragging the sides of resizable windows. This is used for all Areas though, while it is only necessary for resizable areas.

I am now looking into disabling this extra radius for areas which are not resizable.

mankinskin added a commit to mankinskin/egui that referenced this issue Jul 23, 2021
mankinskin added a commit to mankinskin/egui that referenced this issue Jul 23, 2021
@mankinskin
Copy link
Contributor Author

egui/egui/src/memory.rs

Lines 472 to 488 in 5cef4ff

pub fn layer_id_at(&self, pos: Pos2, resize_interact_radius_side: f32) -> Option<LayerId> {
for layer in self.order.iter().rev() {
if self.is_visible(layer) {
if let Some(state) = self.areas.get(&layer.id) {
let mut rect = Rect::from_min_size(state.pos, state.size);
if state.interactable {
// Allow us to resize by dragging just outside the window:
rect = rect.expand(resize_interact_radius_side);
}
if rect.contains(pos) {
return Some(*layer);
}
}
}
}
None
}

one issue with this PR might be, that any non-interactable area can be found as a layer here. Maybe something like a "resizable" property is needed, so there can be interactable, but non-resizable areas. Similar to the "movable" property.

mankinskin added a commit to mankinskin/egui that referenced this issue Jul 25, 2021
mankinskin added a commit to mankinskin/egui that referenced this issue Jul 27, 2021
emilk pushed a commit that referenced this issue Aug 15, 2021
mankinskin added a commit to mankinskin/egui that referenced this issue Sep 29, 2021
fleabitdev added a commit to fleabitdev/egui that referenced this issue May 31, 2023
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`.
emilk added a commit that referenced this issue Jan 7, 2024
…3039)

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 `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`.

---------

Co-authored-by: Emil Ernerfeldt <emil.ernerfeldt@gmail.com>
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 a pull request may close this issue.

1 participant