Thoughts about supporting imgui extensions about imgui-go

[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.