Re: Steps to get to GTK+ 3.0

[Behdad Esfahbod <behdad behdad org>]

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