Re: [OT] Re: Third draft (was Re: defs files)

[Karl Nelson <kenelson ece ucdavis edu>]

> > 
> > Seriously Havoc, don't you think I'm aware of all this ? :-)
> >
> 
> Then why do you keep complaining about it?????? I do not understand
> the hostility toward GTK+, GNOME, and the C bindings if you know this
> stuff. Yesterday both you and Karl posted or mailed to me rants about
> GTK and GNOME maintenance.

Mine was a rant and was private.  I feel that the gtk+ 2.0 path
is completely decided and I mean to try to open it up a little more.
It is still not clear to me if gtk+ is going straight to 2.0 or 
making a 1.4.  If there is a 1.4 that there is more time for me
to compose ideas.

  
> Especially since, as Karl points out, Gtk-- has 4K lines of manual
> code and most of the other language bindings are _far_ larger and thus
> _far_ more difficult to maintain, and only the Gtk-- maintainers are
> complaining like this. 

(Gtk-- was over 11k lines before we improved our abstractions.)

As I have stated many times before, Gtk-- is much closer to the
flame that any of the other wrappers.  I know nearly as much about
the gtk+ internals as I do about the gtk-- ones.  Often what I see
is APIs which can use more polish or a bit raw.  (Mainly because
I spend all my time on those sections of gtk+ which are poor and
didn't wrap well.)  Also unlike all the other wrappers, we are often 
tapping into gtk+ structure.  So I am always craving for more
and better abstractions.  I like gtk+ and think it is by far
one of the most flexible kits I have used.  If I didn't think
so I wouldn't be here.

During that time I have formed many ideas how to improve gtk+ itself.
I could just wrap gtk+ and make a thick interface for our improvements
in C++.  (Which is what all the other C++ wrappers basically do!)
But honestly, I would rather try to get some of the ideas down into gtk+
because they may be benificial to the C users.  They are all 
abstractions aimed at increasing flexiblity. 

The three I am compaigning for are 
  * abstraction of callbacks  (closures)
  * abstraction of item holders  (slots)
  * delegation to items holders and a defined set of axiom.
     (interfaces and redirected delegation though casting)

Whether this is achieved through MI or interfaces or some clever kludge, 
I don't care so long as it is carefully thought out and a long term
solution.  

If anyone is interested in discussing these ideas and try to
bring them to the point where they could form good patches,
contact me.  I try to discuss it on this list, but they are
quite far advanced and untested so generally they are not
a good spend of time for the lead developers.  Which is fine,
but when no one else discusses then there is no community and
thus no advancement outside what the core developers implement.
And that is what I think is very bad.


>Furthermore, you are complaining about slow
> response time from people maintaining a couple hundred thousand lines
> of library code, rather than several thousand lines. Give them a
> break. There is a lot of code and there are lots of people other than
> you throwing patches at GTK and gnome-libs.

I am the only one complaining of slow response.  (and am prown
to exageration.)  I appologize.

   
> Please try to be productive and helpful!

I am.  I am trying very hard to make sure that the gtk+ object
system has enough features to where it can be broken into 
a set of independant Axiom in which high code reuse can be made.

But I am definitely trying at to high of level.  Thus
I intend to send a patch which allows for "signal aliasing"
next.  It is a simple patch to solve the age old problem
that the default action for one widget is different than another.
For example, the default action of a button should be to
be clicked and a toggle button to be toggled.  This has
resulted in large sections of gtk-- code where we probe the
type of object to try and figure out what callback to assign
at default.  So instead why not add an entry in the hash table
so that calling some signal repoints to whatever is the 
appropraite default.  It is a harmless fix, useful to gtk--,
and useful to C users.  Shall I finish the patch?  Will
it be considered for inclusion?


> I am tired of reading the daily
> GTK-GNOME-maintainers-dont-listen-to-us flame from you and
> Karl. Seriously. It is just absurd. The fact that Gtk-- requires some
> work is NOT our fault, for the reasons given above that you say you
> are aware of. GTK is simply not written purely for Gtk--. There are
> tradeoffs and the maintainers are simply unable to make every change
> you might want. On the other hand they are happy to make changes when
> possible (and if they have time or you send patches!).

First of all I don't believe it is just the gtk-- maintainers
who have problems in the gtk+ code base.  I talk to other
C++ wrapper writers and share experiences.  Gtk-- just
appears to have two of the most vocal people, Guillaume and myself.

I am happy to send patches if I know that they are what is wanted.
Currently the development seems so closed to me that I can't say
that the idea hasn't been thought of and reject.  Or I am told
the problem is too hard, which I don't see in part because
I can't know that it conflicts with some undocumented internal. 
(Saying the gtk+ internals are devode of comments is an understatement.)

I do think it is fair to say I have tried to contribute to gtk+
for over six months, but have yet to se any idea, patch or even
bug fix make it in.   So far I have tried to
  - submit a patch for name clean up in gdk
  - submit a patch for depth checking for gdk
  - submit a patch for semaphores, (yes not all that useful,
     but good for users to see how to build better concepts)
  - fought to have a tail pointer added to glib.
  - wrote an entirely source compatible version of glist with
    tail pointers.
  - fought to have an abstraction added for containers 
    so that you can use the same set of methods on glist, gslist,
    and queue
  - tried to get the discussion of how to make better delegation
    and allow for at least some special operations to mimic MI.
  - demonstrated a system of MI which I felt could be easily bond
    to many languages.  
  - submitted dozens of bug reports for conformation to the list.

Many got put out for good reasons, like they didn't get looked
at before they went stale, or they depended on each other which
became stale, or they came at a time when the core developers
has that area in flux or they weren't right for gtk+.  All
understandable, but then you can see how I might feel a bit put 
out.  Add in some ass flaming me just because I participate with
the gtk-- binding and I lose objectivity.



> Karl says that some GNOME people have been flaming you guys, and I do
> apologize for that, and fixes for gnome-libs _will_ go in regardless
> of those people. But flaming all the maintainers because some few
> dudes have been flaming you will not help anything. Just flame those
> dudes back and be done with it, or ignore them.

I will make a concerted effort to ignore the flamers.  GL doesn't
see it because he does go to the IRC area to try to discuss 
ideas.  As I have no contact with any developers beyond IRC and
mail, nor have I met any of them, it is very hard to empathize when
being flamed by people.  Yes, I know I should take two steps
back. 


> I am hoping that meeting you and Karl in Paris will help a lot to get
> everyone feeling better, and I am looking forward to it.

I don't think I was invited.  But if you are every passing by the 
California Bay Area, be sure to drop me a line.  I am a 
far more animated person in real life than over the wire. 
I did see Rasterman recently, and got to listen to 
him talk about being an artist and not a coder while at the
same time say he rewrites any code he doesn't like.  


> That is good to hear. But please, at least file bug reports for
> changes that you really want made; we'll go through the bug reports
> before we freeze. If you don't tell us what to change then it won't
> happen. And if it doesn't happen I do NOT want to hear about it after
> we freeze the library. :-)

Will do.  Where should gtk+ bugs go?  The last ones sent
to the mailling list were never confirmed (or responded to) thus
I did not report them to GNOME bug tracker.  


If we really want to improve things rather then just having vent 
feasts between developers such as you and myself ...

  - add a road map of future design so that outsiders can contribute
    in a direction.

  - add a forum in which ideas can be threaded and discussed without
    falling away like this mailing list.   Projects have short
    collective memories and people are often too busy to continously
    keep up with the development.  Digging back three months
    to find that something was discussed in 2 messages here and 
    4 messages there is an act in futility. 
or 
  - hold an archive of minutes or list of critical maillings for
    key future decisions so that no one has to read through my 
    wasted bandwidth discussing this in the mailing list. :-)

  - a list of design flaws in the gtk+ framework even if they 
    aren't planned to be fixed so that someone outside can come
    up with clever solutions which keep the compatiblity.

  - leave some indication what the time line and dead line for
    ideas are in the project so you don't have me arguing when
    people are too busy working on other things to care.

  - keep status pages up to date.  The gnome core 
    page had gtk-- on schedual for November 1999 release!

If even some of these things happened than life then the gtk+
design process would be more open and more enjoyable.  We just
need someone willing to take on this thankless task.
 
--Karl