ImNodeFlow gives Dear ImGui a node editor you build by subclassing

What the library actually does

ImNodeFlow is a node based editor and blueprint system for Dear ImGui, and the one-line pitch is that you create your custom nodes and their logic and ImNodeFlow will handle connections, editor logic, and rendering.

That division is the whole design. The library owns the canvas, the panning and zooming, the drawing of links between ports, the interaction that creates and deletes them, and the pop-up events when you right-click. You own the node types and what they do.

The feature list is short, and each item is a piece of editor behaviour you would otherwise have to write. Support for Zoom. Built-in Input and Output logic. Built-in links handling. Customizable filters for different connections. Built-in customizable pop-up events. And appearance 100% customizable.

The connection filters deserve a note, because they are the feature that turns a generic node editor into something usable. A filter decides which ports may be connected to which, and the example code applies ConnectionFilter::SameType() to both ends of a node, which means an integer output can only connect to an integer input. Without that, a graph editor degenerates into a place where you can wire anything to anything and discover the mistake at runtime.

The pop-up events are the other half. A node editor without a context menu is a diagram, not an editor, and the built-in customizable pop-ups are what let a user add nodes, remove them and start a link without your code handling any of it.

The primary language is C++, the licence is MIT, and the last push was on 2026-05-23, with the latest release v1.2.2 from 2024-06-09 after v1.2.1 in March 2024 and v1.2.0 in February 2024. The topics list names dear-imgui, node-editor, blueprints and cross-platform, and the documentation is a documentation.md file at the repository root.

Writing a node

The readme's simple node example is the fastest way to understand the API, because a whole node is about fifteen lines.

class SimpleSum : public BaseNode
{
public:
    SimpleSum()
    {
        setTitle("Simple sum");
        setStyle(NodeStyle::green());
        addIN<int>("IN_VAL", 0, ConnectionFilter::SameType());
        addOUT<int>("OUT_VAL", ConnectionFilter::SameType())
                ->behaviour([this](){ return getInVal<int>("IN_VAL") + m_valB; });
    }

    void draw() override
    {
        ImGui::SetNextItemWidth(100.f);
        ImGui::InputInt("##ValB", &m_valB);
    }
private:
    int m_valB = 0;
};

Read it in order, because each line is one of the four things a node needs.

The class inherits from BaseNode, and the constructor is where the node describes itself. setTitle sets the text shown in the node header, and setStyle takes a NodeStyle, with NodeStyle::green() giving the green variant.

The ports come next. addIN<int>("IN_VAL", 0, ConnectionFilter::SameType()) declares an integer input named IN_VAL with a default value of zero, and addOUT<int>("OUT_VAL", ConnectionFilter::SameType()) declares the matching output. The filter is the third argument on both.

The behaviour is a lambda attached to the output port with ->behaviour(...). It is called when the value is read, and here it reads the input with getInVal<int>("IN_VAL") and adds the member variable m_valB.

The last piece is draw(), which is an override and contains plain ImGui calls. The node's own widgets, in this case an ImGui::InputInt for a second value, are drawn inside the node body, so the node can have editable state that the graph does not know about.

The important idea is that the behaviour is a pull, not a push. The output computes its value when something asks for it, so the graph does not need an evaluation order, and there is no risk of a node reading a value that has not been computed yet.

Running the example and starting your own project

A simple example using the SDL2 plus OpenGL3 backend is provided in the example folder, and the readme makes the point that the CMakeLists.txt file downloads the necessary sources automatically and populates.

The build sequence is four commands:

cd example
mkdir build
cd build
cmake ..

and then the example binary is run from the build directory. The readme says you can use this example as your starting point to build your code, which is the practical advice: the example already solves the annoying part, which is getting Dear ImGui and ImNodeFlow compiling together with a backend.

If you already have Dear ImGui installed system-wide, you can pass the -DUSE_SYSTEM_IMGUI=ON option while configuring CMake. The catch is that you need the Findimgui.cmake script so that find_package(imgui) can locate the libraries and headers.

The example folder also holds a CMakeLists.txt, a cmake/ directory, example.cpp, example.hpp and an html/ subdirectory, so the example is more than a single translation unit.

The repository root is laid out in the conventional way for a single-library C++ project: include/ for the public headers, src/ for the implementation, example/ for the sample application, and documentation.md, readme.md and LICENSE.txt.

The build does not require the library to be installed anywhere. The custom-target CMake script fetches both dependencies from GitHub at configure time with FetchContent, and the readme says you can adapt it to your needs.

The CMake setup for your own executable

The custom target section of the readme is a complete, working CMake script for building a program against ImGui and ImNodeFlow, and it is worth reading in full because it shows a pattern that is easy to get wrong.

set(IMGUI_DIR ${CMAKE_CURRENT_LIST_DIR}/includes/imgui)
set(IMNODEFLOW_DIR ${CMAKE_CURRENT_LIST_DIR}/includes/ImNodeFlow)

