Qt has a meta-object system that also allows introspection. However, Qt has things like signals/slots and QML that generally do not have direct correlates in other languages, so support for these sorts of things in a manner that works well with the idioms of the language in question generally need to be programmed.
Originally Posted by kigurai
So although basic access to Qt class signatures and methods is not difficult, being able to provide access to all the capabilities Qt provides in a manner that is well-suited to the language requires more than that.
This is no different with GTK. Getting good idiomatic bindings requires more than just using the introspection, you need language-specific code that maps toolkit-specific concepts to the language in question. Try comparing pygtk's original gobject property handling, which involved parsing a dictionary with strings, to their modern method and decorator-based approach. That didn't happen automatically, it had to be specifically programmed (as PyQt4's property system did, although it doesn't look like they ever used the ugly dictionary method).
Last edited by TheBlackCat; 04-26-2013 at 07:40 AM.
Not sure I am following you here. Are we talking about the same thing?
Originally Posted by TheBlackCat
Using GTK from Python (to take an example) is now done via
from gi-repository import Gtk
which finds the Gtk3 .typelib file. There are no specific "GTK Python bindings", as this is handled by the introspection system.
Then they could have used Gecko and other things instead.
As a user I prefer Gtk2 applications. As a programmer I donít like Qt.
What dont you like about gtk2 as a user? Personally as a user I much prefer Qt programs because I know using them cross-platform is less of an issue, and using them under different environments isnt going to butcher the looks of the program. (Gtk looks like crap under KDE because GTK refused to merge patches from the Qt/KDE guys that made sure it used the desktop's style. KDE merged GTK's patches however to make sure that KDE/Qt programs under GTK rendered correctly.)
Originally Posted by stqn
Yeah, GTK isn't necessarily "bad", but really the only thing its suited for is creating GNOME apps. for cross platform (and even cross-DE) its garbage compared to QT.
Originally Posted by jumico
Last edited by bwat47; 04-26-2013 at 01:04 PM.
Well, both have their uses. For me it comes down to bindings and use case. Since I like coding in D, and Qt support on D is not very good (the QtD project is mostly unmaintained and there is little hope for Qt 5 support), I'd rather use GTK. If coding in pure C, then GTK again has an edge, as Qt is not compatible with C. But if coding in C++, then of course Qt is the way to go. And if the program has to be cross-compatible, then Qt has an edge, if not, then GTK is just fine.
What, if you are coding in C and the program has to be cross-platform?
Originally Posted by GreatEmerald
Well, GTK2 is dead and OpenShot is not the only application that switched to Qt. VLCís switch was quite some time ago and more recently even LXDEís PCManFM switched to Qt: http://blog.lxde.org/?p=990
Originally Posted by stqn
Then either compile the C code with a C++ compiler (and try ignoring all the warnings it spits out about "obsolete features"), and use Qt for the rest, or just use GTK. It's still cross-platform, just not as much as Qt.
Originally Posted by LightBit