The reason I am asking : After playing and extending a bit the provided egui_node_graph_example I started to dive into the next stage: Adapting a minimal version of the blackjack PolyAsm based graph compiler, so I can do node traversal and finally get some executable instructions. Unfortunately this is a bit outside my comfort zone and I ran into an error about wrong lifetimes and at several places I was not comfortable what I was doing to get things to compile and I was also in doubt how to adapt blackjack NodeData to egui_node_graph Node<NodeData>.user_data.

Anyway, if you plan to make blackjack use egui_node_graph, then I probably could figure out myself how to get my minimal compiler example to work, otherwise a minimal working example of something like a graph compiler would be great.

I changed the implementation to non-recurring DFS. This will do the following well.

1. This implementation does not use recursion, so it does not cause a stack overflow even if the number of nodes is large.
2. #21

Now, if change to light mode :

This makes the right-click popup text unreadable. So I made the following modifications to accommodate light mode. I would like to hear your opinions on the colors.

This modified branch is kkngsm@fffdaebe8b5807528444056805429d1bb3c594cb

Hi,

first of all, this library is a great starting point for anyone wanting to do nodegraphs. So thanks for releasing it!

The Editor currently uses straight lines to connect the nodes. But Bezier Curves look so much nicer :)

Luckily egui is adding support for cubic bezier curves. But since this is sadly only in their git, I am doing this writeup so once it ships, the implementation is straightforward.

Here I have linked a demo on how bezier curves can be set up to look like they do in other editors. You can move the endpoints to see how it feels. Notably, the control points are half the distance (s in the demo) away from the endpoints, but on the same y coordinate.

So, what has to be done here in the node graph?

In egui_node_graph/src/editor_ui.rs; Instead of:

painter.line_segment([src_pos, dst_pos], connection_stroke);

Something like:

let s = 0.5 * src_pos.distance(dst_pos);

let control_pos1 = pos2(src_pos.x + s, src_pos.y);
let control_pos2 = pos2(src_pos.x - s, src_pos.y);

painter.add(Shape::CubicBezier(CubicBezierShape {
    fill: Color32::TRANSPARENT,
    points:[src_pos,control_pos1,control_pos2,dst_pos],
    closed: false,
    stroke: connection_stroke,
}));

https://github.com/setzer22/egui_node_graph/blob/75308d0e72dd604339cd864173ca31f1bc7a3fc7/egui_node_graph_example/src/app.rs#L388-L399

If change it as follows, the switch doesn't work.

