Closed nlbuescher closed 3 years ago
I haven't looked at the imgui
docking
branch yet. So I have no idea if I have to tweak the generator to make it work but it's unlikely.
We can have a branch and separately tag it with *-docking
and it should work. Keeping it in sync with master
might be awkward.
Have you used the docking branch of imgui?
I have. Basically it works exactly the same, it just exposes a few extra flags for enabling docking and viewports which aren't in master right now. I will say though that my usage of imgui before this library was through the C API alone. I'll try and see what happens if I just switch cimgui master for docking in a new branch. The API should be the same mostly.
Do you happen to know off the top of your head what the ImVec2_Simple
is? SWIG generates a binding for it, but it doesn't exist anywhere other than the SWIG-generated files.
EDIT: nvm I needed to run the runSwig
task
I'm running into a few issues, ironically mostly related to API changes from 1.76, since the docking branch is more up to date than the version used by kotlin-imgui currently. I can't get the codegen to run successfully because of it, so it might be worth updating master to the newest version, not to mention the issue that Gradle sync won't complete because of some IntelliJ bug which makes working with the code a lot harder. I've managed to narrow down the problem to the implementation(project(":cimgui"))
line in the native target dependency declarations in the imgui build.gradle, but I haven't found a workaround yet.
Oh, that's unfortunate. I'll take a look now.
Will have to file a bug report :weary: but the problem is the withJava()
https://github.com/Dominaezzz/kotlin-imgui/blob/05d5cf0cc69fa9e62384dad7f1fa3192b24d17f6/cimgui/build.gradle.kts#L150
I'd happy get rid of it but it's needed for SWIG. In theory I could create a java only project but.... this is quickly getting out of hand.
Commenting it out should get IDEA to behave for now.
It seems cimgui now includes imgui_internal.h
when extracting metadata into JSON files. Which breaks codegen. https://github.com/cimgui/cimgui/issues/139
I'll put in a few kludges for now.
This (https://github.com/Dominaezzz/kotlin-imgui/pull/8) should unblock you for now. I'll do a review later to decide whether or not to expose imgui internals, after which I'll merge it in to master.
I got the thing to compile! Changes I made:
:cimgui
jvmTarget creation fails on all targets because jvmTargets are created for all platforms although they should only be created for the current platform while developing. Need useSingleTarget || HostManager.is...
logic.igImFormatStringV
needs to be ignored in cimgui.i
because va_list parameters don't work with SWIGenumName.endsWith("FlagsPrivate_")
-> enumName.endsWith("Private_")
because not all Private enums were excluded with the other.ImGui.dockBuilderAddNode(nodeId: ImGuiID = 0, …)
doesn't compile because Int != ImGuiID
. Maybe ImGuiID
should be a typealias instead of an inline class? Or maybe declare a constructor for the expect declaration of ImGuiID? I manually removed the default value for now.ImGuiDataAuthority_
and ImGuiDockNodeState
to nonstrict enums in cimgui.def
to enable proper value conversion.igComboFnPtr
-> igComboFnBoolPtr
, etc)I'll create a new branch, push it, and see if I can create a pull request into a non-existent branch so you can take a look.
Awesome! I'll cherry pick fixes related to the 1.76
upgrade to get it to build.
About ImGuiID
, it'll need to be added to the list of special cases for default values in the generator.
Although, does ImGuiID
mean ID with value 0 or no id (null
).
I also noticed some enum names (like this file) started with underscores, which will have to be investigated.
Good question... the implementation in ImGui seems to create a new node if the id is 0, so it might be a good use of null, although that might make the codegen more difficult.
the underscore prefix in the enum values is a result of enums whose C name doesn't end with an underscore: enumValue.name.removePrefix(enumName)
. Fix would be to add a .removePrefix("_")
or something like that
Or maybe declare a constructor for the expect declaration of ImGuiID?
I didn't realise that ctor wasn't declared in common. Which do you think is better?
ImGuiID.Nil
(or similarly named) in common code.I brought up the latter as it seems only imgui creates ImGuiID
s.
null
might be more effort than it's worth.
Also, looks like the IDE issue has been reported already KT-38037.
Out of those two options, I think a common ctor is better, but I think the best option is to use a nullable with a default null
. Conceptually, the default 0
represents "No ID". How difficult does that make the codegen?
It shouldn't be too bad. I think I've done something similar for a different class.
The issue now becomes, should all ImGuiID
parameters be nullable or just the ones that have default of 0?
technically depends on the implementation. If there is no check for 0 in imgui, it needn't be nullable. I'll check
I've reconsidered. I feel like we shouldn't change the semantics of the library by introducing nullable parameters where 0 is already being used for "No ID", and 0 is used for "No ID" all over the codebase.
To be clear, adding nullability here would only introduce boxing (and proportionally diminish performance) without adding any benefit.
:grinning: Common ctor it is!
I cannot get the docking branch to build as a dependency to save my life. I've tried:
I've literally tried every single combination, but cannot seem to get the docking branch as a dependency. I have the repo setup, as I can get the main branch's latest version, but I could really use some help with getting docking setup. Please publish to docking branch somewhere for ease of use, I don't think it should be necessary to build the whole project in order to have it as a local dependency. I might be missing something but I seriously would like to be able to use the docking branch but cannot seem to get it working with my gradle project.
It's not finished, and no publication is available yet.
In the meantime for testing, you can do the following:
.m2
folder in your user directory)mavenLocal()
to your repositories block in the dependent project@MrManiacc We're working on it, but with Kotlin 1.4 coming soon, making sure kgl
and kotlin-imgui
work with 1.4 has taken priority. It's certainly not intended that you need to build docking yourself.
@MrManiacc We're working on it, but with Kotlin 1.4 coming soon, making sure
kgl
andkotlin-imgui
work with 1.4 has taken priority. It's certainly not intended that you need to build docking yourself.
I've gotten it building locally, but it's not ideal. I'll be looking for the official build of the docking branch. Is there a ETA, or even a rough estimate of when that might be published?
I got docking working, but cannot seem to get viewport working, i've tried enabling it via
io.configFlags = io.configFlags.or(ImGuiConfigFlags.ViewportsEnable)
but it crashes with an error message of
Assertion failed: g.PlatformIO.Platform_CreateWindow != 0 && "Platform init didn't install handlers?", file E:\imgui-kotlin\kotlin-imgui\cimgui\build\downloads\cimgui-docking_inter\imgui\imgui.cpp, line 7482
however, this seems to working
io.configFlags = io.configFlags.or(ImGuiConfigFlags.DockingEnable)
How are you setting up? You can check the samples subproject in the docking branch for a working sample with viewports
I've gotten the viewport working, but when I drag a child when off the main viewport, the window disappears, it shows the separate window on the task bar, but when I hover over I see nothing and there's no display or any sign of the window anywhere. Also on a side note, it seems ImGui.setNextWindowSize
and ImGui.setNextWindowPos
don't work what so ever.
Here is my display class, please ignore the sloppy code, it's temporary and for testing. display.kt
Hi @MrManiacc, which OS are you on and which target (JVM or Native) are you using?
@Dominaezzz I'm using windows 10, JVM.
As far as I can tell, the only way to have a set size on a window is by using the imgui.ini which is not ideal.
I reproduced it.
The fix is to change this line https://github.com/Dominaezzz/kotlin-imgui/blob/9de3f6b72da46c2258bd3b037d6fdb61edaa2602/imgui-glfw/src/jvmMain/kotlin/com/imgui/impl/Utils.kt#L58 from dcbArgDouble(args).toBits().toULong()
to dcbArgLongLong(args).toULong()
.
Shame it's not consistent across OSes.
it seems ImGui.setNextWindowSize and ImGui.setNextWindowPos don't work what so ever
Seems like an upstream problem?
@MrManiacc I checked what effect adding ImGui::SetNextWindowSize
has using a C++ sample with upstream ImGui docking, and it seems to have no effect, so either the usage is wrong, or the feature is broken in upstream.
I got docking working, but cannot seem to get viewport working, i've tried enabling it via
io.configFlags = io.configFlags.or(ImGuiConfigFlags.ViewportsEnable)
Did you try this https://github.com/ocornut/imgui/blob/docking/examples/example_sdl_opengl3/main.cpp#L219 ?
Also: If you dont use impl_xxxx provided by imgui itself (something I would recommend to use as told in https://github.com/cimgui/cimgui/issues/135) you should look for all things needed if ImGuiConfigFlags.ViewportsEnable
is set.
Separate publication is live and built with Kotlin 1.4.10.
imgui
, and by extensioncimgui
, support viewports and window docking in a separate branch. Would it be possible to publish a separateimgui-docking
artifact based on that branch?