Re: New 'GObject' as base for GtkObject?

[Tim Janik <timj gtk org>]

On Thu, 9 Dec 1999, Karl Nelson wrote:

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

hum, i don't think i understand what you are talking about here
(though i haven't paid close attention to all of guillaume's posts
because of language bashing that went on there).
so if you'd shortly outline what consistancy you are talking about
and provide a pointer to that gtkprocess header generator you are
talking about, i'd apprechiate that.

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

personally i consider the quarked data a standard feature we should provide
there, especially to avoid hackery in class tress that derive from a GObject
without quarked data and figure the need for quarked data later on. those
class trees would probably end up using g_dataset_* functionality and would
then need support for dataset destruction in the base class (to invalidate
the object's dataset entry once the pointer is freed).
apart from that, support for datalists is simply required if we want the
signal system seperated as well, there'd be no facility to store the
object's handler list otherwise.
on the reference counting, that is also a definite requirement for GObject,
we can't get signal connections going without that and can't get proper
destruction (with weak reference callbacks as gtkobject has them) going
without that either.

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

having a more lightweight base object could certainly help that,
for instance looking at the GdkDrawablePrivate struct in gtk 1.3,
which has a class function pointer, reference counting and
a user_data pointer, i see a perfect candidate for a GObject derivative.

> 
> --Karl
> 

---
ciaoTJ