GLFW Backend and it’s place within the library

[eliasdaler]

Currently, we have a GLFW backend as a part of "main" repo, but should it stay that way?

I think it might be better to move it to "examples" directory, because you can use cimgui-go without it by implementing another backend with a lib of your choice.

For example, I managed to get cimgui-go working with Ebitengine. I even believe it might be a "better" example, because it’s (almost) a pure Go library, plays better with Go ecosystem, and doesn’t require you to use CGo (so the only CGo code left is between your program and Dear ImGui itself).

So, my proposal is this:

A. Move glfw backend to "example/glfw" directory.

OR

B. If you want to make glfw backend a reusable package, I believe that making it a separate repo might be better (kinda like imgui-go did with [this repo](https://github.com/inkyblackness/imgui-go-examples, but don’t make backend impl "internal")

[AllenDang]

@eliasdaler The reason why I start all this is, neither imgui nor imgui-go provides a ready-to-use library, they all need me to find or implement a backend to get everything work.
This repo and giu should provide a gui framework which could be used immediately without extra work.
That's why I added a default backend implementation inside with a build flag to remove it.

The question behind actually is, who is the target user of this lib, tool creator wants a UI or game engine engineer? I prefer the first.

BTW, all implementation of the backends provides by imgui are immature just as their name implies "example".

[eliasdaler]

Can't the backend be moved to a separate repo/package or inside giu itself?
cimgui-go should be usable in other contexts (in Ebitengine, for example or with SDL-go wrapper lib), and I'd prefer if I didn't have to do anything to remove the things I don't need (like implot which I don't need... but that's another issue.).

If the user wants to have a GLFW backend, they can import "glfwbackend" package. It the user wants pure cimgui-go binding, they can import "cimgui".

Ideally, the output of cimgui-go should be treated as a simple Go package which can function without any other things. And currently, Go module system doesn't allow you to "remove" features it they're a part of the package. It only allows you to separate one big package into several, which is what I'd prefer.

[gucio321]

In my opinion the perfect scenario would be that cimgui-go should have a backend implementation set by default, for people who wants just "plug-and-play" this package. but it should be a method "SetBackend(backend Backend)" that allows to change the default implementation.
This way, we just need an interface Backend that exposes the necessary methods (just like the old AllenDang/imgui-go had)

[eliasdaler]

I think that cimgui-go might have the following structure:

./
    glfwbackend/
        backend.go
        // and other files of backend impl
    funcs.go
    types.go // and the rest of "wrapper" stuff

This way, if people want to use the backend, they can do this:

import "github.com/AllenDang/cimgui-go/glfwbackend"

...

glfwbackend.Start()

And at this point it's not much different to moving a backend to another repo, so people would just do:

import (
    "github.com/AllenDang/glfwbackend"
    "github.com/AllenDang/cimgui-go"
)
...

glfwbackend.Start()
...
cimgui.Text("...")

It is "plug-and-play", but it makes cimgui-go not grab GLFW for me if I don't ever need it. I only need cimgui bindings.

[gucio321]

or even better:

.
└── pkg
    ├── backend
    │   └── glfw
    └── cimgui

This way, go will not grab (iirc) glfw if it is not imported, it will just use cimgui

[eliasdaler]

I don't like "pkg" directory too much. Most good packages don't require you to import them like this:

import "github.com/AllenDang/cimgui-go/pkg/cimgui"

You just import them like this:

import "github.com/AllenDang/cimgui-go"

And I think that it would still import GLFW unless "backend" package has a separate go.mod, so at this point it's better to move backend implementation to a separate repo or make a separate "go.mod" for it.

[eliasdaler]

@AllenDang now that we've decided to remove GLFW backend, how should I do it?
I think cimgui-go might contain ebiten-imgui inside of it until its ported to cimgui-go in upstream (should be quick), but what do we do after?

Do we leave the example/main.go which shows how to use cimgui-go and ebiten-imgui? I don't think we need to store the backend itself inside this repo, it will be redundant.

[AllenDang]

@eliasdaler I prefer to store the backend into this repo and use a build flag to remove it, like what it is for GLFW backend.

[eliasdaler]

I wouldn't be comfortable with taking someone's code and putting it into another repo, essentially making a hard fork of it.
Guess I'll try to rewrite a GLFW backend to live in another package so that users who go get cimgui-go don't have to depend on GLFW or this backend...

[AllenDang]

So you suggest we create a new repo say it's named "cimgui-go-backend-ebiten", and add a example code inside cimgui-go to demonstrate the usage, and add a section to readme like "backend"?

I'm ok with it.

[eliasdaler]

No, I suggest to add "examples" directory here and demonstrate the usage there.
Importing "ebiten-imgui" would be enough to make it work so we don't need "cimgui-go-backend-ebiten" to not duplicate code of "ebiten-imgui" repo.

I would be okay with making "cimgui-go-backend-glfw" repo, though.

[AllenDang]

I think we will eventually need to modify the backend, let me create the repo now.

[eliasdaler]

If we need to modify it, we can just send PRs to ebiten-imgui repo...