Re: [gtkmm] Talk about a major rewrite

[Murray Cumming <murrayc usa net>]

On Wed, 2002-07-31 at 20:49, Joe Yandle wrote:
> 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

That site is down now. Maybe you mean this thread:
http://marc.theaimsgroup.com/?t=100604992700001&r=1&w=2

Is there some point you are trying to make by linking to that thread? I
don't see the relevance.

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

As you said, you've barely touched gtkmm2. There is no black magic.
 
> > 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.

I'm not making a point. I would honestly like to know whether a fork of
Qt would be possible, and if that fork could be LGPL anywhere or even
GPL on Windows/Solaris

> 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 difference is slight, and GTK+ coders generally know what to do. We
have a simpler interface. What's the problem?

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

The GTK+ behaviour is arguably appropriate for C coders. We made our
wrappers behaviour more appropriately and simply for C++ coders. What's
the problem?

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

You don't need to dredge up old problems. Show us current problems.
 
> > > > - 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).

At the time gtkmm2 wasn't ready. I'd use it now instead of Qt. And I
made a mistake actually - Qt's QTable widget is also pretty lousy - I
listed some QTable problems in my diary at the time.
 
> 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?

Not that I am aware of. GTK+2 isn't just a new version number.

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

As you see at the end of that thread, we solved the specific problem.

There is code to deal with C/C++ lifetime issues in gtkmm2, but I don't
think it's what Owen calls a hack. If it's simple and clearly
documented, and reliable, and understood, and the
best-way-to-solve-the-problem then is it a hack? They were hacks in
gtkmm 1.2, with which Owen was familiar, because gtkmm 1.2 had comments
saying approximately "don't change this code - it seems to work now.".
It did work, but that wasn't good enough for gtkmm2.

> 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

That's not a complete thread, I have no memory of it, and it doesn't
mean much to me, so I can't comment on that, 

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

I submitted and committed a heap of minor patches to the gnome libs that
were specifically for gnomemm I had no problems.
 
> In the SignalProxy thread referenced above, Karl complained that the gtk+
> people would not provide the Closure hooks he needed to wrap things easily.

A Closure mechanism _was_ added. It's used by by Python bindings, but
Karl advised me more recently that we didn't need to use it for gtkmm.
He was correct.
 
> 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.

I don't remember us ever asking them. I doubt that we asked them during
the GTK+2 phase. But I doubt that they would expect to have much control
over how their source code is compiled - isn't that something for
distros?

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

The exceptions situation isn't perfect, but I believe it's mostly solved
now. See NEWS or the ChangeLog.

> > 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.
[snip]
> 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.

I don't think it's wise to express such strong opinions about something
that you freely admit you know very little about - gtkmm2. You don't
need to be a contributor to understand how much more organised we have
been with gtkmm2 - you just need to look at the ChangeLog, the
announcements, bugzilla, and this mailing list.

If you want to talk about old pre-gtkmm 1.2.0 problems then maybe we
could start a gtkmm-history list. You could get into gtkmm <1.0 too and
have lots of fun. Personally I don't see the point.
 
-- 
Murray Cumming
murrayc usa net
www.murrayc.com