Separate publication for `docking` branch?

imgui, and by extension cimgui, support viewports and window docking in a separate branch. Would it be possible to publish a separate imgui-docking artifact based on that branch?

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 😩 but the problem is the withJava()

kotlin-imgui/cimgui/build.gradle.kts

Line 150 in 05d5cf0

withJava()

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. cimgui/cimgui#139
I'll put in a few kludges for now.

This (#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 SWIG
enumName.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.
add ImGuiDataAuthority_ and ImGuiDockNodeState to nonstrict enums in cimgui.def to enable proper value conversion.
update handwritten JVM and Native code to reflect new type inclusive API (ie 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?

Declared ctor in common
Only expose a ImGuiID.Nil (or similarly named) in common code.

I brought up the latter as it seems only imgui creates ImGuiIDs.

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.

😀 Common ctor it is!

I cannot get the docking branch to build as a dependency to save my life. I've tried:

com.kotlin-imgui:imgui:*-docking
com.kotlin-imgui:imgui:-docking
com.kotlin-imgui:imgui:docking
com.kotlin-imgui:imgui:docking-SNAPSHOT
com.kotlin-imgui:imgui:9de3f6b72da46c2258bd3b037d6fdb61edaa2602
com.kotlin-imgui:imgui:9de3f6b

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:

Clone the docking branch, and run the "publishToMavenLocal" Gradle task. I'd make sure to change the version in the main Gradle build file to something like "docking" so you know what to put for the version (If you don't change it, you can check what it ended up using by looking in the .m2 folder in your user directory)
Add mavenLocal() to your repositories block in the dependent project
Add the dependency with version "docking" (or whatever you changed it to)

@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 and kotlin-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

kotlin-imgui/imgui-glfw/src/jvmMain/kotlin/com/imgui/impl/Utils.kt

Line 58 in 9de3f6b

val value = dcbArgDouble(args).toBits().toULong()

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 cimgui/cimgui#135) you should look for all things needed if ImGuiConfigFlags.ViewportsEnable is set.

Separate publication is live and built with Kotlin 1.4.10.