About ImGui Bundle & ImNodes

[pthom]

Hello Rokas,

@rokups: once again, as I answered to you on twitter, I am sorry if my work on ImGui Bundle may have impacted your work on a imgui python bindings project.

I was not aware about your efforts on this subject, although it is true that I did not communicate with Omar about my project during its development, and maybe I should have done this sooner. If you feel so, please accept my apologies.

The truth is I wanted to be as polished as possible before communicating about it. Also, I faced quite a lot of challenges during development, especially when porting imgui_internal; and I was not sure I could overcome them all.

I studied your library api while working on ImGui Bundle, and I did not have enough time to bind it initially.

Anyhow, I saw that you discovered the repository of the generator. If you are interested, I could investigate with you how ImNodes could be added into the bindings. This would probably require some adaptations on the API side, since pybind11 is quite limited about opaque types.

Concretely, this would mean that for example this part of the API:

IMGUI_API bool GetNewConnection(void** input_node, const char** input_slot_title, void** output_node, const char** output_slot_title);

would need to be wrapped so that void * is represented as a type that pybind11 can understand (maybe uinptr_t), and so that the outputs of the function are grouped. pybind11 will not handle double pointers, and output parameters are better represented by returning a tuple or a basic struct in python.

maybe something like this:

using NodeId = uintptr_t;

struct ConnectionSlot
{
   NodeId LinkedNode = 0;
   std::string SlotTitle;   // std::string or maybe a fixed size string buffer
};

struct ConnectionInfo
{
   ConnectionSlot InputNode;
   ConnectionSlot OutputNode; 
}

struct NewConnectionInfo
{
   bool Changed;
   ConnectionInfo Info;  
}

IMGUI_API NewConnectionResult GetNewConnection();

This is only a draft, as I do not know ImNodes enough ;-)

Thanks,

Pascal Thomet

[rokups]

Hello!

First of all - no apologies needed for making awesome stuff! My twitter comment may have sounded different from what i intended. When i saw your bindings i was simply blown away :) I was working on mine quietly, without publishing them. It is not a trivial task, and i am making them as i go, while working on a personal project (which has some overlap with imgui bundle - i am also interested in implot applications within ipython notebooks). I am also using SWIG (for better or worse). Though on a deeper look i decided to continue working on my bindings just a little bit more, since imgui bundle does not quite cover everything i need (which would be at very least implot_internal.h). Reason that led me to find bindings generator was me needing to customize bindings output to migrate my project, im not quite willing to drop my conventions just yet... In my bindings i dropped _ suffixes for enum types because that is just noise. I also dropped ImGui prefix from types since i use package name to access things, which allowed me to use imgui.MouseButton_Left instead of imgui.ImGuiMouseButton_Left or explicitly importing every symbol. Basically just some differences in philosophy... But i digress!

On the APIs in question... The reason i used void* there is to allow using an object pointer as a node identity, as seen in usage of GetNewConnection() in the sample.cpp. ImNodes is hardly a library providing a ready solution, it is rather building blocks for implementing custom nodes (and quite limited at that to be honest). In any case, correct thing to do on the side of python bindings would be to use PyObject* in place of every void* in the API, so python users can use arbitrary objects to hold state of their nodes. For returning data - i think it is better to return a tuple rather than a struct by value. My understanding is that pybind11 would make a copy of NewConnectionResult every time function gets called and free it soon after when variable becomes unreferenced on python side. If wrapper was returning a tuple at least we would avoid C++ object copy and only have a throw-away tuple.

But eh.. I am not working on this library much (as can be seen from commit history). I think it would be more valuable to wrap this project instead: https://github.com/thedmd/imgui-node-editor

[pthom]

Hi !

Many thanks for your message, and happy to read that you are pursuing your work on your generator.

In my bindings i dropped _ suffixes for enum types because that is just noise.

In ImGui Bundle you will find a somewhat comparable convention, with things like

TimeUnit = int # enum TimeUnit_
# ...
class TimeUnit_(enum.Enum):
    # ImPlotTimeUnit_Us,      /* original C++ signature */
    us = enum.auto()    # (= 0)  # microsecond
    # ImPlotTimeUnit_Ms,      /* original C++ signature */
    ms = enum.auto()    # (= 1)  # millisecond
    # ...

