GTK 2 v 3

[burdges]

I started merging @agl go-gtk into @mattn go-gtk after I realized the @agl fork had broken error reporting : https://github.com/agl/pond/issues/143#issuecomment-72358811

I’ve started work on a pull request for the GTK 2 changes, but @agl switched to GTK 3 at some point. And Pond now uses GTK 3’s Grids everywhere.

Anyone considered adding GTK 3 support here? I’m actually unsure how go-gtk should best support both GTK 2 and 3 :

Separate gtk2 and gtk3 directories with user settable gtk symlink to gtk2 or gtk3?

If so, what about the common code? Just a convention that gtk[23]/common.go should be (almost?) the same? A go generate script that builds 'gtk[23]/common.gofromgtk+/common.go` with patch files? etc.

[burdges]

There isn't enough support for conditional compilation in Go to handle both GTK2 and GTK3 cleanly.

We could split the modules into gtk2 and gtk3 variants, maybe keeping common code common using go generate directives to build the shared modules with cpp, perl, or whatever. Example : //go:generate cpp -P -CC -D GTK_PACKAGE=gtk3 -o gtk2_common.go gtk_common.go Any such approach makes the who repository depend upon both GTK2 and GTK3 though, which seems unacceptable.

We should therefore stick with specifying the GTK version using Go's build tags. A quick survey of linux machines at the conference I'm at currently reveals many GTK3 installations and zero GTK2 installations, and GTK websites discuss the deprecation of GTK2, so GTK3 should be the default and GTK2 should become a build tag.

[burdges]

Oops, there is no obvious way to cleanly handle the cgo pkg-config lines with go's build tags, which limits the options still further.

[burdges]

After a brief IRC chat it appears the best solution is to rename all the current v2 modules to names like gtk2 and add v3 modules like gtk3. And ask all code that depends upon go-gtk to change their imports.

I disliked this because it creates duplicate common code, but that could be addressed with scripts or whatever.

[sarim]

umm, probably this is not the right place to ask, but is there any development for supporting gtk3?

[burdges]

I placed any updates on gtk3 support in this thread : https://github.com/agl/pond/issues/143

At some point, I began updating mattn's current go-gtk for gtk2 with agl's changes, primarily because it'd resolve our problems with pond not reporting gtk error messages correctly, but I laid it aside for various reasons.

There is an underlying problem that Go is designed for controlled corporate environments and does not play well with others. We'd need conditional complication support to make go-gtk support both gtk2 and gtk3 cleanly. Ain't clear if folks here would be interested in dealing with that once it was done. Now the Go way would be to have two separate go-gtk2 and go-gtk3 projects, which sucks. And we've nobody interested in maintaining go-gtk3 anyways, so that's out. I'd actually recommend you avoid using Go for any projects that need heavy external libraries, like non-web GUIs, use Rust or Python or something instead.

That said, if you're interested in maintaining a go-gtk3, then I can show you want I was doing to port agl's changes for gtk3.

[gour]

@burdges :

"I'd actually recommend you avoid using Go for any projects that need heavy external libraries, like non-web GUIs, use Rust or Python or something instead."

What if I simple do not like Rust's syntax, Python is too slow for my project and want static-typing?

Moreover, I'd like to avoid JS-stuff for my GUI, so wonder what recommendation you have and/or whether something is going to change in the future in regard to the fact "that Go is designed for controlled corporate environments and does not play well with others." ?

[sarim]

What if I simple do not like Rust's syntax, Python is too slow for my project and want static-typing?

Actually my requirement was pretty much like you, don't want to learn Rust, Python is slow and i wanted static-typing.

@gour After fiddling with gotk3, gtk, swig for few days, i ended up ditching gtk. Using gtk (or external lib) in go is real pain, specially when you need cross-platform (read f*ing Windows) support. CGO sucks in Windows. After researching alternatives i choose wxWidgets and gRPC (protocol buffer based rpc). The main logic and database stuffs are in go which acts as a grpc server. GUI is completely in C++ which receives data using grpc and does GUI with wxWidgets. So far this is the best way to do GUI apps in go IMO. Now this decision is also based on other requirements of this project i'm working on, so your milage may vary depending on your use case.

