Earlier quoted context omitted.
Yeah, I think I completely agree with this. Nominally GTK (and I think Qt?) is designed with scripting language support in mind. They export a bunch of XML that can be used to generate bindings in other languages, but said XML is miserably documented and in practice it's basically impossible to leverage it (I recall various attempts at generating Go bindings and all ended in failure--it became apparent that it was ea…
I guess there are two different kinds of bindings. 1) Scripting language is still the driver of the application, it uses "bindings" against a GUI library to implement the application. This is the one I'm most interested in. And if you need low level stuff, you implement that as dll/so library and uses that from you scripting language. What usually happens is that you need to read the GUI library C or C++ code and exa…
Yes, this is very true.
> XML as descriptive source sounds good in theory,
Agreed, and it could probably work in practice with enough investment (ideally forego XML altogether in favor of a markup language that isn't hostile to humans and machines, document the schema thoroughly, provide reference implementations, etc).
> I think I looked at Go-Qt binding but if I remember correctly it was alpha and had problems. Python-Qt exist but I don't know much about it. Read somewhere that I was just easier to use C++ directly, less hassle, don't know if that is true.
Yeah, the Go-Qt binding was just incomplete. There was a Go/QML project early on, but I don't think it allowed for data to flow both directions, which seriously limited its utility and then it just kind of faded into obscurity. Pyqt (there was a competing Python/Qt binding as well, but I forget what it was) was okay, but again it didn't have very good documentation and it would still segfault all the time. One or both of the Python/Qt bindings were also poorly supported.
> Vala looks like a nice solution if you want to go full GTK.
I tried this as well, but it's a thin veneer over GObject and still has many of the same problems. It also lacks any kind of build tooling or package management, and again, it's not adequately invested in and the documentation is poor (or this was the case when I last tried it).
> I think for Gnome and other desktops that uses this technique, it is in the right direction, but the quality of the plugins I have used is most of the time poor, memory leaks etc, you end up using just use the approved ones if you don't like to restart your desktop once a day. If that is because of poor bindings or poor plugin implementations I don't know.
Agreed.