ImGui 1.60 about cimgui HOT 19 CLOSED

My next experiment is going to be an automatic extraction of structs and enums from imgui.h
Would be great for the future.

from cimgui.

Hi Victor,
thanks for your support. Since imgui 1.60 is not yet released and WIP I agree that it should not be in the normal release branch yet. I am looking forward to merge it in once it is officially released, feel free to open a PR already with the current status so that people have an easier time finding it. Once 1.60 is release I would like you to update the branch with a squashed single commit to merge it in.

Cheers,
Stephan

from cimgui.

Ok.
You will have to explain me how to do "a squashed single commit to merge it in" when time arrives.

from cimgui.

thanks!

sure, squash is basically a way to merge multiple commits into one. its a special form of rebase. see here: https://stackoverflow.com/a/5189600

and here: https://github.com/k88hudson/git-flight-rules#i-need-to-combine-commits

from cimgui.

never mind i just realize i can do this when merging the PR on my end! Thanks again! :)

from cimgui.

FYI now that 1.60 is out, I will attempt to make smaller releases onward to facilitate and/or encourage easier/smaller/incremental upgrades.

One thing I may suggest would be to tag cimgui version to match the imgui tags (v1.60 etc.)
Since this repo doesn't have many commits it should be easy to retroactively tags versions.
I also believe it is fine to move on the cimgui tags if a fix is being made after the initial port, pointing to the latest cimgui version for a given imgui version.

Based on that idea:
v1.53 1a5e261
v1.52 fa1b93b
v1.51 6a31578
v1.50 516547d
etc

from cimgui.

@ocornut thanks I know 1.60 is out. On the weekend latest I will grab this branch and adapt whatever is missing. but yeah smaller releases would make it much easier.

Actually I already use those git tags to match your releases. The only difference so far is that I never moved them to add fixes, that I could do in the future actually.

from cimgui.

Actually I already use those git tags to match your releases. The only difference so far is that I never moved them to add fixes, that I could do in the future actually.

Oops, my apologies! I have no idea how I missed them, I think on github I often expect to see them under "branches" while they are merely one click away. Sorry!

from cimgui.

@ocornut I have updated to tag 1.60 in my branch 1.60 and everything got broken:
CHANGELOG.txt breaking changes is not enought: when you add to imGUIio ConfigFlags member all the ffi binding has to be updated. I will try to read all changes done (not only breaking changes)

from cimgui.

from cimgui.

1.60 is merged now thanks to @sonoro1234. I will check it out in one of my projects tonight and then set the final release tag!

from cimgui.

@extrawurst It is not ready. As I told above structs are not according to 1.60 already

I am working on automatically generating enums and structs.
My first problem now is the differences between cimgui.h structs and imgui structs:

In cimgui you have

struct ImVec2
{
    float x, y;
};

struct Other
{
    struct ImVec2 foo;
};

while in imgui.h (being C++) would be:

struct ImVec2
{
    float x, y;
};

struct Other
{
    ImVec2 foo;
};

finally my solution is:

struct ImVec2
{
    float x, y;
};
typedef struct ImVec2 ImVec2;
struct Other
{
    ImVec2 foo;
};

Do you agree with this solution for structs in cimgui.h or this would break something?

from cimgui.

Other question:
why
https://github.com/Extrawurst/cimgui/blob/master/cimgui/cimgui.h#L45

from cimgui.

Everything working here except glyphs which I am investigating

from cimgui.

The problem was with ImFontAtlas nested structs (CustomRect and GlyphRangesBuilder) which must not be nested in C

from cimgui.

@extrawurst
My 160 branch works now.
My last commit provides a way to automatically generate imgui_structs.h which can be included in cimgui.h by defining CIMGUI_DEFINE_ENUMS_AND_STRUCTS when you need to generate your binding as I am doing in LUAJIT-imgui

This is a working base for adding (not automatically by the moment) the new function wrappers needed in 1.60

Now the PR cant be merged because it was partially merged before.
Perhaps last merging should be reverted before applying the new PR?
Or better revert in master and apply new PR to a new branch (master1.60?) until finished.

from cimgui.

Now I am begining the work for function generation. The main problem happens with overloaded function names. I would like to make naming algorytmic but already used names in cimgui which other people use in its binding should be taken in account.
For more on this see ocornut/imgui#1782

from cimgui.

sounds like a good idea. you could whitelist the overload names in an automated approach

from cimgui.

@extrawurst last PR merge was incomplete and master is broken:
#49 (comment)

Now the PR cant be merged because it was partially merged before.
Perhaps last merging should be reverted before applying the new PR?
Or better revert in master and apply new PR to a new branch (master1.60 or master_auto?) until finished.

from cimgui.