Where is the bridge between Python and C++?

[slotrans]

I've been trying to port a small dearpygui program to a set of lower-level Dear ImGui bindings for another language. To do that, I've had to dig in to some of the conveniences that dearpygui offers, such as the horizontal=True option for groups, to see how they're implemented. I've been able to infer that e.g. add_button ultimately invokes code in src/core/AppItems/basic/mvButton.cpp, but that inference is based purely on matching up names.

What I haven't been able to find is the actual code that connects those two things (probably because I have little understanding of Python internals or native extensions, and can barely read C++). Where can I find it? What is the mechanism by which Python invocations of the functions in the _dearpygui module result in C++ code getting executed?

[hoffstadt]

Hey, sorry its a bit of a mess and we are still cleaning up the backend to make things like this easier. The add_ commands are actually lines 34-57 of cpp.hint. As for any specific operations or additions (like the horizontal keyword you mentioned), look at the "draw" methods. For group it would be mvGroup.cpp line 57-200.

The actually "bridge" you are looking for is here and some of the macros you find in the specific item files (mvButton.h). You can also search for "mv_python_function" in the code. These functions are the actual cpp functions the python code is calling.

[abellgithub]

I'll add to this since I've just been through it. All the magic is in the PyInit__dearpygui() function. All the entry points are added via methods in the list that is passed from the module specification, dearpyguiModule, to PyModule_Create. The functions that actually represent objects that stick around (called "items") are created with the macro magic of MV_ITEM_TYPES, which has X defined to create the method definition in the init function.

Items are all created with the common_constructor which uses CreateEntity to make the item (also with macro magic) and then store that returned item in the parent's appropriate "slot" with AddItemWithRuntimeChecks.

Note that items, as well as lots of other things, are retained as mvRef<type>, where this isn't really a reference, but a std::shared_ptr.

Also, if an item has a tag and the tag is an int (not explicitly checked, by the way), that value is used as a UUID for the created item. If the item has a tag and it's a string, a UUID is generated by incrementing an integer that's stored in the global context and that string/UUID mapping is stored in an std::unordered_map. Not sure how (or if) this is guaranteed unique with user-provided tags. I may well have missed something.

There is no use of anything like pybind11 or cython or cppyy.

[hoffstadt]

That's exactly it. It's a mess now but it worked...