which would be at very least implot_internal.h

I had not seen the need for this one. Anyhow, I spent sometime studying if the generator could swallow it. It seems like it can, and it gave me this result, which I was able to compile and use with python (beware, this is work in progress, and I tested only one or two python binding in the internal module).

See related commit in the implot_internal branch.

I had to exclude some functions, see generate_implot.py : the functions I had to exclude were mainly time related, and DateTime format related (since they were using a C style output char * buffer)

---

Concerning your library, thanks for the suggestions ! I'm not sure using PyObject would be recommended with pybind11 (which is closer to C++ than swig).
Concerning your remark about returning a tuple [bool changed, optional<ConnectionInfo>], you are right! Or maybe even a simple optional<NewConnectionInfo> would even suffice.

Concerning thedmd/imgui-node-editor, I ported already; and it is working nicely.

Cheers!

[rokups]

I had not seen the need for this one.

In my experience writing a non-trivial implot application totally requires internal header. Many things are just not exposed. Features like point fitting or axis manipulation (syncing chart location when switching between independent charts, saving/restoring visible chart range etc). Curiously enough, i feel like i avoided a bullet, because SWIG manages to deal with implot_internal.h while imgui_internal.h is much more complicated and i could not trivially wrap that, but at the same time i did not need to use imgui_internal.h yet.

I'm not sure using PyObject would be recommended with pybind11 (which is closer to C++ than swig).

I used PyObject to convey the idea of passing a python object. So with pybind11 you would use pybind11::object which wraps PyObject*. Different skin, same thing.

Or maybe even a simple optional would even suffice.

Thats a great idea. I suppose in such case pybind11 would return a value or None and from user's point of view it would be either falsy or truthy, which is perfect.

[rokups]

Hey while we are talking, here is how you can integrate imgui with ipython:

imgui_loop.py - implements a custom main loop for ipython.

from ipykernel.eventloops import register_integration


@register_integration('imgui')
def loop_imgui(kernel):
    """Start a kernel with the Tk event loop."""
    import imgui
    app = None
    while True:
        if len(imgui._ipython_callbacks) > 0:
            title, cb = imgui._ipython_callbacks[0]
            if app is None:
                app = imgui.DearImGuiApp(title)

            if app.begin_frame():
                do_continue = cb()
                app.end_frame()
            else:
                do_continue = False

            if not do_continue:
                app.close()
                app = None
                del imgui._ipython_callbacks[0]

        if kernel.shell_stream.flush(limit=1):
            break


@loop_imgui.exit
def loop_imgui_exit(kernel):
    pass


def load_ipython_extension(ipython):
    pass


def unload_ipython_extension(ipython):
    pass

and in the notebook:

%load_ext imgui_loop
%gui imgui

import imgui

@imgui.ipython_gui('Charts')
def imgui_app():
    visible, is_open = imgui.begin('Charts', p_open=True)
    if visible:
        imgui.text('ipython_gui')
    imgui.end()
    return is_open

@imgui.ipython_window('Charts')
def imgui_app():
    imgui.text('ipython_window')
    return True

these are custom additions in imgui module that are used to communicate gui implementation functions to the loop:

_ipython_callbacks = []

def ipython_gui(title):
    def decorator(fn):
        global _ipython_callbacks
        _ipython_callbacks.append((title, fn))
    return decorator


def ipython_window(title):
    def decorator(fn):
        global _ipython_callbacks
        def render_window():
            flags = WindowFlags_NoDecoration | WindowFlags_NoResize | WindowFlags_NoMove
            vp = get_main_viewport()
            set_next_window_pos(vp.pos)
            set_next_window_size(vp.size)
            if begin(title, flags=flags):
                do_continue = fn()
                end()
            else:
                do_continue = False
            return do_continue
        _ipython_callbacks.append((title, render_window))
    return decorator

If you think this is useful add it to imgui bundle. This is what it looks like:

Decorated ui implementation functions are ran one after another, next one runs if first window closed.

[pthom]

This is definitively interesting, and close to a subject I would like to explore, i.e. improve Notebook integration. I had written a draft idea on how to better integrate ImGuiBundle with a notebook (see here).
I was exploring how to display the Gui directly in a notebook. However, this is a bit bumpy road!

I'll take a look at your ideas, thanks!