Re: GObject extension propose (GContainer)

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

Qui, 2006-06-15 �13:00 -0400, Tristan Van Berkom escreveu:
> Tim Janik wrote:
> 
> >On Thu, 15 Jun 2006, Fontana Nicola wrote:
> >
> >  
> >
> >>Hi all,
> >>
> >>I'm a GObject based libraries (for UI purpose and not) user and I often need
> >>a generic container to derive my own types. In my opinion, I think this
> >>generic container must be included inside the GObject library ... it could
> >>be used by a lot of derived libraries providing a common approach.
> >>
> >>I published my solution - that is, what I am currently using - on
> >>sourceforge.
> >>
> >>http://sourceforge.net/projects/gcontainer/
> >>
> >>Is it a good idea? Is something planned in this direction? Am I totally
> >>wrong?
> >>
> >>I need feedbacks ...
> >>    
> >>
> As a side note... I've been working on container --> child relationships and
> honing them down inside the glade builder... objects may for example have
> object delagates that are "owned" and in turn may "own" other delagates...
> this is all functional with libglade facilities and the future gtk 
> builder also
> (from the design as of yet...)... this concept of "types of container 
> relationships"
> is also usefull for GtkMenuShell --> GtkMenu for example (not just any 
> GtkWidget
> can be added to a menushell).
> 
> All of that just to say... I cannot count the times I've thought to 
> myself that
> GtkContainer should really just be GContainerIface, and implemented by
> whatever interested objects that want to parent other objects...

  That's interesting, but I wonder what is the runtime penalty of
interface lookup compared to normal class structure lookup?  Is it
really OK to use an interface for this, or is it better just to add a
new virtual methods to the GObject class?

>  I think
> that what we need is not really "yet another container api", but a container
> api that is a unified front for generic handling of the GTK object 
> hierarchy at runtime.

  Actually, for the python language bindings we could use a generic
GObject container interface.  See
http://bugzilla.gnome.org/show_bug.cgi?id=303266

  Regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic