Re: [gtkmm] Talk about a major rewrite

[Joe Yandle <jwy divisionbyzero com>]

Murray, I truly respect the time and effort you've put into this project.
You seem to be taking this thread as an attack against your current work,
which it is not at all (at least on my part).  

I'm approaching this thread from the perspective of "wouldn't it be nice 
if we had a completely C++ GUI toolkit that respected C++ conventions and 
whose internals had a fairly low barrier of entry for developers?"

I can't imagine that I'm the first user/developer of this project to 
wish for this.  But I'm extremely realistic about the chances of such a 
project actually succeeding.

> 
> Have you lost your senses? Some guy thinks he's found a bug but hasn't
> even reported it, so you both agree that the logical next step is to
> start a new project?
> 

Huh?  This has *nothing* to do with a (specific, unreported) bug.  This has 
to do with long term issues with the gtk+ binding layer.  

Clearly, I'm approaching this discussion from the perspective of someone 
who spent a considerable abount of time on gtkmm-1.2, and only barely
touched gtkmm2.  When I was last around here, you and Karl were still
trying to figure out how to deal with gtk2:

    http://www.geocrawler.com/mail/thread.php3?subject=%5Bgtkmm%5D+New+SignalProxies&list=1110

If everything now works, that's wonderful.  But it doesn't in any way change
the fact that a lot of really black magic is going on under the hood.  I've
used this project since the pre-1.0 days, so I freely admit that my perspective 
is biased from having dealt with it then.

> 
> It's not clear to me whether a fork of Qt is possible. I mean, Qt is not
> free (libre) on Windows, and it is not LGPL, so surely they wouldn't
> allow someone to make a fork that was fully LGPL everywhere.
> 

Of course not, and that's not what I was saying.  I simply said that anyone
can fork Qt/X11, provided s/he uses strict GPL.  I specifically stated the
restrictions of LGPL vs GPL, so I'm not sure what your point was here.

> > 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.
> 
> How can any body have any idea what you are talking about? Can't you
> even give one example?
> 

Off the top of my head:

The debate over connect(), connect_before(), and connect_after().  IIRC, we 
decided to present a more simple interface then gtk+ did, at the cost
of completeness.  

The widow destroy/delete_event_impl debate.  I don't really remember what 
our final solution was, but I think it ended similarly.

I vaguely remember other such debates over the years, but without a lot more
googling I won't be able to dredge them up.

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

Two words: CList and CTree.  In fact, you've stated before that you had to 
use Qt in some professional projects because CList and CTree were so badly
written (and gtkmm could do nothing to fix, being only a wrapper).

Also, Gtk::Text and it's editing performance on large chunks of text.

Granted, these are gtkmm-1.2 issues.  Is there really nothing in gtk2 which
behaves badly?

> 
> > > - 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.
> 
> Being a wrapper isn't what everybody would want, but it works. And if
> you agree that "this is a mess" then
> a) Define "mess", like and stuff, you know.
> b) Explain why it is a "mess" as defined in a). We've done a lot of work
> to simplify and document gtkmm2. 
> 

Here's an email thread between you, Havoc, and Owen:

    http://mail.gnome.org/archives/gtk-devel-list/2001-October/msg00161.html

Do you want me to dig up more?  

> > > - 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.
> 
> Hello? Ever thought of sending patches to GTK+?
> 

Karl, at one point, was completely unable to get O(1) tail access to many
structures coming out of gtk+, and the gtk+ people refused to accept his
patches.  I think this is from that argument:

    http://gnome.dti.ad.jp/mailing-lists/archives/gtk-devel-list/1999-August/0042.shtml

Guillaume frequently bitched about the gnome people refusing to accept 
patches that would enable him to wrap more sanely.  I'm sure he would
be more than happy to provide details.

In the SignalProxy thread referenced above, Karl complained that the gtk+
people would not provide the Closure hooks he needed to wrap things easily.

Do you remember the issues with exceptions?  The gtk+ people
refused to add -fexceptions to their compile flags, because they were worried
it would impact their performance.  Without it, any exceptions which hit 
C code as the stack unwinds (think C++ callbacks to widget events) will simply 
abort() without reaching application code.

Perhaps you have a better working relationship with the gtk+ people than
Karl or Guillaume did.  

> > 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.
> 
> gtkmm2 is increasingly well documented. Why start a new project with no
> documentation instead of helping us to complete the documentation for
> gtkmm2?
> 

The point isn't the documentation, it's the black magic.  A true C++ GUI 
toolkit without the black magic of Qt (moc) or gtkmm (c/c++ glue layer)
would, in my opinion, be a Good Thing(tm).

> > It's been ogre's choice for too long now.  Maybe it is time to finally do
> > something about it.
> 
> Patches are the way forward.
> 

Patches are the way forward for gtkmm2.  I've always felt that this project
was like working on a nuclear reactor with scotch tape, and I really don't
think I'm the only one with that perception.

Finally, let me say that I am *NOT* wholeheartedly endorsing the idea of
writing a new gtkpp (or whatever) from scratch.  I just think that the 
original post deserved intelligent commentary and response, not an all 
out flaming castigation.

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