include(FetchContent)

FetchContent_Declare(ImNodeFlow
     GIT_REPOSITORY "https://github.com/Fattorino/ImNodeFlow.git"
     GIT_TAG "master"
     SOURCE_DIR ${IMNODEFLOW_DIR}
)

The two directory variables are set first, and then each FetchContent_Declare passes its SOURCE_DIR explicitly. That is the detail that makes this work: by default FetchContent puts each dependency in its own subdirectory of the build tree, and ImNodeFlow needs Dear ImGui's sources at a known location relative to itself. Setting SOURCE_DIR for both puts them side by side in a directory you control.

The sources are then listed explicitly. For ImGui that means imgui.cpp, the imgui_stdlib.cpp from misc/cpp, imgui_draw.cpp, imgui_tables.cpp and imgui_widgets.cpp, plus the SDL2 and OpenGL3 backends. For ImNodeFlow there is one file, src/ImNodeFlow.cpp.

The executable is then declared with add_executable(custom_exe custom_exe.cpp ...) over both source lists, with the C++ standard set to 17 through set_property(TARGET custom_exe PROPERTY CXX_STANDARD 17), and the include directories covering the ImGui sources, the ImNodeFlow include directory and the ImGui backends directory. The target compile definitions include IMGUI_DEFINE_MATH_OPERATORS, which is what makes ImGui's own maths operators available for the vertex maths the node editor does.

Linking depends on the backend, and the readme gives the SDL2 plus OpenGL case:

find_package(OpenGL REQUIRED)
find_package(SDL2 REQUIRED)
if (UNIX)
    if (NOT APPLE)
        find_package(Threads REQUIRED)
        find_package(X11 REQUIRED)
        target_link_libraries(custom_exe PRIVATE
                ${CMAKE_THREAD_LIBS_INIT} ${X11_LIBRARIES} ${CMAKE_DL_LIBS})
    endif()
endif()

target_link_libraries(custom_exe PUBLIC OpenGL::GL SDL2::SDL2)

The conditional structure matters on macOS, where X11 and Threads are not required the way they are on other Unix systems.

Where ImNodeFlow fits, and where it stops

The comparison worth making is with a node editor that ships as a complete application, and with writing the editor yourself.

Against a ready-made visual programming environment, the difference is that ImNodeFlow is a library and the application is yours. There is no runtime, no execution graph, no serialisation of a project file, and no built-in meaning attached to a node beyond what you give it. The behaviour of an output is a callback you wrote, and nothing tells the library what it means.

That is a strength if you are building a domain tool. A shader editor, a quest graph editor, a data pipeline builder: in each case the nodes mean something specific to your domain, and the generic editor gets in the way. It is a weakness if you wanted a visual programming language users could author arbitrary logic in, because then you have to build the semantics, the execution model and probably the undo stack as well.

Against writing the editor yourself, the value is in the parts that are fiddly rather than clever. Link rendering with proper anchors, the panning and zooming maths, the interaction rules that distinguish a click from a drag, the context menus, the filtering of which connections are allowed. Those are the parts where you spend a week and end up with something that feels wrong, and where a maintained library is the sensible choice.

The limits are worth naming. The library is Dear ImGui specific, so it inherits Dear ImGui's own constraints, including its immediate mode rendering model, which means a large graph means many draw calls every frame. It has no persistence layer, so saving a graph is your problem. The zoom support was contributed by a third party, nem0, and the credits also name thedmd for imgui_bezier_math.h and ocornut for Dear ImGui itself, which is a short list for a project of this kind and suggests the codebase is small enough to read.

On maintenance, the picture is modest. The last push was on 2026-05-23 and the repository is not archived, so work continues, but the last tagged release is v1.2.2 from June 2024, with v1.2.1 in March 2024 and v1.2.0 in February 2024. A library with a release gap of about two years and a recent commit is worth evaluating on its current state rather than on its version history.

The documentation pointer is documentation.md at the repository root, and the readme says to refer to it for a more detailed explanation, which is where the full API and the node lifecycle are described.

Editorial conclusion

ImNodeFlow suits a C++ developer building a tool with a visual editor on top of Dear ImGui, since a node is a subclass with a handful of declarations and the library takes care of the canvas, the links and the interaction model. It is the wrong tool if you want a general visual programming language with execution semantics, because ImNodeFlow is an editor framework and the behaviour of a node is your own callback, and it is the wrong tool if you want a finished application rather than a building block. Before starting, read documentation.md, which the readme points to for the detailed explanation, and copy the example folder as the starting point, since its CMakeLists.txt already fetches and builds the required sources.

Frequently asked questions

Official sources

1. Fattorino/ImNodeFlow on GitHub
2. Issues
3. License: MIT
4. README
5. Releases