Possibly add a version of the bindings with "internal" turned off

[4bb4]

Hi there, thanks for keeping these bindings up to date, I use them every day in several projects via my Rust bindings that build on them.

One snag I have run into is that the version of the bindings in this repo has the internal API exposed, which is nice in terms of enabling the most APIs for users, but unfortunately gets me into trouble (I think, maybe I'm just doing something wrong) with the imgui Rust bindings that use a cimgui version without the internal API exposed (see imgui-rs/imgui-rs#395 (comment)).

I considered forking cimplot and running the generator with the internal flag off or vendoring everything altogether in implot-rs, but of course it would be even nicer to have both a version with "internal" and one without it already in the repo here.

What do you think? Thanks in advance for any help or advice.

[sonoro1234]

I try to avoid the burden of having both versions.
What happens when you use this repo with no_internal cimgui?

[4bb4]

Thanks for the quick reply!

I try to avoid the burden of having both versions.

Alright, then I'll come up with a solution on my end. I think I might take implot as a submodule and vendor in a no-internals version of cimplot created with your generator along with an attribution note and backlink to the repo here.

What happens when you use this repo with no_internal cimgui?

The build fails because "cimplot with internals" requires symbols from "cimgui with internals" - at least that was the conclusion I came to when trying to get things to work. I don't think it is possible to switch imgui-rs to use the imgui internals without forking the repo - there is an issue for adding support for this, but it does not look to be resolved soon.

[sonoro1234]

The build fails because "cimplot with internals" requires symbols from "cimgui with internals"

Do you have a compiler error with symbols missing?
Could you post it?
As far as I know it should not happen.

[4bb4]

I'll try to come up with one - it has been a while since I've done those experiments, the reason I opened the issue today is that I thought I could get back into things and this might help. The fact that you say things are expected to work is already very good input for me, it makes me suspect that I am doing something wrong on my end. I'll go experiment a bit (might take a while, I'm not sure if I'll get to it today) and get back to you once I have some results.

[4bb4]

Another question for me to experiment with: The imgui-rs version I point to seems to vendor in an older version of cimgui from back in april, so I am not sure which version of cimplot I should pair this with to try and get things working. If I naively try out the current master, I get errors in the bindings generation process with bindgen about ImRect and ImPoolIdx being missing:

[...]
.../cimplot/cimplot.h:64:94: error: unknown type name 'ImPoolIdx'
.../cimplot/cimplot.h:66:76: error: unknown type name 'ImPoolIdx'
.../cimplot/cimplot.h:68:76: error: unknown type name 'ImPoolIdx'
.../cimplot/cimplot.h:70:82: error: unknown type name 'ImPoolIdx'
.../cimplot/cimplot.h:439:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:468:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:486:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:488:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:501:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:502:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:503:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:504:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:515:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:516:5: error: unknown type name 'ImRect'
.../cimplot/cimplot.h:583:5: error: unknown type name 'ImRect'
[...]

... and, looking around imgui, I find that type in the imgui_internal.h C++ header here.

I'm not sure what follow-up things to ask, because I don't want to waste your time with problems specific to the way I create and build my Rust bindings - I just describe things here in case there is something super obvious you can help me with without having to deal with all the details.

[sonoro1234]

You could try to compile implot examples with the imgui present in back in april
If it complains then you should change to an older implot until you find a compatible one.

It is strange because ImRect is quite old (Perhaps in your compilation you are forgetting to include imgui_internal.h?)
But this shouldnt be as cimplot.cpp already includes imgui_internal.h

[4bb4]

Thanks for the hints, I'll do more experiments.

Perhaps in your compilation you are forgetting to include imgui_internal.h

So far I have been using cimplot so I can create an FFI to a C API - if that C API requires the inclusion of a C++ header, I have to deal with C++ code at the FFI boundary, and then I might as well attempt to create bindings to the C++ code directly. Maybe I am just confused though and am missing the point.

But this shouldnt be as cimplot.cpp already includes imgui_internal.h

For cimplot.cpp things should be fine (that is a C++ build anyway), but cimplot.h itself refers to things like ImRect as well (for example here). If paired with an internal-enabled version of cimgui, a C version of ImRect is available here, which works, but for the combination of an non-internal-enabled cimgui and an internal-enabled cimplot, I don't yet see a way to create bindings using only C headers because types like ImRect and ImPoolIdx are not available as C types.

In any case, the original issue is answered and I'll see if I can work around the problem in implot-rs itself a bit, so we can close the issue I think.

Thanks for all your help!

[sonoro1234]

If paired with an internal-enabled version of cimgui, a C version of ImRect is available here,

But this is not docking_inter branch but master branch. (In dockin_inter ImRect is found in https://github.com/cimgui/cimgui/blob/docking_inter/cimgui.h#L1390)
In cimgui repo, master branch it is the no internal branch (the same used by imgui-rs)

[sonoro1234]

Update: without internal in cimgui and internal in cimplot compilation succeds but the problem appears in the part of cimplot.h revealed with CIMGUI_DEFINE_ENUMS_AND_STRUCTS, used in the binding generation, where ImPoolIdx is not defined.
Solutions are:
1 - generate cimplot without internal
2 - generate cimplot with internal but manually add ImPoolIdx definition (and posibly others) doing cut and paste from cimgui.h (with internal generation) to the part in cimplot.h under CIMGUI_DEFINE_ENUMS_AND_STRUCTS

[4bb4]

Thanks for looking into this further! I did not yet get around to do more experiments, but I'll see if I can make one of your two suggestions work.