fn update(&mut self, ctx: &egui::Context, _frame: &mut eframe::Frame) {
    let graph_response = egui::CentralPanel::default()
        .show(ctx, |ui| {
            self.state
                .draw_graph_editor(ui, AllMyNodeTemplates, &mut self.user_state)
        })
        .inner;
    egui::TopBottomPanel::top("top").show(ctx, |ui| {
        egui::menu::bar(ui, |ui| {
            egui::widgets::global_dark_light_mode_switch(ui);
        });
    });

Currently egui_node_graph returns the node removal response before disconnection responses during node deletion. User code is likely to want to clean up connections before running any logic that handles node removal directly. This PR re-orders the responses so that disconnect responses are emitted before the removal response. This PR should be considered as introducing a breaking change, and one that isn't protected by types. As such it could lead to bugs in user code that depended on the old order. Still I think this is a more logical ordering so I am submitting this PR for consideration. Thank you.

As discussed in #26 - using lambdas / structures instead of macros. I think this is much easier for someone to reason about at a glance, especially as it doesn't introduce any new syntax or semantics. The first block was trivial, but the second block required me to introduce a temporary struct Evaluator to hold all of the relevant state.

I think the first block is uncontentious, but the second one might be a bit harder of a sell due to the increase in LoC. I think it's worth it, but you might not 😅

I'm working on my render graph editor. There are two special nodes called Input and Output. They should exist for all my node graphs, can not be created by the user, nor can be deleted.

I want to hide the close button for my Input/Output node. Currently I found no existing way to do this.

There can be a method fn can_delete(&self) -> bool for NodeDataTrait, so the nodes can decide whether it is deletable.

I implemented it on my fork. I can make a pr if you like.

I changed the implementation from DFS to BFS. This will do the following well.

1. This implementation does not use recursion, so it does not cause a stack overflow even if the number of nodes is large.
2. Infinite loop countermeasure #21
3. Easy to follow the process for those seeing the implementation for the first time(It might depend on the person.).

Just a simple quality of life feature to make the node finder search bar case insensitive by default. I'm fairly new to rust and open-source in general but excited to follow the development of blackjack and maybe contribute in the future. Really cool idea.

Fixes panning outside of the editor area, and being able to open a new finder by clicking inside the finder window. Also makes it so the finder area is always on top. It seemed to disappear when clicking twice in a editor area for some reason.

Tested in my program and seems to work.

Happy new year!

I've finally managed to finish the redesign that I proposed in this thread, and now here's the PR for it!

To accomplish the goals that I set out to achieve, I had to do almost a total rewrite of the library although I tried to keep it as spiritually close to the original as I could. Given how extreme this rewrite is, I won't be offended at all if you decide to reject this PR. Either way it was an extremely valuable exercise for me.

To help you decide whether you actually want these changes, here's a list of pros and cons:

Pros

• The UI is much more flexible
  • Developers can inject their own custom nodes and ports
  • Colors for the general look and feel can be customized
• It is easy to set connection limits for both input and output ports, or make their connections limitless
  • This means developers can set their input nodes to accept 1, N, or unlimited inputs
• It is easy for application users to see what the limits are and to choose which connections to disconnect
• Migration to this new API isn't too terrible (imho), the example application can be used as a reference
• I personally think the API is overall simpler to use, but obviously I'm biased when I say that

Cons

• Massively changes the API
• Ports are now inside of the node body instead of at the edge (see screenshot)
  • I do not prefer this change, but I couldn't figure out a way to make the node > port > hook hierarchy work without egui automatically wrapping the ports and hooks into the body of the node

After really getting into the weeds on this effort, I have a few conceptual concerns about using egui to produce node graphs.

• As you've mentioned elsewhere, zooming is very challenging and not something that egui presently supports out of the box
• Getting a desirable level of flexibility/extensibility involves some very convoluted trait relationships
• egui is a very useful and powerful tool for developing conventional UIs, but I feel like we're rapidly approaching the limit of what it can support nicely. I'd like to incorporate more complex 2D rendering into my node graphs, but I have some doubts that egui is cut out for that.
• I'm concerned about how well the immediate mode rendering will actually be able to scale if I want to use it for very large complex projects

For all of the above reasons I'm thinking about exploring the possibility of developing a node graph editor on top of kayak_ui which is made for the bevy engine. I feel optimistic that with the benefits of an ECS and a retained mode rendering pipeline there will be a lot more opportunity to produce large scale, complex, aesthetically pleasing node graphs.

I have two, possibly related, issues with UI ordering

1. Cables are above nodes

Cables should render behind nodes. As you can see, if they are in front, it can look pretty janky.

2. Attempting to select a node selects most back node when layered

If I click on the title "ObjRender", it brings the "Expression" node to the front. I expect the UI to reflect what I can interact with. "Expression" should only be selected if I click where I can see it, on the left.

If you right click a node output, it should show the add node ui, then automatically connect the added node to the clicked output if compatible.

I'm happy to pick up this work.

The example doesn't work with version 0.3.0. Are you gonna release a new version? or maybe add some more documentation to make it easier to get started?

NodeIds use slotmaps to hold references. Slotmaps return the same sequence of IDs for a given KeyType.

For example this runs with no panics

use slotmap::SlotMap;

fn main() {
    let mut sm1 = SlotMap::new();
    let mut sm2 = SlotMap::new();
    let sm1_key1 = sm1.insert("foo");
    let sm2_key1 = sm2.insert("bar");

    assert_eq!(sm1_key1, sm2_key1);
}

Egui Node Graph statically assigns the same KeyType to the node_graph slotmap and therefore multiple node_graphs in the same process will return the same keys. Since these keys go into the same "global" egui widget key-space egui complains about identical keys.