Re: Steps to get to GTK+ 3.0

["Brian J. Tarricone" <bjt23 cornell edu>]

Jean-Yves Lefort wrote:
> On Wed, 04 Jun 2008 15:18:45 -0400
> Paul Davis <paul linuxaudiosystems com> wrote:
>
> > On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote:
> >
> > > Rather than calling my suggestions silly, why don't you actually try
> > > to explain how the non-preprocessed, dynamic-only GLib property design
> > > is superior to the Qt design (or at least not inferior), or describe
> > > these specific reasons that you are talking about?
> > because i really don't give a damn. i don't use GTK+, i use gtkmm, and
> > there is no feature of Qt that i ever find lacking. although Qt has
> > closed the gap, for a long time it was the poor cousin of gtkmm when it
> > came to type-safety, integration with the STL and more. i'm really not
> > all that interested in what happens at the GObject level, other than
> > that it maps into a decently performing layer by the time i interact
> > with it at the C++ level. i also don't want to see glib/gobject
> > developers wasting time trying to do what C++ plus a preprocessor does
> > in plain C or C plus Yet Another PreProcessor.
>
> You didn't get the point. As explained in my initial message, a
> preprocessor would be used to fix the performance of the property
> system.

I wouldn't think that this is worth it.  As Tim mentioned elsewhere, for 
properties that need to be read/written in a time-critical fashion, it's 
best to add specific getters/setters.  GTK already does this in many 
places (often for convenience, not for performance reasons), so I don't 
see how this is a huge burden.

Regardless, have you done any benchmarking?  You might find the 
performance issues to be negligible.  And you might not.  But throwing 
around statements like "it's definitely much slower" is meaningless 
without numbers.

> Ease of use is not the main goal, it's only a secondary
> benefit. As you might know, Qt is implemented in plain C++, and
> nevertheless uses a preprocessor (moc).

If it needs a preprocessor, it's not "plain C++".

	-brian