RE: [gtkmm] Talk about a major rewrite

["Butler, Gerald" <gbutler Jewels COM>]

	As someone only beginning to USE gtkmm I find the design goals
incredibly straightforward and well-reasoned. I believe this entire thread is
nothing but cruft. I have tried using Qt and found it lacking in functionality
and elegance. So far, my exposure to Gtk+, Gnome, GtkMM, and GnomeMM has been
nothing but satisfactory.

	I agree that the C-OO model is somewhat inelegant, but, I believe that
elegance is not the only goal at stake. As has been pointed out NUMEROUS
times, the strength of the Gtk/Gnome API is that it is *easily* (Murray et.
al. I'm sure would use this term loosely ;-) wrapped in alternative language
bindings.

	I believe that anyone who takes even a moment to consider these issues
would only have gracious praise for the efforts of the
Gtk+/Gnome/GtkMM/GnomeMM developers.

	I for one would just like to say thanks. Someday, I hope to be at a
competent enought level with GtkMM to contribute something worthwhile back to
the community.

> -----Original Message-----
> From:	Murray Cumming [SMTP:murrayc usa net]
> Sent:	Wednesday, July 31, 2002 4:25 AM
> To:	Joe Yandle
> Cc:	P. Christeas; gtkmm-list
> Subject:	Re: [gtkmm] Talk about a major rewrite
> 
> 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
> 
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
> 
> 
 The information contained in this e-mail message is privileged and/or
 confidential and is intended only for the use of the individual or entity
 named above.  If the reader of this message is not the intended recipient,
 or the employee or agent responsible to deliver it to the intended 
 recipient, you are hereby notified that any dissemination, distribution or 
 copying of this communication is strictly prohibited.  If you have received 
 this communication in error, please immediately notify us by telephone
 (330-668-5000), and destroy the original message.  Thank you.