[gour]

@sarim Thank you for reply.

Using gtk (or external lib) in go is real pain, specially when you need cross-platform (read f*ing Windows) support.

Yes, Linux is my native platform, but I'd like multo-platform app.

CGO sucks in Windows.

Ohh, can you provide some more info in regard?

After researching alternatives i choose wxWidgets

Well, I want(ed) to avoid using {C, C++, Java} directly.

and gRPC (protocol buffer based rpc). The main logic and database stuffs are in go which acts as a grpc server. GUI is completely in C++ which receives data using grpc and does GUI with wxWidgets.

Thank you for gRPC pointer, I'll check it out.

So far this is the best way to do GUI apps in go IMO. Now this decision is also based on other requirements of this project i'm working on, so your milage may vary depending on your use case.

Sure...that's why I'm still considering to use FPC (Free Pascal) with Lazarus/(fpGUI)...

[sarim]

Ohh, can you provide some more info in regard?

Well, i wanted to use CGO to mix go codes with native(c/cpp). Go 1.5 added new buildmodes (namely c-archive, c-shared), but those aren't supported/implemented in windows.

There are some attempts at creating directly opengl based cross-platform gui library in go. Something like that would be the proper and painless way to do GUI in go IMO. Wait a few years and see if something like that appears :P

[gour]

Well, i wanted to use CGO to mix go codes with native(c/cpp). Go 1.5 added new buildmodes (namely c-archive, c-shared), but those aren't supported/implemented in windows.

I also have a need to bind 3rd party C library, so good to know. ;)

There are some attempts at creating directly opengl based cross-platform gui library in go. Something like that would be the proper and painless way to do GUI in go IMO. Wait a few years and see if something like that appears :P

I'm monitoring andlabs's libui and ui attempts.

[princegoyal1987]

@gour What did you finally select for your gui stuff? All of your points are application for me as well, don't want C/C++, learning rust is too painfull (and I don't know how much cross platform GUI is supported there).

[princegoyal1987]

"I'd actually recommend you avoid using Go for any projects that need heavy external libraries, like non-web GUIs, use Rust or Python or something instead."

@sarim Just checking, is this still valid in 2017?

[gour]

@princegoyal1987 Well, the project is on hold due to other, mostly non-computer-related obligations, but if I'd do it in Go, I would take a look at this project.

[sarim]

well i'm not keeping tabs with these gui attempts, but did some research back at late 2016. Still didn't like any go gui offerings. Can't suggest you anything if you don't want c++ :P perhaps try electron?

@gour Kinda skimmed over therecipe/qt source when it first came out. Bindings were generated manually, so discarded it. What happens when in future project gets abandoned but you want to use latest qt? Using something automated like SWIG is better bet. But don't know what is the condition of the project now. So my opinion might be outdated.

[princegoyal1987]

@sarim Then I might go with GRPC + Go + C++ approach. What do you suggest for GUI there? WXWidgets vs GTK, who wins? I need printer (paper printer) support as well. Any idea about printer support on those? (its going off topic from thread, but I have to ask :P)

[sarim]

IMO Wx/Qt easily wins over GTK.

The project i was talking about (in 2015) in this thread had extensive printing requirements. WxWidgets has nice printing support. You can draw your stuff yourself in c++ or use any external library. I needed tables and reports etc.. so i used jasperreports. I ran it in its own java server, go server sends requests to jasper via http and gets the pages in pdf. Then pdf is sent via grpc to c++ gui client. Using mupdf (a c pdf library), i read the pdf to pixels and draw the pixels to printer via wxPrintout class.

But if you don't need table, report, graphs etc... you can probably use wxHtmlEasyPrinting class. Also check out wkhtmltopdf.org.

The process with Qt will be similar.

[burdges]

I'm going to close this since I've migrated completely to Rust. And Go is not likely to ever abandon the requirement to vender dependencies since Google can afford to work that way. I'll leave you with a quote though : "We were strongly advised to not use cgo, by people who have used it extensively."