Re: [gtkmm] Talk about a major rewrite

[Joe Yandle <jwy divisionbyzero com>]

Before I go into detail here, let me say that I have wanted to do something
like this for a very long time.  Last year, I proposed reimplementing
qt/kde with libsigc++ to get around moc (which is the main reason why I 
still use gtkmm):

    http://marc.theaimsgroup.com/?l=gtkmm&m=100422456621893&w=2

> Hi all.
> I'm just another programmer, writting programs with gtkmm. Last week I got 
> desperate enough to send this e-email.

3 years ago, I was just another programmer, writing programs with gtkmm.  I 
understand your desperation quite well ;)

> I have come accross a whole series of bugs and pitfalls of gtkmm. I think 
> there is no hope of dealing with them, because many of them relate to gtk+ 
> itself. 
> My suggestion is to re-write gtkmm, so that it only has C++ code (and not 
> wrap around gtk+). 

I would love to do this.  Karl (a former maintainer of gtkmm) used to talk
about doing this.  There is only one problem: it would take a very large
amount of time to do.  At least that's been our excuse for the last few 
years.

> Since all gtk+ code is GPL'd, we can copy-paste that into 
> C++ functions.

It would, of course, be a little more complicated than this, if only 
because we could do so much better in pure C++.  All of the nasty OO kludges
would go away, but because of this we'd have to do more than simply cut and 
paste.

> This mail is just a summary. I'm willing to write a whole series of 
> mails-docs etc to discuss my view. Here are some points to answer your first 
> questions:
> - Qt won't do because of licensing. I also want some features for me; Qt is 
> not open-source like that.

This is not at all true.  Qt/X11 is GPL, so we are perfectly free to do
whatever we want with it, as long as we retain the GPL.  Currently, gtkmm 
is LGPL, so we would be moving to a (more|less) restrictive license.

Let's not get into a GPL holy war here.  All I will say is that LGPL allows
proprietary software to link, while strict GPL does not.  I'll leave it up
to everyone here to decide whether they care about this, and how.

> - Some other interfaces are clearly written, but they don't have the gtk+ 
> completeness.

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 presenting a simplified
interface, we allow the developer to develop more easily, while keeping the 
ability to decend to C and retain completeness.  

> - 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.

> - Some gtk+ functions are buggy. Gtkmm inherits the bugs.

This is absolutely true.  It is one of the main reasons I have considered
reimplemention.

> - If gtk+ changes, gtkmm has to change, too (most of the times).

True, but for the most part this is restricted to interfaces.  The gtk+ 
interfaces rarely change, except for major releases.  wrap()'ing new interfaces
is rarely difficult.

> - Gtk+ tries to implement an object model in palin C. Gtkmm wraps around 
> that. This is a mess.

Again, absolutely true.  Another good reason to reimplement.

> - The gtk+ object model is still a good framework and design to start with, 
> in a purely C++ environment.

True again, as long as you're discussing the object model in the (very)
abstract.  

> - 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.

> - IMHO this mess I describe is the reason gtkmm is not very popular. Qt is 
> and shows some path to follow.

qt/kde were much more mature than gtkmm, at least until at least gtkmm-1.2.x.
Most gnome hackers love C, so there was very early a pigeon-hole effect
where C++ programmers drifted into the kde corner.  We've spent years 
trying to reverse the flow, but we obviously have very far to go.

Of course, once a C++ programmer does find gtkmm, s/he has to choose between
the following:

1. a well documented and functional C++ toolkit with lots of nasty black magic.
2. a not well documented, mostly functional C++ toolkit with lots of nasty
   black magic.

It's been ogre's choice for too long now.  Maybe it is time to finally do
something about it.

> - I could (thoretically) write that thing myself and let you go on with 
> gtkmm. It wouldn't be fair, however, if my work made yours obsolete.

I don't think this is an accurate characterization.  gtkmm has the ability
to wrap() *any* gtk+ object, regardless of whether it's in the base library
or not.  So gtkmm would always have something over gtk++ (or whatever you
would call it).

I, personally, would be willing to make the tradeoff.  Many others would not.
But that's a Good Thing(tm).  Monocultures tend to be a Bad Thing(tm).

> - I am thinking of some projects I want to open. I need a stable and 
> efficient interface myself. I hated it when an app I wrote couldn't run, 
> because of obscure gtkmm behaviour. I'll discuss more about that later.
> Anyway, thanks for your time if you have read it all down to this line.
> 

Thanks for starting this discussion.  I'm curious to see how others respond.

cheers,
--
joey yandle                             ___====-_  _-====___
www.divisionbyzero.com            _--~~~#####//      \\#####~~~--_
/jwy/pubkey.asc                _-~##########// (    ) \\##########~-_
                              -############//  :\^^/:  \\############-
                            _~############//   (@::@)   \\############~_
                           ~#############((     \\//     ))#############~
                          -###############\\    (^^)    //###############-
                         -#################\\  / "" \  //#################-
                        -###################\\/      \//###################-
                       _#/:##########/\######(   /\   )######/\##########:\#_
                       :/ :#/\#/\#/\/  \#/\##\  :  :  /##/\#/  \/\#/\#/\#: \:
                       "  :/  V  V  "   V  \#\: :  : :/#/  V   "  V  V  \:  "
                          "   "  "      "   \ : :  : : /   "      "  "   "