Imgui: Pure java port in progress

[elect86]

Hi guys,

we (me at the very moment) are working on a pure java port of imgui here

don't hesitate join and participate, we need help trying to make it as good as the original :)

[unpacklo]

Are you doing a full port of the original source? Is it not possible to
just create bindings that call into the public imgui API? Seems like it
would be a monumental task otherwise...

On Tue, May 24, 2016 at 8:51 AM, Giuseppe Barbieri <[email protected]

wrote:

Hi guys,

we (me at the very moment) are working on a pure java port of imgui here
https://github.com/jovr/imgui

don't hesitate join and participate, we need help trying to make it as
good as the original :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/ocornut/imgui/issues/671

[elect86]

Yep.

My intention is to have a pure java imgui in oder to greatly simplify the dependency, just add a jar and having the whole imgui available.

It's possible of course to create the binding, but this would imply to deal with all the C world headaches..

My goal is to do the most fedele port as possible in order to reduce at minimum all the future modifications. I already did that for glm and gli, in progress for assimp, and it works great, I can catch up months of commits in few hours.

I already ported (almost) all imgui.cpp, imgui.h and imgui_internal.h. I am on my way now on imgui_draw.h and imgui_impl_gl3.

I paid also attention to report all the original comments, regarding functions/structs/variables

[ocornut]

simplify the dependency,
It's possible of course to create the binding, but this would imply to deal with all the C world headaches..

But you are less likely to fully complete and maintain a full port, so using a binding sounds more pragmatic and realistic to me. Either way, it is your project :) I don't know anything aobut the Java ecosystem.

[elect86]

Yep, that's the only disadvantage.

Let's say it's the typical double edge sword, althought even the binding option requires some sort of minimal mantainance if any call/arguments in the original code changes, less likely of course but always present

[ocornut]

Closing this as agreed. I have added an entry to https://github.com/ocornut/imgui/wiki/Links

[elect86]

So.... after jumping on the Kotlin train, I took back this project and upgraded to this new cool jvm language, totally Java compatible...

I also synchronized it to the very last modification: tens of commits in just an hour or so

Fixing a couple of bugs, but the core is there!

[ocornut]

Nice! How much of it is functional at the moment?
Monumental amount of work, it still sounds quite crazy to maintain that sort of thing!

[elect86]

At the very moment, windows (and its component: tilebar, tooltip), glyphs/text, windows selection, moving and resizing

I am hunting a couple of bugs down now about the window resizing, the minimum size doesnt get respected and another about screwing the text when you resize the window too small and then make it bigger again

Well, it's about 16k loc.. kotlin is quite expressive

Regarding all the stb stuff, at the very first I attempted a port, but then I ended up using lwjgl binding, this offloaded me of a lot of shit work..

It may sound weird, but actually maintenance is really a light task. Since I sticked as much as possible to the original code (as far as possible in the terms of a cpp -> kotlin translation), I can catch up really quickly, even by simply browsing the commits on github and looking at the deltas.

[elect86]

Hi Omar!

so, I am on my way to catch up with your fantastic gui.

I am using the test window to test (and finish to implement) all the stuff.

But I noticed something wrong... this

render this

and Scrolling Text %d is not completely visible.. is this a bug or misuse?

[ocornut]

It's a misuse/feature lacking, the child window here is created with a width of (0) with uses the remaning parent (menu) window size. There's currently no way for a child window to feed it's size back into the parent.

[elect86]

shouldn't be this line

else { *v = arg0; }

instead

else { *v = arg1; }
?

[ocornut]

It is correct with arg0. In doubt run the C++ code and test it.
The ImGuiDataType_Int is scanning and using an int for assignment, only the binary operators are using a float value for the right-side.

[ocornut]

Perhaps for clarity the variables should be named arg0i and arg1f in the ImGuiDataType_Int path, and arg0f arg1f in the ImGuiDataType_Float path to reduce confusion for the reader.