Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

Tim, 

I think this is definitly the right track.  But is does miss
one of Guillaume's points, consistancy.  It is not necessary to
work in a language that forces it, but if a simple macro format
converted a base format (like the gtkprocess header generator)
was provided it would at least ensure the object system was
easier to use and more consistantly applied.  

Minor comments...

> - support for per-object quark data (the base GObject shouldn't
>   take up more than 12 bytes, i.e. a class pointer, reference count
>   and a GData* pointer)

I don't see why it even needs more than the class pointer.  The
data and reference pointer could be added in a type derived from
the base object if size was really an issue.  

> - support for gtk-alike object signals
> - basic support for a more flexible parameter system to get/set/monitor
>   object properties

Definitely a plus.

> - hooks for type system change notification (type/class/object creation
>   and destruction)
> - hooks for type plugin implementations
> 

[...]
> - we have a great potential here, to fix the remaining holes with regards
>   to language bindings, assuming that language binders participate in
>   the process of accomblishing this library

It will never be possible to fill all the holes, but 
just knocking off the major ones would make life a lot better.  
However, consistant use of the object system would do
more for us than the actual design.  The Gtk-- and Libsigc++
project members woould be happy to lend support.

--Karl