kotlin-graphics/imgui

Clarifying title/project name

Closed this issue · 3 comments

Hello,

Could you put more emphasis on the fact this is not exactly dear imgui but a rewrite?

  • I think the word "port" is misleading and using the word "rewrite" would be more clear and appropriate to the casual reader? (both to suggest that it doesn't provide the guarantee that dear imgui provides, but also suggesting your version may be a better fit for java/kotlin users)
  • Change the title of the page and in licence at the bottom from e.g. "dear imgui" to "dear jvm_imgui"
  • I also feel renaming the repo e.g. kotlin-graphics/imgui/ to kotlin-graphics/jvm_imgui (or another name) would help convey this. (Note that github redirect old repo names.)

They are merely suggestions, and I see there are already efforts to reduce ambiguity but I believe there's still a lot of possible confusion for the reader. Those are the suggestions I have here.

Thank you!

Hello Omar!

Yeah, sure

as you see there are already links and descriptions to your original library and your work (with credits and description of your development process at the end) and I believe port is equivalent to rewrite, it's also very common in the jvm world

Nonetheless if you think there might be still some space for confusion, I'll do as you suggest to be double sure people don't misunderstand, since I have absolutely nothing against it and I own you this very nice gui :)

so, I just committed:

  • I replaced all five port occurrences with rewrite in the readme
  • changed the title of the page and the license at the bottom from dear imgui to dear jvm imgui
  • regarding the repository renaming, I kind of dislike it. I had myself this doubt very long time ago and I decided against for various reasons I'll tell you now

First of all, because if I do rename the repository, I shall do the same for all the others for coherenc:, this mean assimp, openvr, gli, glm, ovr and bullet will all become jvmAssimp, jvmOpenvr, jvmGli, jvmGlm, jvmOvr, jvmBullet...

What about the others, since they don't have have a c++ counterpart, and gln too which also fits directly within glm and gli, it wont be usually listed together with the two just mentioned (with alphabetical order).

I also kind don't particularly love camelCase projects names (it makes harder to distinguish capital i from l) or names containing _ in the middle (some IDEs, such as Netbeans, will ctrl-jump the whole world).

So at the end we would end up with a lot of projects starting with the same name jvm*.

Also this noise will be in the IDE, as you will see tons of jvm* everywhere (which we already do often for others stuff) and in the emails when you get replies/notifications (the source is always clear because the organization/owner name is always present).

Moreover, I really love very short (conciseness is also one of the main reasons of my preference for kotlin), syntetic and lower names (I plan even to change uno-sdk to simply uno and Vulkan to vulkan).

I find it also fits quite nicely with the way we declare dependencies using Gradle in our build.gradle.

This is also the same reason I didnt standardized also the repository name it when you prefixed at the time all the imgui occurrences with dear (althogh I see you also didn't change the repo, probably on the same wave of mine)

Anyway, to overcome this last point, I added this explicit sentence (rewrite of dear imgui) right in the project description, which is visible directly at first sight at the organization level. This will be also visible at first sight in google once its cache gets updated.

I hope you will appeciated (and understand) :)

Thanks a lot, this is more than good enough for me!
I didn't realize you had a whole ecosystem of library and agree it makes sense to keep the /imgui repo name in your case.
Good luck ahead!

Glad to read that..

Ps: forgot to say, I also added It doesn't provide the guarantee that dear imgui provides, but it is actually a much better fit for java/kotlin users. at the beginning paragraph