Glad to see some more work being done on UI frameworks in Go, though I doubt this will end the splintered nature of all the different (mostly half-baked, honestly) options.
I've personally been using a Qt5.1/QML based solution with a Go/CGO based QML plugin that acts as a bridge between QML and backend Go code. It doesn't try to export much of Qt to Go, it basically expects you to write the UI logic in QML/QtQuick and then just use Go for the underlying app logic, using the QML plugin bridge to allow Go code to call QML functions and vice-versa. In practice this works somewhat like writing a Go server that manages an HTML UI for doing browser-based UIs with a web-based RPC system, except I can write the UI code in QML which I find much preferable to HTML/JavaScript (variable binding Just Works, no need for frameworks like Angular, no need to mess with CSS, can efficiently pass around binary data in byte arrays easily, etc).
Currently my solution isn't even half-baked, I've been implementing it to serve a specific app, and it currently has some dependencies that force it to be Windows only (these could be trivially removed, but doing so isn't important for my app). I may share the code for this sometime in the future after it has matured a bit more, though there's really not that much to it.
Slightly off topic, but something I've been curious about. Go decided on garbage collection to manage memory. Why do so few languages offer something like C++'s RAII?[1]
In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generated for you, which will ensure all the objects members are destructed with your object,[2] so you can avoid even worrying about the destructor.
Yeah, it's not as simple as GC, but it seems like a great compromise between manual memory management and garbage collection.
[2]: Provided no members are dynamically allocated. If you allocate an array in your constructor, for example, you need to free it in the destructor. You need to define a destructor to free dynamically-allocated memory, or to do other cleanup.
Preferring RAII over garbage collection is the decision that Rust made.
Probably the reason that more languages don't use RAII for memory management is safety. C++, even with RAII, is not safe—you can violate memory safety with certain uses of references and iterators. Rust has to go to great lengths (lifetimes and the borrow check—things that have only been in the research landscape) to make this safe.
This approach starts getting brittle when you get into objects that aren't procedure-scoped; for instance, a global session table in a web application, or a request token tracker in an RPC system. These are also the kinds of object lifecycles that tend to be behind leaks and corruption in programs that don't use RAII.
People use shared pointers to mitigate that problem, but shared pointers are (a) a reference counting scheme with all the attendant problems and (b) not compatible with code that holds references but doesn't speak the same shared pointer scheme.
(It's been a bunch of years for me since I wrote C++ professionally; that may show here.)
It's more error prone than GC and there aren't really enough advantages to RAII to make it worth it much of the time. Sometimes, sure, but GC is nicer and usually fits the bill.
I am on ubuntu raring with the packaged golang and I can't compile your example code, copied directly out of Sample Use.
kbarrett@vernon-linux:~/go-work/gotk$ go version
go version go1.0.2
kbarrett@vernon-linux:~/go-work/gotk$ go build
# github.com/conformal/gotk3/glib
glib.go:380[/tmp/go-build210667265/github.com/conformal/gotk3/glib/_obj/glib.cgo1.go:370]: function ends without a return statement
glib.go:743[/tmp/go-build210667265/github.com/conformal/gotk3/glib/_obj/glib.cgo1.go:741]: function ends without a return statement
function ends without a return statement. If this is a problem with my version of go, I will try and fetch the latest head from git. I am interested!
sudo go get github.com/conformal/gotk3/gtk -- gives the same error.
No mention of goroutines or concurrency in the post. Is it addressed by the project at all? I can't imagine that the GTK main loop will deal well with being cooperatively scheduled -- the UI would block any time another goroutine ran on the same OS thread.
Ideally the GTK main loop would run in its own OS thread, and there would need to be a way to ensure that no GTK calls happen in other goroutines. Other (threaded) environments tend to handle this by deferring via a one-off "idle" function that is scheduled and run by the GTK main loop for things like that.
We do try to deal with concurrency and goroutines as much as we can. I'd recommend taking a look at the (rather simple) goroutine example as part of the gtk package. Unfortunately though, as you said, GTK is not thread safe (calling GTK from multiple threads was deprecated as of the last release I believe) and calls must be made using glib.IdleAdd() to run the functions in GTK's main loop context.
Does anyone else think we need a new open-source widget toolkit? Qt, GTK, and what else is there? Those guys are old. I've done both, and WPF, and WPF is just so much better. I wish there was an open-source toolkit that didn't just suck.
Yes, most are old and tiered. But another problem is, there is not a company/organization or even language community to take on such a big endeavour.
I'd like to see a C based toolkit, that's made specifically for wrapping it up for other languages (in C++, Ruby, Python, Go etc) and has niceties to help with this.
I just gave it a try now, but the code will not compile on my dev box (OpenBSD, go tip). Even after making some minor fixes (I fixed an #include directive, removed a call to a deprecated function, etc.) there appear to be some serious issues (one error I got mentioned the size of an array being negative).
It appears this code has not been updated in a year, and we wished to target a recent GTK version (3.8, to be precise) with our bindings. Had we known about the project, we probably would have considered submitted patches to fix its issue and bring it up to date with newer dependencies, but even then, I feel that it would be almost as much or perhaps even more to fix and verify an unfamiliar and broken code base than rolling our own.
But I'm glad to see this project seems to be doing memory management in a Go-like manner.
That approach isn't too surprising when the Go framework is, like this one, a Go wrapper on top of existing C code. And quite a lot of Go frameworks are that.
However, even ignoring the CGO-based frameworks, there's nothing wrong with mostly using Go as if it were C with closures (and garbage collection, and interfaces, and optional implicit typing and reflection), that's how most Go code looks, even in the standard library. Channels/CSP are great if you need to easily pass data among concurrent goroutines, but not all code neatly fits into that model nor benefits from concurrent execution.
One of the early mistakes most newbie Go programmers make (and I did this myself as well) is overusing channels, just because "hey, channels are super cool"!
You are not considering that most Go UI frameworks are twenty years of C/C++ and a couple months of Go. Naturally anything trying to do significant reinvention is not going to be as far along.
I use channels all the time in actual code using gotk3. Unfortunately, it means using glib.IdleAdd() a lot (because GTK is not thread safe), but it works.
People just lean to their comfort. I am an Erlanger -- so I tend towards channels. As people start doing more concurrently and the problems get more complex, dividing work among simple actors (or microservers depending how you break it up) becomes a great way of keeping complexity under control.
if you look on github, you'll notice that all the obvious names were taken, e.g. go-gtk, go-gtk3. that was what really drove the project name to be gotk3.
[+] [-] georgemcbay|12 years ago|reply
I've personally been using a Qt5.1/QML based solution with a Go/CGO based QML plugin that acts as a bridge between QML and backend Go code. It doesn't try to export much of Qt to Go, it basically expects you to write the UI logic in QML/QtQuick and then just use Go for the underlying app logic, using the QML plugin bridge to allow Go code to call QML functions and vice-versa. In practice this works somewhat like writing a Go server that manages an HTML UI for doing browser-based UIs with a web-based RPC system, except I can write the UI code in QML which I find much preferable to HTML/JavaScript (variable binding Just Works, no need for frameworks like Angular, no need to mess with CSS, can efficiently pass around binary data in byte arrays easily, etc).
Currently my solution isn't even half-baked, I've been implementing it to serve a specific app, and it currently has some dependencies that force it to be Windows only (these could be trivially removed, but doing so isn't important for my app). I may share the code for this sometime in the future after it has matured a bit more, though there's really not that much to it.
[+] [-] asb|12 years ago|reply
[+] [-] owaislone|12 years ago|reply
[+] [-] kristianp|12 years ago|reply
[+] [-] quacker|12 years ago|reply
In C++, when you define a class, you define the constructor(s) and the destructor. Then the destructor is called whenever the object goes out of scope. Easy. This is the gist of RAII. Furthermore, in C++, a default destructor is automatically generated for you, which will ensure all the objects members are destructed with your object,[2] so you can avoid even worrying about the destructor.
Yeah, it's not as simple as GC, but it seems like a great compromise between manual memory management and garbage collection.
[1]: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initial...
[2]: Provided no members are dynamically allocated. If you allocate an array in your constructor, for example, you need to free it in the destructor. You need to define a destructor to free dynamically-allocated memory, or to do other cleanup.
[+] [-] pcwalton|12 years ago|reply
Probably the reason that more languages don't use RAII for memory management is safety. C++, even with RAII, is not safe—you can violate memory safety with certain uses of references and iterators. Rust has to go to great lengths (lifetimes and the borrow check—things that have only been in the research landscape) to make this safe.
[+] [-] tptacek|12 years ago|reply
People use shared pointers to mitigate that problem, but shared pointers are (a) a reference counting scheme with all the attendant problems and (b) not compatible with code that holds references but doesn't speak the same shared pointer scheme.
(It's been a bunch of years for me since I wrote C++ professionally; that may show here.)
[+] [-] jlgreco|12 years ago|reply
[+] [-] yebyen|12 years ago|reply
sudo go get github.com/conformal/gotk3/gtk -- gives the same error.
[+] [-] Scaevolus|12 years ago|reply
[+] [-] jevinskie|12 years ago|reply
[+] [-] acomjean|12 years ago|reply
[+] [-] dysoco|12 years ago|reply
[+] [-] MetaCosm|12 years ago|reply
From poking around, still a pipe dream for the moment.
[+] [-] joeshaw|12 years ago|reply
Ideally the GTK main loop would run in its own OS thread, and there would need to be a way to ensure that no GTK calls happen in other goroutines. Other (threaded) environments tend to handle this by deferring via a one-off "idle" function that is scheduled and run by the GTK main loop for things like that.
[+] [-] jrick|12 years ago|reply
[+] [-] pionar|12 years ago|reply
[+] [-] coldtea|12 years ago|reply
I'd like to see a C based toolkit, that's made specifically for wrapping it up for other languages (in C++, Ruby, Python, Go etc) and has niceties to help with this.
[+] [-] papaf|12 years ago|reply
1. Standard C++ ui designed in a form designer and connected to C++ classes.
2. QML + javascript.
3. OpenGL with the ability to use widgets on the OpenGL viewport.
[+] [-] sesteel|12 years ago|reply
They also set finalizers.
[+] [-] jrick|12 years ago|reply
I just gave it a try now, but the code will not compile on my dev box (OpenBSD, go tip). Even after making some minor fixes (I fixed an #include directive, removed a call to a deprecated function, etc.) there appear to be some serious issues (one error I got mentioned the size of an array being negative).
It appears this code has not been updated in a year, and we wished to target a recent GTK version (3.8, to be precise) with our bindings. Had we known about the project, we probably would have considered submitted patches to fix its issue and bring it up to date with newer dependencies, but even then, I feel that it would be almost as much or perhaps even more to fix and verify an unfamiliar and broken code base than rolling our own.
But I'm glad to see this project seems to be doing memory management in a Go-like manner.
[+] [-] prodigal_erik|12 years ago|reply
[+] [-] georgemcbay|12 years ago|reply
However, even ignoring the CGO-based frameworks, there's nothing wrong with mostly using Go as if it were C with closures (and garbage collection, and interfaces, and optional implicit typing and reflection), that's how most Go code looks, even in the standard library. Channels/CSP are great if you need to easily pass data among concurrent goroutines, but not all code neatly fits into that model nor benefits from concurrent execution.
One of the early mistakes most newbie Go programmers make (and I did this myself as well) is overusing channels, just because "hey, channels are super cool"!
[+] [-] JulianMorrison|12 years ago|reply
[+] [-] jrick|12 years ago|reply
[+] [-] MetaCosm|12 years ago|reply
[+] [-] dragonwriter|12 years ago|reply
[+] [-] bratsche|12 years ago|reply
[+] [-] jlgreco|12 years ago|reply
[+] [-] zandorg|12 years ago|reply
[+] [-] conformal|12 years ago|reply
[+] [-] mortdeus|12 years ago|reply
[+] [-] dysoco|12 years ago|reply
[+] [-] gophering|12 years ago|reply