Re: [gtkmm] Talk about a major rewrite

[Paul Davis <pbd op net>]

>again, this was not my impression of his tone or content.  some of his 
>points were valid, others were not.  *nothing* he said implied that gtkmm
>sucks, only that wrapping a fucked up OO C toolkit is bound to create problems

sure. but thats the whole point of gtkmm. if you want a true C++
toolkit, use Qt or write a new one but don't go trawling on the gtkmm
list with vague claims about how gtkmm sucks. as you point out karl
and guillame both raised some similar points - nothing was done
because its not part of the project's goals in any way. gtkmm is not a
C++ toolkit. its a wrapper around a "fucked up OO C toolkit".

>read some of karl and guillaume's rants about dealing with bugs in 
>gtk+/gnome.  the mailing list archives are full of them.

its strange. i don't disbelieve you in any way. its just that i don't
actually remember any of them. this suggests something to me about the
nature of their complaints being the result of a particular
programming style or worldview. i stand as a counter-example who can
find almost nothing to complain about in gtkmm except missing wrappers
for a few rarely-used things.

>his point was that gtkmm is a slave to changes in gtk+.  

yes, because gtkmm is BY DESIGN a slave to everything in GTK+. this
was never a project to write a C++ toolkit.

>> >- Gtk+ tries to implement an object model in palin C. Gtkmm wraps around 
>> >that. This is a mess.
>> 
>> agreed. not that much of mess, though.
>> 
>
>again, read the archives to see exactly how much of a mess this has always bee
>n.

the implementation is a mess. but as a gtkmm-using programmer (rather
than a gtkmm programmer), the mess is more or less completely
invisible to me.

>> >- The gtk+ object model is still a good framework and design to start with,
> 
>> >in a purely C++ environment.
>> 
>> why? as in "why bother?"
>> 
>
>i've thought of this.  karl used to talk about this.  guillaume left, for many
>of the reasons in the original email.  clearly, it's not a completely outragou
>s suggestion.  

no, its not completely outrageous. but the starting point should be "i
want to write a really good C++ toolkit", not "gtkmm sucks, come with
me and we'll write a better one, even though i can't explain what
precisely is wrong".

>> >- 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 deaden
>d.
>> 
>> i have tens of thousands of lines of gtk/gtkmm code. this doesn't
>> happen unless me, and it won't happen to you, the programmer, unless
>> you make a mistake. another alternative is a bug in gtk+ but these
>> seem pretty rare in the object management category. 
>> 
>
>saying "it's rare" doesn't in any way dispute his point.

no, it doesn't. but it can make the significance of his point
extremely, perhaps even vanishingly, small.

>> >- IMHO this mess I describe is the reason gtkmm is not very popular. Qt is 
>> >and shows some path to follow.
>> 
>> aha. you definitely don't know what you're talking about.
>> 
>
>did you miss the 'IMHO'?  are you saying that he doesn't know what his own
>opinion is?  maybe you're implying that he has no right to state his opinion
>here?

what evidence is there that the design of Qt is the reason for its
popularity. the "IMHO" was attached to a sentence claiming 
	    
	   (1) there is a mess
	   (2) its responsible for more programs being written with Qt
	         than gtkmm

point (1) is the main bone of contention. point (2) may or may not be
true, but its just as likely that Qt is popular because KDE is popular
and because KDE is de-facto C++ versus Gnome's de-facto C. Most people
wanting to write for Gnome choose C, and thus choose GTK. Most people
wanting to write for KDE choose C++, thus choose Qt. 

however, the IMHO was not attached (though its always implicit in
almost all human communication) the claim that Qt "shows some path to
follow". Qt is not a GUI toolkit, its a development platform. It
contains all kinds of cruft that, while useful, has no place being
integrated into a GUI toolkit .... IMHO ... Murray has done a
perfectly reasonable job of explaining why the Qt/gtkmm choice is
settled for many of us.

>> >- 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.
>> 
>> how ambitious. how conceited.
>> 
>
>how horrible of him to ask us to join an interesting project.  how wonderfully

he didn't just ask us. he arrived, told us our work was crap and then
asked us to join his (largely undefined) project that might replace ours.

>karl whined and bitched about dealing with gtk+ for years.  so did guillaume 
>(before he left).  so did havoc (before he left). so have i.  so has almost 
>everyone who's used this toolkit, at one point or another.  

then leave. gtkmm is a wrapper for GTK+ so that C++ programmers can
use GTK with C++ idioms. if you think GTK+ is a piece of crap, then
don't use gtkmm.

there are a few things in GTK+ that i find problematic. i have no
doubt whatsoever that similar issues exist in every other toolkit
(XForms is the only one I am reasonably familiar with) once you start
writing complex applications. but do i think its worth junking? no
way. do i wonder why they implemented an object model in C?
sometimes. but then i read about those guile/python/perl/c++
programmers using the same common toolkit, and i have a satisfactory
answer. 

>it is extremely reasonable to say that keeping people "as happy as they are no
>w" 
>is a less than desirable situation.  i'm not saying that it is at all 
>clear that another project is the correct solution, but to dismiss the idea
>out of hand with such a biting, vicious response serves the interest of no one
>.

i agree.

--p