Closed rsaccon closed 2 years ago
I don't think there's any reason for the central panel, other than the code I extracted this from being structured that way. So it would make a lot of sense to let the user customize the container where the graph is drawn in.
I can give this a go, or let me know if you'd like to work on a PR! 👍
I would also really like this. I did a quick test by creating a egui::Window
and passed in the UI parameter to draw_graph_editor
. I had some trouble with the sizing of the window container. The right-click menu is available outside the Window, and the node widget is not possible to interact with, until I move the very small window on top of the Node widget. The positioning of the Node widget seems to be global and not relative to the window as well.
I don't really know that much about egui to figure this out at the moment..
fn update(&mut self, ctx: &egui::CtxRef, _frame: &epi::Frame) {
egui::Window::new("Graph Editor").show(ctx, |ui|{
let graph_response = self.state.draw_graph_editor(ctx, ui, AllMyNodeTemplates)
}
}
In the meantime I also played with an example where I pass UI
to draw_graph_editor
and made the same observations as @jorgeja. I do not know how in egui normally this is handled, but peeking at the source of some other projects which use egui it looks to me like Ui.interact might be helpful to restrict and handle interactions.
Currently
draw_graph_editor
creates a CentralPanel to draw its stuff. In my case I would prefer if the the main application manages the container for for the graph_editor and just passes aUi
todraw_graph_editor
. Is there a specific reason for the CentralPanel approach (like special requirement for the pan-zoom) ?