Potentially reconsider how bevy_egui interacts with picking by default

[mweatherley]

I work on a Bevy application that has camera viewports composited into window where the rest of the UI is made with egui. In 0.32, the change to EguiContextSettings makes it so that picking events anywhere in the main window are blocked by bevy_egui. Of course, visually speaking, these camera viewports lie "on top of" the UI.

(Actually, the behavior is weirder than that, since pointer events seemingly leak through as long as the mouse button is held down, but this is obviously not what you'd want.)

Disabling this requires creating a system or whatever to alter the relevant value in EguiContextSettings for the main window. In other words, I created a plugin just to undo the work in #338.

The main issue from my point of view is not the fact that bevy_egui causes pointer events to get captured per se, but more a matter of defaults and expectations. I can imagine that in plenty of scenarios (e.g. egui windows floating over a camera viewport), this behavior makes a lot of sense. In reality, what happened was that I bumped the bevy_egui version as I was migrating to Bevy 0.15, and it took a long time for me to realize that bevy_egui even interacted with picking at all, since my baseline expectation is generally for plugins not to interact with the picking backend by default but to do this through other means (e.g. a separate plugin).

Perhaps this is also a shadow of some way in which the camera views could be better integrated; ideally, of course, we would probably not be seeing that egui wants the mouse input in the egui::Context in the first place.

[vladbat00]

Hi, thank you for raising the issue and sorry about the inconvenience due to the update.

Actually, the behavior is weirder than that, since pointer events seemingly leak through as long as the mouse button is held down, but this is obviously not what you'd want.

Could you help me with reproducing this behaviour? I'm either misunderstanding what you are describing here or there might be something more to it. I've just pushed 079f098 to the main branch, to use the picking feature in the render_egui_to_image example.
The only thing that I've found is that dragging the mesh when a pointer is hovering over the screen-space UI is still happening if you've started dragging while from outside of the screen-space UI. But I'd say that's not necessarily an unwanted behaviour (and I suppose it's not something that bevy_egui can really affect).

The main issue from my point of view is not the fact that bevy_egui causes pointer events to get captured per se, but more a matter of defaults and expectations.

I understand how the behaviour change might not be expected in the context of some applications. And I agree it could have been better documented (settings and features discoverability is something that I'd like to improve, and I'm totally open to PRs for tackling this). Having that said, I think this is the behaviour that most users would expect. As you've also mentioned yourself,

I can imagine that in plenty of scenarios (e.g. egui windows floating over a camera viewport), this behavior makes a lot of sense.

– this seems to me like the most popular use-case for bevy_egui.

But I'm open to reconsider this if more people stumble upon the bevy_picking integration as something they wouldn't expect.

Perhaps this is also a shadow of some way in which the camera views could be better integrated; ideally, of course, we would probably not be seeing that egui wants the mouse input in the egui::Context in the first place.

Could you please expand on this a bit? I'm not sure why we wouldn't want to see egui wanting mouse inputs.