[exDM69]

> GTK support for OpenGL, OpenCL was terrible, having to low code everything, while in Qt works as well as with cocoa.

OpenGL support sucks in GTK and QT equally. Especially if you want a more recent version of GL.

OpenCL does not depend on your widget toolkit in any way.

> Let GTK die and improve(or fork) Qt.

Qt is not really as great as you seem to suggest. It's a bloated "batteries included" framework that has everything from it's own string type to wrappers for things like threads and sockets. GTK is a widget library that is a lot leaner and meaner in comparison.

These massive platforms that try to wrap everything in the underlying operating systems to a common API use only the least common denominator of the systems that it runs on. The easy 80% works quite well but things tend to fail miserably when you enter the 20% realm. Things like memory mapped files or asynchronous socket i/o tend to be missing from these wrapper platforms.

And Qt is still using an old non-standard conforming version of C++ to achieve portability to things like Symbian. And their own C++ extensions that require you to use their build system and pre-processing tools. So you can't really use Qt without going all the way to Qt land.

[sparkie]

Probably worth adding that Qt being C++ is itself a problem - as it makes it inaccessible to the majority of programmers, due to the lack of ABI compatibility with C++ and any other languages. Gtk+ on the other hand, is almost universally accessible, because any language worth using can bind C APIs.

Of course, the downside here is that all the Gtk+ bindings to other languages are based on the Gtk+2 API. Gtk+3 hasn't gained much popular support.

[exDM69]

> Probably worth adding that Qt being C++ is itself a problem

Yep. C++ is what I call a "dead end" language. If you write your code in C++, it will be only usable from C++. If you want to use it from Python, Ruby or whatever, you'll need a C shim in between. If it were written in C, you could use ctypes and other similar means to do FFI quickly.

Unfortunately, most languages other than C are more or less a dead end.

[maigret]

> Unfortunately, most languages other than C are more or less a dead end.

Except for Java, where you can reuse code directly with JVM-compiling stacks like Clojure.

[exDM69]

Well that is arguable. If you stay within JVM, you can use your Java code from other languages like Clojure and Scala. To some extent you can use Scala and Clojure code from Java. But you can't really use Java code from Python or Ruby unless you work with Jython or JRuby.

So, I'd put Java in the "dead end language" bin. You can use C code from Java (via JNI) but it's not practical to do it the other way.

[UK-AL]

Not always. See boost python.

[exDM69]

I'm aware of that. But it's essentially a shim layer, albeit one that is semi-automatically generated. The preferred way of doing Python FFI is to use ctypes inside Python, not write (or generate) C or C++ code that works as the shim.

That's the way many languages prefer to do their FFI, write "foreign" declarations in the language itself, not in C++ land. E.g. in Haskell, you can call C with very little effort. When dealing with C++ you have to get along with ABI issues and things get a lot harder.

[rdale]

If writing language bindings for Qt based C++ apis is harder than writing language bindings for GTK C based apis, how come there are at least as many high quality language bindings for Qt as there are for GTK?

Just because an api is C based doesn't make language bindings 'happen automagically', otherwise Gnome wouldn't need the GObject Introspection project. KDE has a similar project called 'Smoke' and some language bindings based on that.

There are different technical challenges to writing bindings for a C++ based api as opposed to a C based api, but it is just not true to say that one is better than another in my opinion. This is based on my experience doing a lot of work on Qt C++ language bindings, and a project using GObject Introspection.