Need for a hand-crafted wrapper vs. investing in a wrapper generator?

[dertseha]

This wrapper was created at a time when there was no working alternative for me and my project.
However it turned out to be re-usable for others, so this is where we are right now.

Yet other projects also moved on, and so we have projects like https://github.com/cimgui/cimgui , which are based off of a generator using meta-data.
In combination of me asking whether other maintainers of this repo here may be useful (#161 ), I am also wondering, whether there is continued need for a hand-crafted wrapper.

Slight side-step: Most of us using imgui-go are most likely also using something from https://github.com/go-gl - either go-gl/gl , or, as I've learned to be better: go-gl/glow. I have realized that the go-gl/gl repo is a viable source to get something going quickly, yet you also have a lot of extra weight, and the additional dependency of updates to go-gl/gl when something in go-gl/glow changes. Using go-gl/glow directly for ones project furthermore allows to specialize the used API in the background.
For these reasons I've switched inkyblackness/imgui-go-examples to have the OpenGL bindings created via go-gl/glow, for example.

And this is what I am wondering about imgui-go as well: What if instead of maintaining a hand-crafted wrapper, there was a Go wrapper generator? This idea could go even farther: What if that generator would additionally allow to add or mix-in either branches of Dear ImGui (mutliple windows for instance), or even extra add-ons, like file dialogs and all of that. With the current set up of the hand-crafted wrapper, none of that is possible.

While a curious idea to tinker on, this wrapper generator is probably nothing I'd do on my own. Yet with this question I am trying to seed this idea, which might be picked up by some - and by extend then gives answer to the original question: Is there continued need for this hand-crafted wrapper?

[ptxmac]

I've been thinking about this for a while and have done a few experiments.

It's definitely possible, and it would make it much easier to support all features, new features, and even some of the special branches (like docking)!

Unfortunately, it's not the easiest generator to build.

Some of the problems I've seen so far:

• Some fields are changed by getting a pointer to a struct, and just updating fields, while other needs to be handled by calling a function.
  • E.g. Changing the DisplaySize is done using igGetIO().DisplaySize = ...
  • while getting the font atlas texture is a function ImFontAtlas_GetTexDataAsAlpha8( ... )
  • Creating a generator that creates a nice API that works for both is challenging
• cimgui makes no real distinguishing between "simple" structs that should be duplicated and more complex ones that should be updated through a handle
  • E.g. for Vec2 it sounds expensive to always call cgo when changing a value, so it makes more sense to keep a copy in go and do the conversion when needed
  • A struct like Context is much more complex, and changes happen less often, so it makes sense to simply keep a handle to C and update it
• There's a lot of pointer mess that needs to be wrapped correctly.
  • Getting the font texture happens usingvoid ImFontAtlas_GetTexDataAsAlpha8(ImFontAtlas* self,unsigned char** out_pixels,int* out_width,int* out_height,int* out_bytes_per_pixel)
  • Creating a generator that correctly figures out how unsigned char** should be represented in go and generates the correct wrappers is a bit messy

All can be solved, but I'm starting to think a hybrid approach might make sense; re-use large parts of imgui-go and try to make a generator that creates compatible code and slowly replace more and more of the handcrafted code.

[ptxmac]

I've taken another look at this. Currently just investigating if it would be easy to replace all the iggXXXX functions with the cimgui igXXXX counterparts. As a proof of concept, here's a commit that adds cimgui and replaces a single function: ptxmac@6237713

What's great about this is that since it's the same imgui.cpp underneath, the migration doesn't have to be completed in a single change!

[ptxmac]

@dertseha Any thoughts on the above approach?

[dertseha]

Thank you for the ping, and your patience.

I have a few thoughts to that, which I haven't consolidated yet or weighted against each other. (Order is random, simply following my train of thought)
First, using cimgui appears simpler from the code's perspective. As cimgui already hides the 'object oriented' layer, this moves the complexity from the imgui-go wrapper to there.
Following on that, assuming there is some formal description, adding a Go layer could be automated. (And yes, potentially not be compatible with the current state of imgui-go, which would be on the 'cons' side)

In parallel to that, I also see myself finding less and less time catering (I might even use the verb 'caring') for the wrapper - The main project I built that needs the wrapper hasn't updated the used version in ages - and I'm also not working on that project either for months.
So getting towards a path that automates the generation of the wrapper might be a long-term benefit, even if it drops one of the original main reasons for handcrafting it, such as conscious version compatibility or being idiomatic Go-idiomatic. Yet, with the volatility of the core ImGui API, version compatibility seems to be a too high goal for that anyway.

Looking over at the readme of cimgui, there is that meta-description with which such a wrapper generator can be automated.
Which brings me back to my original post: If there is a generator tool, I wouldn't need to depend on a regularly updated library if I can generate the code specifically for my project (splicing in other branches or plugins - assuming the meta-description exists.)

I see your point regarding the compatibility putting cimgui between ImGui and imgui-go . Yet I also ask what the long-term benefit is of going that path. I'd rather spend the energy creating the generator. As a user, I'd then be able to use the generator directly - instead of waiting imgui-go getting updated to a new underlying version and getting extended regarding any new functions.

Doing a quick search, there's a Lua VM for Go ( https://github.com/Shopify/go-lua ). I'm curious: Similar to your example for splicing in cimgui into imgui-go - how would (could) a generator look like?

[ptxmac]

The thought behind moving from the handmade c wrapper to the ones from cimgui is to make a generator easier to build. cimgui contains json definitions for all functions and types, and in theory we should be able to create a nice generator tool.

See https://github.com/cimgui/cimgui/tree/master/generator/output for the definitions

From experiments I've learned that there are a number of exceptions that need to be fixed by hand. One that comes to mind is the usage of varargs. cgo have no support for varargs, so all cimgui functions that take format style strings are problematic, and can't easily be auto-generated.

[dertseha]

I'm with you that there will be some exceptions that cannot be easily or properly handled by a generator. For these cases, there could be an exception list and still a small section of handcrafted wrappers. Doing a quick search, there are only a few functions with varargs and doing specialized exceptions is perfectly fine.

What I am still not sold on is why we should consider changing the internals of imgui-go - or how it helps regarding a generator. I believe we agree that we want to have a generator, that provides Go code with an API, and internally calls cimgui (With the hand-crafted exceptions as mentioned).
The Go code that this generator creates should, in my view, already be the code that the user would call. In my view there is no inkyblackness/imgui-go in play: As a user, I'd fetch that generator as a separate tool and let it run with my parameters that I chose (with drag'n'drop, no extra windows, ...). The generated code is then in a subfolder of my project. Because this generated code will be specialized to the parameters of the user there's no need to make this generated code available as a library.
This is what I meant, in my original post, that go-gl/gl (the generated code as a lib) is rather a crutch than a "useful" library. Users should only use go-gl/glow (the generator) directly - and I see this similar with the generator we are discussing here.

Said differently: I'd like to be able to freeze & archive imgui-go and instead have such a generator.

[ptxmac]

Looks like Allen Dang has made this in the meantime!

https://github.com/AllenDang/cimgui-go

[dertseha]

This is awesome, thank you @ptxmac and also @AllenDang !
This then means there's a migration path to potentially sunset this handcrafted wrapper.

[ptxmac]

For completeness, here's the announcement post on r/golang:
https://www.reddit.com/r/golang/comments/ws3e89/announce_cimguigo_an_autogenerated_wrapper_of/

[dertseha]

I've decided to prepare for discontinuing imgui-go in favour of that wrapper.

[ptxmac]

I finally had some time to play around with cimgui-go and looked at what's needed to replace imgui-go.

The current implementation uses imgui's GLFW backend, so it comes with a hard dependency on GLFW.
To work around that I've created a fork ptxmac/cimgui-go which puts the GLFW backend behind a build tag so it can be skipped.

I've also rewritten the imgui-go-examples to use the new library, and the conversion is almost seamless (cimgui-go doesn't provide as many default parameters, so the code becomes a little more verbose)

[AllenDang]

@ptxmac I'm trying to generate a convinient version of function with default arguments, seems like 90% of functions could be generated.

[ptxmac]

I think that would be great, perhaps follow the convention from this project and add V to the long version of the functions.

E.g.
Begin(name string)
and
BeginV(name string, open *bool, flags ...)

[AllenDang]

Agreed