Could this widget interact with 'wants_pointer_input'?

[WooterTheTroubleshooter]

Is it possible for this widget to capture the mouse on hover? So that the egui method below will return true?
https://docs.rs/egui/0.19.0/egui/struct.Context.html#method.wants_pointer_input

I am using the above method in my game to know when to listen to interactions with the game. Clicking on the gizmo on a part that is not over the current selected entity will change selection instead of rotating/scaling.

Thank you.

[urholaukkarinen]

wants_pointer_input should return true when the gizmo is clicked. I don't know if it can be changed so that it would return true on hover too.
Can you call interact on the gizmo earlier, before checking whether to select another entity?

[WooterTheTroubleshooter]

Ok, I had already made sure the gizmo.interact was first in the chain.

It seems like the gizmo_response/egui is 1 or multiple frames late in responding to clicks/drag and I am not sure why that is happening. Floating windows seem to work fine, but that is probably due to wants_pointer_input disabling on hover for those.

The game itself uses mouse_down for immediate response. I am not able to find when wants_pointer_input changes to true for the gizmo. (mouse_down or later)

[Lieunoir]

Hi, I think I ran into the same problem, my dirted fix consisted of replacing ui.interact(viewport, id, Sense::click_and_drag()) by ui.allocate_response(ui.available_size(), egui::Sense::click_and_drag()) (and also allocate space during dragging).
There are a few downsides :

• I haven't been able to make it work with layers, so it sometimes show over other ui elements
• I don't think it behaves well if other widgets are added on the same area
  It does work well having multiple gizmos in the same area though.

Haven't found a prettier way to make it work (I haven't been able to completely understand how egui's hover capture works), maybe using a rect exactly fitting the gizmo would be better

[WooterTheTroubleshooter]

The problem I had, seemed to be in the scheduling of some of my ecs plugins. Where the processing of the selection seemed to happen in parallel with `egui'.

I added an additional stage EntitySelection where I moved the entity selection systems.
Which will run after handling the gizmo input unless `wants_pointer_input()' returns true.

[WooterTheTroubleshooter]

Hi, I think I ran into the same problem, my dirted fix consisted of replacing ui.interact(viewport, id, Sense::click_and_drag()) by ui.allocate_response(ui.available_size(), egui::Sense::click_and_drag()) (and also allocate space during dragging). There are a few downsides :

• I haven't been able to make it work with layers, so it sometimes show over other ui elements
• I don't think it behaves well if other widgets are added on the same area
  It does work well having multiple gizmos in the same area though.

Haven't found a prettier way to make it work (I haven't been able to completely understand how egui's hover capture works), maybe using a rect exactly fitting the gizmo would be better

I wanted to change my implementation to use mouse down instead of click, I ended up doing something similar. It did break the interaction part and I ended up removing it. As the primary button is checked again later.

However I am not confident enough to say I didn't break other stuff.

if state.active_subgizmo_id.is_none() {
    if let Some(subgizmo) = self.pick_subgizmo(ui, pointer_ray) {
        let hover = ui.input(|i| i.pointer.hover_pos())?;
        let rect = Rect::from_min_size(hover, vec2(1., 1.));
        ui.allocate_rect(rect, Sense::click_and_drag());
        subgizmo.focused = true;
        state.active_subgizmo_id = Some(subgizmo.id);
    }
}

WooterTheTroubleshooter@ed456b5