Stable branch of Kotlin support about imgui HOT 15 CLOSED

Let's add stable branches then, it'll be a win for anyone using it being able to choose. The stable branches might be a few days behind the repos that updates often, but that's ok.

from imgui.

Here you go, I just updated the whole dependency, it should now relies purely on kt 1.2 :)

from imgui.

Thank you very much Guiseppe, and Merry Christmas and Happy New Year to you too!

from imgui.

Ok so, I created a new branch for that and a new release, I just tried on my machine and with few modifications it seems working flawness

Anyway, I have very few time and I'd like to focus on bugs and other lib dev (in primis assimp and bullet), so.. would you mind becoming a collaborator and taking care of this branch? Because I need help as oxygen at the moment..

from imgui.

I would love to help and as I haven't gotten the chance to try imgui yet I will do that first. Probably on thursday as it seems now.

I think there won't be overwhelmingly much to do in this branch, just catch up with changes when necessary. I guess I can handle that without disappointing anyone. =)

from imgui.

I thought I would take a quick look at it by adding the v1.52_Kt_stable to my build, but to my surprise it now asks for kotlin 1.2.0-rc-39, both the stdlib and reflect (and imgui doesn't even have reflect as dependency). I cloned the stable branch and yes, it has the correct dependency in its build script.

So what could have caused this? Reading more into the actual error messages I can see the release itself has dependencies to other (release-) libraries that in turn has dependencies on kotlin 1.2.0-rc-39, (uno-sdk, gln, gli, glm, kotlin-unsigned).

I added the kotlin-dev repo to my own build too, but it caused a classpath clash with several multiple kotlin libraries with this warning:

w: Runtime JAR files in the classpath should have the same version. These files were found in the classpath: C:/Users/tkarlsson/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jre8/1.1.51/cc8e639ff087472268912159cd66c01f2765c657/kotlin-stdlib-jre8-1.1.51.jar (version 1.1) C:/Users/tkarlsson/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-jre7/1.1.51/8b5933578dc55f32cfc1a25f1db6371e4161fb8f/kotlin-stdlib-jre7-1.1.51.jar (version 1.1) C:/Users/tkarlsson/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.2.0-rc-39/bf7ecf7feffe6fdaf845551744bc74925609caf8/kotlin-reflect-1.2.0-rc-39.jar (version 1.2) C:/Users/tkarlsson/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.2.0-rc-39/150364e2db860fb6912ff0d681b8a5ca2d7ca00d/kotlin-stdlib-1.2.0-rc-39.jar (version 1.2)

It "works" as in that it runs when using multiple stdlib.

While using the dev branch from bintray we should add that to the install instructions, as it won't work for production branches without it.
maven { url "https://dl.bintray.com/kotlin/kotlin-dev" }

Maybe we're better off just waiting for 1.2 to be released, should be soon after all, and make the whole series into stable-branch-first approach if it's possible? I can still find time to help.

from imgui.

Damn, yeah, that makes.. all the dependencies are based on the rc..

I guess we have to find for a more future proof solution, because I always jump on the latest version of kotlin available. The first quick and dirty solution it comes in mind is to have the same double release process (rc/whatever and stable) for each dependency..

Anyway originally I thought about putting all the jars (rc and stables one, with a small naming modification) in the same release, but this cannot work with jitpack I think, because there is no way to tell which jars to download under the same release: it always fetches based on the tag..

Howver, feel free to add that in the install instruction :)

from imgui.

I would guess all libraries are on kotlin 1.2 now and that makes KtStable superfluous, or what do you think?

from imgui.

I'm gonna upgrade sooner or later everything to 1.2, so that you could have a truly kotlin 1.2 dependency

However, I'd say that KtStable isn't superfluous because I'm gonna jump on the next EAP as soon as it comes out..

from imgui.

Oh, nice! Is there anything you want me to do?

from imgui.

Could you give me a confirmation on your side that is it really so? No other old/weird kotlin rc dependencies?

from imgui.

Yeah I will give it a try when I'm in the right spot at the right time!

from imgui.

Ok Tobias, here we go again, kt 1.2.20 eap 11 is out.. how shall we continue?

I already branched all the dependencies to have kotlin stable dependency. And this was fine.

However what I disliked was that I also published aside the normal releases, a release also for the stable branch.

Now, my question is, do you need the stable-releases? Because if just pulling by commit id from the stable branches is enough then I'd skip completely to publish stable releases and mixed up things

from imgui.

I'm a bit torn about it too, as we've never had any stable branch of the libraries that imgui is tightly coupled to there will always be a mix of versions and most likely serious conflicts in any project using this library, as the project grows.

It also doesn't make much sense having a whole separate branch just to change one line, there just has to be a better way to deal with it, but the only way I know as of now is to somehow clone all the libraries into one project and set it to use the project version of kotlin. This would be some work but could be worth it, although the tight coupling to lwjgl and opengl makes it hard to be sure it can be used as library instead of just an addon to those frameworks.

So I made a test framework for a fully agnostic rendering/drawing engine, with the goal of having it fully working with intellij autocomplete and such, just to see if it would be possible with Kotlin. Java itself are always bound by the interface so library specific methods can never be seen automatically by the IDE. This worked though, using Kotlins amazing generics! This means it is possible to do this kind of abstraction and IDE magic in Kotlin, which in itself is totally awesome!

This might be above both your and my paygrade in regards to the amount of time it takes to achieve these abstraction libraries as everything in imgui is tightly coupled to one solution now.

So, if noone else wants the release for kotlin 1.2, 1.3 and so on, I think we should remove it and avoid the infinite loop of merging with master, as no source code is changed anyway between the branches.

Have a very Merry Christmas and a Happy New Year, Giuseppe!

from imgui.

Hi Karlsson,

since a while I kind of followed your suggest and relying only on stable versions of kotlin stlib.

So, I'd say this issue can be marked as solved nowaday

it took a while but we finally made it :D

Anyway, it's almost Christmas again, so let me wish you also a Merry Christmas and a Happy New Year

Ciao!

from imgui.