Building issues

[Chillance]

Hey!

I must say this is fantastic work, however, I'm not able to use this as I'm not entirely sure how you are suppose to "install" this.

go get github.com/shibukawa/nanogui-go gives me:

#cd ...../src/github.com/shibukawa/nanovgo; git submodule update --init --recursive
Submodule 'gh-pages' (git@github.com:shibukawa/nanovgo.git) registered for path 'gh-pages'
Cloning into 'gh-pages'...
ERROR: We're doing an SSH key audit.
Reason: unverified due to lack of use
Please visit https://github.com/settings/keys/420226
to approve this key so we know it's safe.
Fingerprint: 70:e5:.....
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

fatal: clone of 'git@github.com:shibukawa/nanovgo.git' into submodule path 'gh-pages' failed
package github.com/shibukawa/nanovgo: exit status 128

And I also noticed this trying to build nanogui-go:

../src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:429:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusStartCallback’

Could you be so kind to update this so it builds? Possibly add instructions/steps needed to do it.

Thanks!

[haiitch]

@Chillance I'm currently not having issues with nanovgo but then I cloned it a few days ago, there may be a regression going on. However I did experience problems like yours cloning nanogui-go, including the wrong access rights. I was able to get past it in the last clone attempt I made, but now I get a whole lot of new error messages. It's hard to tell from the symptoms whether we're experiencing problems caused by Github, or the repo is being touched by the author. My current error messages follow:

$ go get -v github.com/shibukawa/nanogui-go
github.com/shibukawa/nanogui-go (download)
github.com/shibukawa/glfw (download)
github.com/shibukawa/glfw-2 (download)
github.com/shibukawa/glfw-2/v3.2/glfw
# github.com/shibukawa/glfw-2/v3.2/glfw
In file included from /home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw_x11_window.c:2:0:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c: In function ‘_ximStatusStartCallback’:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:391:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘imeFocus’
     window->x11.imeFocus = GLFW_TRUE;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c: In function ‘_ximStatusDoneCallback’:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:397:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘imeFocus’
     window->x11.imeFocus = GLFW_FALSE;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c: In function ‘_createXIMStatusCallbacks’:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:428:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusStartCallback’; did you mean ‘preeditStartCallback’?
     window->x11.statusStartCallback.client_data = (XPointer)window;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:429:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusStartCallback’; did you mean ‘preeditStartCallback’?
     window->x11.statusStartCallback.callback = (XIMProc)_ximStatusStartCallback;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:430:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusDoneCallback’; did you mean ‘preeditDoneCallback’?
     window->x11.statusDoneCallback.client_data = (XPointer)window;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:431:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusDoneCallback’; did you mean ‘preeditDoneCallback’?
     window->x11.statusDoneCallback.callback = (XIMProc)_ximStatusDoneCallback;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:432:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusDrawCallback’; did you mean ‘preeditDrawCallback’?
     window->x11.statusDrawCallback.client_data = (XPointer)window;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:433:16: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusDrawCallback’; did you mean ‘preeditDrawCallback’?
     window->x11.statusDrawCallback.callback = (XIMProc)_ximStatusDrawCallback;
                ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:435:44: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusStartCallback’; did you mean ‘preeditStartCallback’?
         XNStatusStartCallback, &window->x11.statusStartCallback.client_data,
                                            ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:436:43: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusDoneCallback’; did you mean ‘preeditDoneCallback’?
         XNStatusDoneCallback, &window->x11.statusDoneCallback.client_data,
                                           ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:437:43: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘statusDrawCallback’; did you mean ‘preeditDrawCallback’?
         XNStatusDrawCallback, &window->x11.statusDrawCallback.client_data,
                                           ^
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c: In function ‘createWindow’:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:693:20: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘imeFocus’
         window->x11.imeFocus = GLFW_FALSE;
                    ^
In file included from /home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw_x11_window.c:2:0:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c: In function ‘_glfwPlatformGetIMEStatus’:
/home/vruz/go/src/github.com/shibukawa/glfw-2/v3.2/glfw/glfw/src/x11_window.c:2336:23: error: ‘_GLFWwindowX11 {aka struct _GLFWwindowX11}’ has no member named ‘imeFocus’
     return window->x11.imeFocus;

[Chillance]

Hey, sorry. I meant I get that error also with building nanogui-go (made the edit to correct).

I also managed to get the nanovgo running. But yes, nanogui-go seems to be a bit out of date to the more current headerfile now where as whatever the old code was using is now removed. Such as the imeFocus. That is what I suspect.

