Thoughts about supporting imgui extensions

[ptxmac]

I've been looking at some of the larger extensions for imgui (like implot), and thinking about how best to use these together with imgui-go.

Ideally, it would make the most sense to create new packages, i.e. github.com/inkyblackness/imgui-go for the base imgui integration, and something like github.com/ptxmac/implot-go for each extension that makes sense to wrap.

Unfortunately, this hits a limitation of how cgo works; when adding c/cpp code to a go package, everything will be linked statically. This means that two packages cannot compile the same c/cpp code since this results in duplicate symbols.

In the of imgui-go it means only one package can include "imgui.cpp" (and friends). But implot can't be compiled without, so there's a conflict if two separate go packages both want to include imgui.cpp

I've been trying a few different things, but so far I've only found a few solutions, and none of them is "pretty":

1. Put everything to do with implot in the same package as imgui, but prefix it with Implot_ (or similar). Some tricks with go build tags could be used to be able to ignore all implot code if not needed (either opt-in or opt-out).
2. Same as above, but move all code calling C to an internal package and then create another layer of wrappers for the imgui/implot/etc. packages. I.e. package/implot have a method ShowDemo which is just a direct call to package/internal/clib.ShowDemo. A lot of complication, but it would make the packages somewhat neater for users.
3. Use dynamic libraries instead of statically linking the source. This would fix all problems, except actually using the packages becomes a pain. The user would be responsible for installing a dynamic library version of imgui / implot / etc for the correct architecture.

As a side note, I also took a look at things like cimgui / cimplot, but they won't fix any one of the problems here, except the double wrapping in 2. would be much easier to maintain since most could just be generated from the JSON definitions

I'm hoping I've missed a better solution, but it seems cgo is not very flexbile when wanting to use the same C code in several packages

[dertseha]

Hello there and thank you for your thoughts.
So far I haven't thought that much into these details, thus also thank you for coming to conclusions that I only vaguely suspected so far.

Similar to a somewhat related topic brought up in #112 , especially with your conclusions about complexity, my answer back then still holds: imgui-go is a wrapper for, and only for, the official branch of Dear ImGui. And with your conclusions about cgo, the wrapper (by itself) is also not combinable with extensions.

Added to that is also the question about "scale" in the farthest sense: Which extensions should be included in this uber-wrapper (regardless of the chosen approach)? What are the criteria? You brought up one extension, I know there's at least one for file dialogs people might find useful, and there's probably plenty more.
I'd really like to avoid going into a path where I (or any future maintainers of this repo) become package managers, juggling with versions, updates, and compatibilities between the extensions and base versions. It is already tricky enough to keep somewhat of a promise of semantic versioning with the base library.

Instead, I'd think of a wrapper-generator tool. Similar to the approach of cimgui, but on a broader sense: Select the base library (branch & version), then any extension you like, and the tool collects the corresponding sources, and then runs a code generator over them. So, instead of a pre-built Go library that you import, you create the imgui-experience specific to your own project.
Upsides: You can have a mix-and-match of all extensions/variants; Downsides: Not hand-crafted (which, given the complexity, would actually be a positive)
This is only a vague idea, partly inspired by such things like go-gl/glow , and I don't intend to follow up on it.
(edit: there's still potential for some hand-crafting, as probably the function signatures need meta-info, just like in go-gl/glow)

In short, any attempt for adding any extensions must be done in a dedicated repo/project - I don't intend to take on this task.
I take it that you were hoping to have/achieve such a combination within this repo. Sadly, this is beyond what I planned it for.
Though perhaps all of this sparks some ideas in you :)

[ptxmac]

I take it that you were hoping to have/achieve such a combination within this repo

Not directly, I'm aware that any solution to this problem will be quite disruptive, so it makes more sense to have it in a fork or completely new project. But it would be useful to coordinate so if I start working on a solution it would be an almost drop-in replacement for inkyblackness/imgui-go

Creating a generator is probably the best solution, and if it's based on cimgui it would provide a small handful of extensions "for free" (the cimgui org have wrappers for imgui and 5 extensions)!

It's also the solution that has the steepest initial development curve - I took a stab at it a few days ago, and while it can be done, it does require a lot of work to get it up and running. I'll take a look at glow for some inspiration on how build wrapper-generators!

[dertseha]

A compatible drop-in replacement sounds good!

Having a generated approach, capable of adding extensions, with hand-crafted meta information does also feel better than hand-crafting just the base library. Especially if the users are allowed to select what they actually need.

I'm curious with what you come up with. As for coordination: Since I'm only focusing on the official base library, this area is predictable.