On Wed, 2008-06-04 at 07:35 -0400, Paul Davis wrote: > > Basically, something like this: > > > > http://doc.trolltech.com/4.4/properties.html > > > > When reading this and other Qt documents, one realizes that a large > > technological gap separates GLib/GTK+ and Qt. > > I don't want to start a flame war over old hat, but statements like this > shouldn't go unchallenged. GLib/GTK+ chose a different technology as a > base than Qt did (C vs. C++, and no pre-processing source versus > preprocessing source). As a result, some things that are easy in Qt are > hard in GTK+, but the reverse is true as well. If you want to see a > system that works more like Qt's (but better IMHO), you have only to > look to gtkmm.
We hear this again and again. There are two statements here: * Qt is superior because it chose C++. * Qt does preprocessing. GObject does not do preprocessing. Both are wrong. Specially the second one. First, lets see what's on the table: http://doc.trolltech.com/4.4/metaobjects.html Reading that page, say: * QObject::metaObject() returns the associated meta-object for the class. * QMetaObject::className() returns the class name as a string at run-time, without requiring native run-time type information (RTTI) support through the C++ compiler. * QObject::inherits() function returns whether an object is an instance of a class that inherits a specified class within the QObject inheritance tree. * QObject::setProperty() and QObject::property() dynamically set and get properties by name. One can't help but notice that QObject is *exactly the same thing as GObject*. With QMetaObject exactly being GObjectClass. Means, even though Qt is based on C++, they had to reinvent the object system again, exactly the same way that GObject did, because C++'s object system is static. Next, the preprocessing myth. Source code using Qt is written into files with the .moc extension. Then the .moc file is *copied intact* into a C++ file. Let me repeat: no rewriting done. And their custom symbols (signals, slots, Q_OBJECT, Q_PROPERTY) are simple macros. Their moc compiler processes the moc source and creates another source file, containing the class metadata, and that's linked into the project. This is where it confuses people. Qt could as well say "write proper C ++" and we just scan the .cc files straight. Not sure why, perhaps to make build setup easier, they decided to call their dialect of C++ moc. Now, people think GObject doesn't do the same. We do. Slightly differently. In that: * We use plain .c for our GObject code. No .go. * We don't use macros to add extra metadata to our classes or other types. Guess what we use then? Surprise! Comments indeed. If you are not sure what I'm talking about, check glib-mkenums and glib-introspection. So, the "technological gap" mentioned in this thread, namely, Q_PROPERTY(type name READ getFunction [WRITE setFunction] [RESET resetFunction] [DESIGNABLE bool] [SCRIPTABLE bool] [STORED bool] [USER bool]) Is not much technological (Q_PROPERTY expands to empty when compiling), as opposed to attitude. GObject maintainers do not like changing the syntax of the native language (C), while Qt developers don't mind adding arbitrary syntax as long as it makes it feel more comfortable. Anyone with some Perl or python skills can implement G_PROPERTY with the exact same syntax as the Q counterpart. Just make it generate the property definition code and include it in your class file. Any volunteers now? -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
