Principles for this lib.

[AllenDang]

Since we got a team now, lets create few principles to unify our thoughts.

I nominate following first:

1. Plug and use.
   The only thing this lib depends is go.
   A default backend sbould be provided somewhere.

2. Document and sample code from cpp should be easy to reference.
   So we may need to keep the naming as the same with cpp as possible.

3. Maximum automation.
   As the fact that imgui is constantly involving, we should aiming to generate wrapper automatically in most cases.

[eliasdaler]

"Default" backend can be ebiten-imgui. Less cgo - easier to fetch and build.

GLFW backend is okay too, but better be built with go-gl/glfw.

[AllenDang]

Ebiten looks better, i hate cgo because it makes it impossible to debug...

[AllenDang]

And here is my reason to reuse the backend inside imgui, imgui itself keep involving...
I met several times my backend stops working after upgrade imgui.

[eliasdaler]

Well, ebiten-imgui will need more development if something in Dear ImGui changes, but that's a given. It also doesn't support every GLFW backend feature, but it can be fixed with some work.

However, I've maintained ImGui-SFML for 6 years now and I rarely had to fix something because of ImGui changing things considerably. It happened like 3-4 times in 6 years and mostly was just "rename X to Y"

[eliasdaler]

"The only thing this lib depends is go."
Many wrappers around C libs require you to have a C compiler or a lib installed/compiled manually: go-gl/glfw, inkyblackness/imgui-go do compilation on the fly using cgo, sdl-go requires you to have SDL installed on your system and finds it via pkgconfig, etc.
But this allows you to not ship your library with a precompiled binary and doesn’t limit you to a set of platforms you built the lib for.

Do you know of any major Go libraries which ship with precompiled libs?

[eliasdaler]

My problem is not the size but the cost of building and redistributing binaries in the repo.
Is it even possible to compile cimgui-go on the platform for which we don't have pre-compiled libraries?

For example, see this branch. I've removed Windows lib. Is it possible to make cimgui-go work on Windows now with "go get" and some more actions? Or do you need to have a fork of cimgui-go? If the latter, then it's really bad.

On the other hand, look at imgui-go. It doesn't ship binaries. But you can "go get" it on any platform, run "go build ." with your app and it will just work, because cgo will compile the temporary static imgui lib for your platform.

[eliasdaler]

Also see this discussion. A while back Go team decided to drop precompiled ".a" files and a lot of Go usage now implies that you need to have a C compiler installed.

[eliasdaler]

Hmm, actually go-sdl ship precompiled libs: https://github.com/veandco/go-sdl2/tree/master/.go-sdl2-libs

[AllenDang]

So i say lets go with pre-built binaries for now

[eliasdaler]

Agreed. Need to invest more time in build scripts though…

[eliasdaler]

@AllenDang, just to confirm - are you OK with removing a GLFW backend and replacing it with ebiten-imgui for now? It will make our lives considerably easier for maintaining (no more dependency on GLFW and don't need to build GLFW static lib)

[AllenDang]

@eliasdaler Ok, let's do it.

[gucio321]

@AllenDang @eliasdaler what about creating some Discord server for the project (and probably for GIU as well)?
IMO, the benefits will be:

• get rid of many FAQ-issues
• easier communication between maintainers

[eliasdaler]

Not a big fan of using Discord for open-source projects unless they have a huge community.

Dear ImGui had Discord at first, but then it was closed as it was too much for its creator to maintain (and answer the same questions over and over).

For maintainer communications, issues/Github discussions/PRs are better because you rarely need instant responses. If you have something you want to ask in private, you can always shoot someone an e-mail.

[gucio321]

Not a big fan of using Discord for open-source projects unless they have a huge community.

oh, ok. Some time ago I was helping with an open source project and my experience with using discord are rather positive...