Re: [gtkmm] Talk about a major rewrite

[Joe Yandle <jwy divisionbyzero com>]

paul, this is without a doubt the most drippingly bitter email i've ever seen
from you.  without trying to start a flame war here, i really don't think 
the original email deserved anything like that kind of response.

> i apologize ahead of time for the deeply sarcastic tone of my reply. i
> just hate it when someone who hasn't been around here before shows up
> and suggests that someone (else) rewrites everything they've done. 

this is not at all what he was suggesting.  in fact, you even responded
to the part where he talked about doing it all himself, so i'm extremely 
confused as to how you came to the conclusion that he was asking us to 
'rewrite everything [we've] done'.

as i read his email, he was asking if anyone here would like to join him 
in his project rather than pumping more effort into gtkmm.  a thoroughly
reasonable request, and not one that deserves malevolent vituperation.

> my manners below are not good, but they're better than showing up at
> someone's party and saying "your work sucks!".
> 

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.

> >- Some other interfaces are clearly written, but they don't have the gtk+ 
> >completeness.
> 
> some specific examples? AFAIK. gtkmm2 is basically complete.
> 

paul, this has been a *design goal* of gtkmm for years.  we wrap things 
in a somewhat simplified way, yet allow access to the underlying C instances 
for completeness.  

> >- Gtkmm wraps around C functions. That is bad for performance.
> 
> have you measured this? do you actually know what you're talking about?
> 

we at least agree here ;)

> >- Some gtk+ functions are buggy. Gtkmm inherits the bugs.
> 
> so? go talk to the GTK+ people. gtkmm represents the decision by many
> to use GTK+. they just prefer to use it with C++ idioms. its not meant
> to be a C++ implementation, just as the python, java, guile, perl and
> other wrappers are not. it provides the C++ programmer with a
> comfortable way to use GTK+. nothing more (or less).
> 

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

> >- If gtk+ changes, gtkmm has to change, too (most of the times).
> 
> so? if anything changes, something changes. what's your point?
> 

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

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

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

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

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

> >- 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
intellectually honest of you to accuse him of "suggest(ing) that someone (else)
rewrite(s) everything they've done".

> >It's Summer and I'm taking my holidays. You can think of my suggestion and 
> >talk about it. All I wait for now is your comments (the core team 
> >preferably). As from September we could talk about the real implementation. 
> 
> tell you what: why don't wait till your holidays are done, then
> continue doing what you normally do. the gtkmm team will keep doing
> what they do, and people will continue to be about as happy as they
> are right now.
> 

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.  

it is extremely reasonable to say that keeping people "as happy as they are now" 
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.

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