Are events consumed correctly? about transform-gizmo HOT 8 CLOSED

What I found is, during a session of click-rotate-release, we have:

• initial click is not consumed right away, i.e. egui context doesn't recognize that Gizmo consumes the click
• drag is consumed
• release is also consumed

I don't know if it's an issue with egui-gizmo or egui upstream, it's not easy to find out.

from transform-gizmo.

The consumed is part of egui_winit::EventResponse. For mouse input, it should get marked as consumed when egui::Context::wants_pointer_input() returns true. At least in the egui-gizmo-demo that seems to immediately return true whenever I click the gizmo, if called after Gizmo::interact.

from transform-gizmo.

What is the "egui-gizmo-demo" you are referencing @urholaukkarinen ? I checked the demo in this repo and it's not using winit, so it's not applicable as an example.

from transform-gizmo.

I meant that in the demo egui::Context::wants_pointer_input() returns true after interacting with gizmo, but I have not tried the Gizmo with egui_winit yet.

Anyways, the Gizmo does not explicitly consume any events. It interacts with egui using `ui.interact(viewport, id, Sense::click_and_drag())``, which in turn tells egui context that something is clicked/dragged.

from transform-gizmo.

I did some more experiments, and I think I found the answer. wants_pointer_input() only sets to true after I draw the Gizmo and it receives an event. Previously, I was checking for wants_pointer_input() on receiving the event, and that would be false, because Gizmo hasn't had a chance to process this event yet.

This is probably a misunderstanding of egui event model from my part. But it feels inconsistent somewhat with the rest of egui for me? For all other elements, somehow it's enough to check wants_pointer_input() before actually drawing them. So maybe there is something that could be done on Gizmo side?

from transform-gizmo.

Egui containers like Area and Window seem to cause wants_pointer_input to return true already on hover. I suppose I could also do that for the Gizmo, but I haven't yet figured out how. I don't know if there is any built-in way to do that for custom widgets.
It could be done by using a non-background Area element, but that is just a rectangle. I may not want wants_pointer_input to return true when none of the gizmo parts are highlighted.

from transform-gizmo.

For the record, I tried resizing an egui panel (which isn't related to Gizmo specifically), and I'm seeing the same issue. Initial click is not considered as consumed, which the release button is consume. So it could be something not to do with Gizmo specifically.

from transform-gizmo.

Since the gizmo no longer has any notion of events, I'll close this. If events can be manually consumed with egui, you can use Gizmo::is_focused or the gizmo interaction result to decide if the events should be consumed.

from transform-gizmo.