Also, what if we could make this work with https://github.com/go-gl/glfw instead? I recall https://github.com/golang-ui/nuklear/ and https://github.com/gen2brain/raylib-go/ is using that.

[haiitch]

I was able to make Go Nuklear work after a few edits ( you can take a look at my cloned repo for the changes I made https://github.com/golang-ui/nuklear ) I'm not familiar with raylib-go, I'll take a look.

And yes, I would try to make nanogui-go work with current (not vendored) versions of GLFW. Just so we catch up, could you please give me a brief description of what you think were the changes that broke nanogui? I don't understand why it should break, if it's using a vendored GLFW, unless the nanogui author updated GLFW without updating nanogui to reflect the changes.

Thanks for your help

[Chillance]

Building nuklear and raylib-go isn't really an issue. Both of those work fine for me. And they provide nice instructions. What I'm having trouble with here is this library, which is a shame because it certainly seems well done and something I want to explore.

What I suspect is the issue here, with nanogui-go, is that the header files are too new (in our systems) for the code in this repo (since it's like a year ago this was updated last time). You need the -dev packages to be able to build that glfw stuff since that is in C. And those dev packages contain newer headerfiles not matching up with the code here. This is what I suspect is going on.

[haiitch]

I see what you mean, and I did consider that possibility. But, if nanovgo (by the same author) builds just fine, and nanogui is based on nanovgo depends on that for lower level operations, it seems unlikely that would be the case. And again, the GLFW stuff is vendored, and it's the same GLFW stuff that nanovgo uses that works just fine. Also, there is no C code in neither Go's nanovgo nor Go's nanogui, they're clean Go implementations, not bindings, they only use Go's GLFW. (and that works just fine with go nuklear) I'm going to try replacing the GLFW version it uses

PS: I tried out raylib. I like that it comes with a lot of code samples, it comes with good text and font type management, the code is very readable, it builds crazy fast, and the resulting binaries can be made really small (after strip and upx). The GUI example it comes from is very primitive, and 2d geometric shapes don't look perfect when rendered, (nanovgo does a much better job at that). I think I may try to abstract the underlaying library I use in my application and see if I can reuse parts of nanogui to implement a working GUI, or if that proves unworkable start a new one from scratch.

[haiitch]

@Chillance I have narrowed the problem down to a few issues. It seems the author was in the middle of adding IME support to widgets, and not all widgets need IME support. So the easiest way to restore nanogui-go to a buildable state is to remove these additions for the time being. The author doesn't use the go-gl/glfw bindings directly, but rather through an abstraction layer provided by goxs (github.com/goxjs/glfw). The goxjs abstraction is meant to offer a choice of GLFW backend, the traditional desktop library, or a WebGL-based one on the browser. So I simply replaced the vendored goxjs/glfw in shibukawa's repo with a link to the current github.com/goxjs/glfw. One other thing that I had to do was to replace some incorrect imports that referred to github.com/nanogui.go/ as the project's URI, which is obviously now github.com/nanogui-go/. The dot go name must have been an older version, but some of the code wasn't updated after the project name change.

Now if I try to build the provided sample1.go, only a few problems remain with the IME support functions that no longer exist in one single source file screen.go (after making the changes described above). So, I will address this in my next session later tonight. Hope this helps

github.com/shibukawa/glfw
github.com/shibukawa/nanogui-go
 github.com/shibukawa/nanogui-go
/home/vruz/go/src/github.com/shibukawa/nanogui-go/screen.go:111: screen.window.SetPreeditCallback undefined (type *"github.com/shibukawa/glfw".Window has no field or method SetPreeditCallback)
/home/vruz/go/src/github.com/shibukawa/nanogui-go/screen.go:117: screen.window.SetIMEStatusCallback undefined (type *"github.com/shibukawa/glfw".Window has no field or method SetIMEStatusCallback)
/home/vruz/go/src/github.com/shibukawa/nanogui-go/screen.go:410: s.window.GetPreeditCursorPos undefined (type *"github.com/shibukawa/glfw".Window has no field or method GetPreeditCursorPos)
/home/vruz/go/src/github.com/shibukawa/nanogui-go/screen.go:410: not enough arguments to return
    have (<T>)
    want (int, int, int)
/home/vruz/go/src/github.com/shibukawa/nanogui-go/screen.go:414: s.window.SetPreeditCursorPos undefined (type *"github.com/shibukawa/glfw".Window has no field or method SetPreeditCursorPos)

[haiitch]

OK I made all the changes necessary in screen.go and textbox.go (the only widget that actually uses shibukawa's IME additions) and that problem is sorted. But now I have a different, and worse problem, which appears to be related to the Go compiler itself. Go panics whilst compiling nanogui-go, and it doesn't seem to be a C library problem. Now I'm really stuck. Please let me know if you manage to make any progress.

$ go build -v
github.com/shibukawa/glfw
github.com/shibukawa/nanogui-go
 github.com/shibukawa/nanogui-go
panic: bad store type

goroutine 1 [running]:
cmd/compile/internal/amd64.storeByType(0xd3b6c0, 0xd558a0, 0xa50e80)
    /wrk/pkg/go/src/cmd/compile/internal/amd64/ssa.go:76 +0xc8
cmd/compile/internal/amd64.ssaGenValue(0xc422252800, 0xc4214cef20)
    /wrk/pkg/go/src/cmd/compile/internal/amd64/ssa.go:699 +0x5aed
cmd/compile/internal/gc.genssa(0xc42221e240, 0xc4200e4238, 0xc42225d1f0, 0xc42225d260)
    /wrk/pkg/go/src/cmd/compile/internal/gc/ssa.go:4422 +0x25e
cmd/compile/internal/gc.compile(0xc420ebab40)
    /wrk/pkg/go/src/cmd/compile/internal/gc/pgen.go:443 +0x707
cmd/compile/internal/gc.funccompile(0xc420ebab40)
    /wrk/pkg/go/src/cmd/compile/internal/gc/dcl.go:1292 +0xdc
cmd/compile/internal/gc.Main()
    /wrk/pkg/go/src/cmd/compile/internal/gc/main.go:464 +0x1f08
main.main()
    /wrk/pkg/go/src/cmd/compile/main.go:50 +0xfe

[haiitch]

Update: It's a go compiler problem, and it's not specific to Go 1.8. https://github.com/golang/go/issues/19515 The Go developers are on it, and it should be fixed in Go 1.8.1 when it's out, or making the necessary changes to the Go compiler and building Go from source. I'm not going to do this today, but I thought this should be documented and I may pick it up again in a few days.

[Chillance]

Hey @htrob ! Lovely work! I don't suppose you made a fork to add these fixes?

Now, what I've seen from just looking at the code here, I really enjoy and like how nicely structured it is. What I would have liked to see, is like a cool amalgamation of raylib-go, nuklear, and this nanogui-go. I know that this pretty much all in Go (only glfw is the C part), while the others rely on C code. But, they all have their little nice thing, and coming together as one would have been super. Especially for Go as a GUI library. From raylib, there are nice gaming specific things that would be nice to have. In the end I prefer having as much as possible in Go, and I suppose the only thing that would need to be in C, would be the glfw part, and this library is a nice start.

Anyway, it sounds to me that I need to rebuild Go itself or wait for 1.8.1 before being able to use this.... :(

[Chillance]

Btw, about raylib, and rendering of primitives. Is anti-alias turned on?

I did: raylib.SetConfigFlags(raylib.FlagMsaa4xHint | raylib.FlagVsyncHint)

and it looks so much better.

[haiitch]

@Chillance Here's another update. The Go compiler bug had fortunately been fixed three days ago. So after a couple of attempts I built Go from the latest Go source, and now I have a working Go 1.8 compiler that is able to compile Nanogui, and the furnished example in the sample1 folder. go version devel +aea4410 Fri Mar 17 20:33:46 2017 +0000 linux/amd64 When I execute it, a nice GUI is displayed temporarily, and then it quits immediately. (see screenshot at the bottom of this comment box).

Nanogui (in global.go) main loop executes a goroutine to gather user input events (keys and mouse) then it sleeps for 50 milliseconds, and loops again. The programme seems to panic and halt during the goroutine's sleep time. I thought it was something more obvious like the usual main thread problem that is typically resolved using LockOSThread(), but it doesn't seem to be that. I removed the time.Sleep in that goroutine and the programme doesn't crash anymore, but now it's constantly polling events (not every 50 milliseconds) so that's consuming resources insanely, and it doesn't respond to events, and eventually hangs. I'm also taking a look at the gui4go project by the same author to see if there's anything more I can do to fix it, but not much else I can do beyond this point.

I'm on the brink of giving up and just use Nuklear, which doesn't have a nice API (I agree Nanogui's API is nice) but at least it does work. And Nuklear looks nicer anyway. Either that or write my own, stealing parts from Nuklear, Nanogui, and the Raylib gui package to get started with. I think I'm going to take a few days off it and pick it up again after the weekend. Thanks for the Raylib antialias hint tip, that's helpful.

[haiitch]

Here are the modified shibukawa .go files, I don't think I'm forking it after all. I'll see what I do in a few days, making sense of nanogui and the Go compiler problems has consumed just oo much time today. The kind of ideal GUI I need is not really for a game, but I'd also like it to be more like the sort of smarter toolkit you get with creative software like Adobe After Effects for example. So that means also not GTK-like.

In the meantime here's a zipped file with the changes I made (only .go sources, which is the project minus binary media files that I didn't touch) The glfw package is just a current copy of goxjs/glfw. You should also have a working go-gl/glfw available, of course.

Aaand... not a minor thing... compiling the latest Go from source, which is not hard, but it takes a couple of attempts sometimes to get it right.

shibukawa.zip Good luck, please let me know if you make any progress.

[Chillance]

You will do you own? Now that sounds very interesting to me! If you make it with the same nice API and parent/children structure like this one, it could end up very useful.

Now, one thing that I was thinking of doing, but not sure I will as I currently don't have the time for it, would be to take out everything from nanogui-go and nanovgo that is self contained, and then add some kind of glfw layer to it. This library has a lot going for it, and a nice API and parent/children structure, so would be a shame not to keep that. If done properly, it could possibly make it easier to be used with other libraries, like nuklear and raylib. I mean, this gui library seems to only include glfw for things like glfw.MouseButton. This could be abstracted away. Anyway, the idea would be to make self-contained as much as possible, and work nicely with other libraries.

I like raylib, but when doing GUI, this helps a lot because of all the logic this one has already for many of the common UI components. So, if this was abstracted away, it could possibly be quite easy to hook up with raylib-go too, and that would just be so cool.

Thanks for the package. I suppose I will give it a go, building Go! :)

[haiitch]

I've been trying to AVOID building my own, but seeing the current state of Go GUIs, I'm not ruling it out.

I tried to do something with the 2d engine Engi, which doesn't have any GUI controls. But it also doesn't have any canvas-like geometric drawing primitives, so I used gg https://github.com/fogleman/gg/ which a FreeType-based vector drawing library, on top of Engi, https://github.com/ajhager/engi a 2d game library. I was able to make some things look nice, but that's also not a solid foundation on which to build a full blown GUI. Engi is a basic wrapper around GLFW as well, and it took me a week to figure out how to draw vector images on that! Here's a sample of what I did with Engi and gg

[haiitch]

I didn't even attempt to have a decent api on top of my engi/gg experiment. In case you're interested, here's the code (binary included because you will be missing some changes I made to the forked libraries) htrob.zip

Now, maybe I should stop polluting shibukawa's space with unrelated stuff :-) Please feel free to email me o drop me a note on my github if you would like to keep discussing other gui things. horatio.trobinson@gmail.com

[Chillance]

Yeah, I know! Frustrating with so many cool things started with Go, but never takes off.

I really love the simplistic UI coming from nuklear/raylib/nanogui. Even for Desktop usage. These libraries are essentially the same. And, with little effort, it also works on all kind of platforms and even in the browser!

I started with nuklear with what I'm doing, and then moved over to raylib, which lacked the better UI support nuklear had, but had "cameras" and all that nice 2d stuff, which made it simpler for me to move the camera, instead of me wasting time on fiddling around with that. Especially when zooming in and out. So with raylib, I like that you have that lower level control drawing rectangles and collision support, but building a more GUI heavy solution with raylib requires more work as it is on that lower level with drawing rectangles. With this nanogui-go, you have nifty things like layouts and taking care of the sizes and calculating and positioning the UI components build in. And, from what I can tell, it's quite easy to do your own widget, while having all the work with layout for you already build in. This is a huge plus, as you can focus on actually doing your widget and program you are working on. In the Draw function, you specify how your widget looks, and you can reuse other widgets. Really nice structured code that way, which is why I really would like this to work much easier than it currently does.

A shame with the Engi there.

I think if enough effort was put in into something, it could really take off and it's one of those things were, if a library reaches a certain point where it's useful enough and more and more people would like to use it, then it can become quite huge.

[Chillance]

Yes, sorry. Went a bit off the rails there. I will email you. :)