search

Dominaezzz / kotlin-imgui

Kotlin bindings for Dear ImGui
MIT License
83 stars 4 forks source link

Separate publication for `docking` branch? #7

Closed nlbuescher closed 3 years ago

nlbuescher commented 4 years ago

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?

Dominaezzz commented 4 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?

nlbuescher commented 4 years ago

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.

nlbuescher commented 4 years ago

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

nlbuescher commented 4 years ago

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.

Dominaezzz commented 4 years ago

Oh, that's unfortunate. I'll take a look now.

Dominaezzz commented 4 years ago

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.

Dominaezzz commented 4 years ago

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.

Dominaezzz commented 4 years ago

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.

nlbuescher commented 4 years ago

I got the thing to compile! Changes I made:

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.

Dominaezzz commented 4 years ago

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.

nlbuescher commented 4 years ago

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

Dominaezzz commented 4 years ago

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?

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

null might be more effort than it's worth.

Dominaezzz commented 4 years ago

Also, looks like the IDE issue has been reported already KT-38037.

nlbuescher commented 4 years ago

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?

Dominaezzz commented 4 years ago

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?

nlbuescher commented 4 years ago

technically depends on the implementation. If there is no check for 0 in imgui, it needn't be nullable. I'll check

nlbuescher commented 4 years ago

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.

nlbuescher commented 4 years ago

To be clear, adding nullability here would only introduce boxing (and proportionally diminish performance) without adding any benefit.

Dominaezzz commented 4 years ago

:grinning: Common ctor it is!

MrManiacc commented 4 years ago

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.

nlbuescher commented 4 years ago

It's not finished, and no publication is available yet.

In the meantime for testing, you can do the following:

  1. 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)
  2. Add mavenLocal() to your repositories block in the dependent project
  3. Add the dependency with version "docking" (or whatever you changed it to)
nlbuescher commented 4 years ago

@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 commented 4 years ago

@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?

MrManiacc commented 4 years ago

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)

nlbuescher commented 4 years ago

How are you setting up? You can check the samples subproject in the docking branch for a working sample with viewports

MrManiacc commented 4 years ago

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.

MrManiacc commented 4 years ago

Here is my display class, please ignore the sloppy code, it's temporary and for testing. display.kt

Dominaezzz commented 4 years ago

Hi @MrManiacc, which OS are you on and which target (JVM or Native) are you using?

MrManiacc commented 4 years ago

@Dominaezzz I'm using windows 10, JVM.

MrManiacc commented 4 years ago

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.

Dominaezzz commented 4 years ago

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?

nlbuescher commented 4 years ago

@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.

sonoro1234 commented 4 years ago

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.

nlbuescher commented 3 years ago

Separate publication is live and built with Kotlin 1.4.10.