Resolve confusing situation with go-gtk

[infinity0]

Filing here because issues are disabled on go-gtk.

I am looking into laying the foundations for eventually making a Debian package for pond. All the crypto dependencies were packaged recently, and only Go-GTK is left. I notice that your version [1] diverges from upstream [2] somewhat.

Are there any plans to push these changes upstream? If not, please consider formally forking the project and renaming it something else, so that I can package it for Debian. (This is also good software engineering practice anyways, to avoid conflicting namespaces.)

[1] https://github.com/agl/go-gtk
[2] https://github.com/mattn/go-gtk

[burdges]

Alan Fey @emptyset and Ram Vedam @rvedam expressed an interest in merging the go-gtk distributions by @agl and @mattn

[mattn]

I can merge agl's changes if you'll create PRs. :)

[agl]

I'm not sure that Pond's go-gtk changes are suitable for too much upstreaming. If nothing else, changes to avoid deprecation warnings have caused problems for people on older (and not so old) distributions. I need to work out something better for that.

Additionally, I do not want Pond packaged for Debian, thanks.

[burdges]

We should elevate the priority here slightly :

At present, the go-gtk fork by @agl has poor error message handling, like in https://corcra.github.io/assets/pond-panic.txt via @corcra blog https://corcra.github.io/sec/2015/01/30/pond-on-yosemite.html These uninformative error messages have seemingly prevented people from debugging the Pond GUI build process on platforms like OS X.

In this case, the @agl go-gtk's PixbufLoaderWithType https://github.com/agl/go-gtk/blob/master/gdkpixbuf/gdkpixbuf.go#L88 should return a *glib.Error like NewPixbufFromFile in @mattn https://github.com/mattn/go-gtk/blob/master/gdkpixbuf/gdkpixbuf.go#L106 And the **glib.Error used in @agl go-gtk's PixbufFromFile https://github.com/agl/go-gtk/blob/master/gdkpixbuf/gdkpixbuf.go#L49 probably won't work either. You cannot fix this with type safe casts inside Pond itself, but inside go-gtk the same unsafe casts would recognizably be type safe (ala *C.GError to *glib.C.GError)

[burdges]

I made some progress on manually replaying the changes by @agl on the current branch by @mattn but got side tracked. And I'll remain so for the near future. If however anyone wishes to grab me, and work on it together, then maybe we can hammer it out quickly. Imho, that work is worth finishing because it'll fix how Pond reports GTK errors.

There is an important underlying constraint here : Go is designed for building servers in controlled corporate environments. Go is not a "systems programming language" in the sense that its conditional compilation directive lack the power to deal with variabilities in system libraries. Anyone packaging applications that depend upon go-gtk should therefore vender mattn/go-gtk as go-gtk2 and agl/go-gtk as go-gtk3. That's the Go way.