Re: [gtkmm] Talk about a major rewrite

["Robert J. Hansen" <rjhansen inav net>]

> In defense of Karl, Murray, et al (including myself), this is done for
> (what we thought was) a good reason.  Pure gtk+ allows for things which
> are bad practice, in more ways than I care to go into here.  By

I don't have an objection to Gtkmm's API, save that for now it's still a 
moving target.  It gets frustrating to write code which works in one 
release, and two releases later you're stuck relearning the API.  On the 
other hand, Gtkmm has a great excuse for the API changes--it's still 
pre-2.0.

I don't view APIs as a big issue, once they've been frozen.  I picked up 
STL in two days, and figured out enough of Qt to be effective in about a 
week, just to name two large libraries with widely different APIs and code 
styles.  I think the "does Gtkmm use a simplified interface and is it a 
good idea?" question is not really a big deal at all.  Give a competent 
coder a well-documented API, a week's time and a few liters of Mountain 
Dew and the API will be learned.

> > - Gtkmm wraps around C functions. That is bad for performance.
>
> I'm not sure if this has ever been quantified.  Suffice to say that most
> GUI apps are not limited in speed by the gtkmm/gtk+ glue layer.

Let's look at PyGTK for a moment.  :)

PyGTK = object-oriented wrapper around GTK+, written in a scripting 
language not known for its blazing speed.

Gtkmm = object-oriented wrapper around GTK+, written in a high-performance 
compiled language.

PyGTK's performance = quite acceptable

Gtkmm's performance > PyGTK's performance

Gtkmm's performance > quite acceptable

> > - Some gtk+ functions are buggy. Gtkmm inherits the bugs.
>
> This is absolutely true.  It is one of the main reasons I have
> considered reimplemention.

... of course, reimplementation would create hordes of different bugs while 
trying to squash a few GTK+ bugs.  Better, I think, to leave it as it is.

> > - What bothered me is the way gtkmm tries to track data losses and
> > references. If gtk+ handles it wrong, gtkmm can't help and that is a
> > deadend.
>
> Again, true.

Of course, if GTK+ handles it wrong, then so will everything from the Ada95 
GTK+ bindings to the Guile and Perl GTK+ bindings and everything in 
between.  If Gtkmm were to be totally reimplemented from scratch, we'd 
lose a huge amount of GTK+ QA testing that we get essentially for free 
from the other development camps.

There's also another question for reimplementation.  If we're going to 
reimplement from scratch, why make GTK+ in C++?  What's the compelling 
reason to do that, as opposed to experiment, try out new ideas, make a new 
widget toolkit altogether?  As you said, monocultures are bad--if you're 
going to reimplement from scratch, why not throw in some diversity?

--All this said, I think the current approach--utilizing GTK+ to do Gtkmm's 
tasks--is the right one.

-- 
Geek Code: GAT d- s+:+ a27 C++(+++)$ ULB++>++++ P++ L+++>++++ E W+ N+ w
           PS+ PE++ Y++ PGP++ t+ 5++ X-- R tv b+++ DI++ D--- G+ e++ h*
           r* y+*