Re: [gtkmm] Talk about a major rewrite

[Murray Cumming <murrayc usa net>]

On Wed, 2002-07-31 at 01:18, Joe Yandle wrote:
> > 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.

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?

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

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.

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

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

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

> > - 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+?

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

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

-- 
Murray Cumming
murrayc usa net
www.murrayc.com