GTK 4.0 [LWN.net]

GTK 4.0

Posted Dec 18, 2020 11:18 UTC (Fri) by scientes (guest, #83068)
In reply to: GTK 4.0 by compenguy
Parent article: GTK 4.0

> The C++ API has made QT rather painful to bind from other languages.

GTK is not C, but gobject, which is basically the Vala language. You can see what a pain this is with the attempts to bind GTK to go and other garbage-collected languages.

to post comments

GTK 4.0

Posted Dec 18, 2020 19:33 UTC (Fri) by swilmet (subscriber, #98424) [Link]

I have the impression that using an API through a language binding never really feels like a native API, except if the binding has been created manually and tailored for the target language (but in that case it could be seen as a wrapper library, not a mere binding).

It's one of the reasons why the Xamarin Studio (MonoDevelop) developers wrote their own text widget in C#, and gave up GtkTextView (also, and mainly, because GtkTextView sucks, although they could have contributed to GTK to improve it, but C/GObject is not their favorite hobby).

GTK 4.0

Posted Jan 8, 2021 12:45 UTC (Fri) by bengen (guest, #14957) [Link]

Linking GTK to Go is not a particularly good example. Though I haven't got any experience with integrating GTK and Go programs specifically, I am certain from doing so with other C libraries that the GObject object system is not to blame here.

Go and anything non-Go do not mix particularly well and the Go community's answer is "CGo is not Go", with the implied notion that we'd all be better off just reimplementing our C and C++ libraries in Go. Sure, Go's foreign function interface support can be used for easy things and there's even some documentation, but as soon as you want to do something nontrivial, possibly with callbacks into Go from C, your life gets interesting, and not in a good way. Once you are done fighting the garbage collector and the magic protecting it, the fun shifts to a build system that does not handle non-trivial cases such as (cross-compiling or figuring out custom search paths for headers and libraries) particularly well. You end up adding build scripts or Makefiles or lengthy instructions. If you expect others to use your Go library of C bindings (i.e. build it from source), explaining the non-standard build system or instructions then becomes a major source of entertainment.

Very little of this has anything to do with the Go runtime having a garbage collector.