Availability of Graph Node Editor
jostlowe opened this issue · comments
Hi!
Wow, this project looks really cool! Great work
I've been on the lookout for a graph node editor, similar to the one implemented in this project. It is intended for a server routing network traffic for stage lighting protocols.
Is there any way of re-using the graph editor from this project? Is there any chance that the graph editor might be separated into its own crate in the future?
It seems the author expressed interest, which is great because the mode editor seems really well done!
I'd really like to see this for a project I'm working on, so do let me know if/when this will be done :P
(For context, I've wasted a combined 7 hours trying to get a grid to work and look natural. A grid. Granted, a zoomable and pannable grid, but why the hell is graphics programming this hard 🤬)
Hey all! Yes, this is indeed something I'd intend to work on at some point :)
Right now there are two main roadblocks that make it a bit difficult:
-
Zooming of UIs is not supported by egui AFAIK and for blackjack required a very specific setup with the wgpu backend. This could be replicated on other back-ends, but this part of the code is not portable.
-
I'm still haven't had time to figure out a good API for this independent graph crate. It should have the ability to define node types as well as the data types that can flow through the graph, potentially with each data type having a widget function so it can be rendered inline with the node.
For the zoom issue, I think to make this portable a solution must be considered at the egui level, but I'm not sure how difficult would that be, or if the author would be interested in a feature like this. On the other hand, the other roadblock looks very easy to tackle, and it's just that I haven't had time to put some serious thought into this yet. So I think a good plan would be to offer the node graph as an independent crate without the ability to zoom for the time being, but with enough parameters to allow other people to implement zooming in their backend, should they want to do it.
The interest in this is very high. I have started studying Blackjack's editor code and hopefully I will be able to contribute to this project sooner than later.
Zooming of UIs is not supported by egui AFAIK and for blackjack required a very specific setup with the wgpu backend. This could be replicated on other back-ends, but this part of the code is not portable.
@setzer22 I was able to get (the concept of) zoom to work (though it didn't look nice) with just pure egui (w/ glium). It may not be the best solution, but you can basically just do ui.input().scroll_delta.y (or zoom_delta if you want it to use ctrl+scroll not scroll)
Hi @ThePuzzlemaker! Detecting when I should zoom (i.e. zoom_delta) is already very portable. The problem is zooming an arbitrary child ui whithin an egui application. This would involve a mechanism to create a child_ui so that it gets a larger available_size and pixels_per_point values, which are then automatically shrunk by egui to fit the original available size.
I'm quite happy with the current implementation, but it basically requires two separate egui instances and very fine-grained control about how input events are forwarded to the child instance.
Oh wait--that's how you do zoom 🤔 I thought you just used the zoom factor to do some type of scaling when drawing nodes and connections. That makes sense why it's not as portable.
Yup! The problem with doing scaling like that is that the widgets would not get larger. I could figure out a way to shrink the widgets by playing around with spacing and proportionally scaling fonts. But the way I'm currently doing zoom is guaranteed to work no matter what you draw, so it feels conceptually cleaner
The graph node editor behind blackjack is now its own crate!
I will keep this issue open for a while until I take care of refactoring blackjack to use the new crate.