Re: New 'GObject' as base for GtkObject?

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson wrote:
> > 
> [timj about MI]
> > > and finally i guess there'd be some non-C++ language binders who
> > > are going to rip our asses off for that ;)
> 
> yes.

Again I think we are over complicating this.  Adding MI just
means there is the option of breaking apart interfaces into sub
pieces.  This doesn't mean that it will be used to make a tree
that can't be represented in a single inherance tree.  Only that
we can map the SI tree to MI classes and simplify the code base.


> > I don't quite understand why you think it complexifies the interface
> > all that much.  It took me only 2 hours to modify a simplified
> > copy of the gtkobject system to have MI.
> 
> our languaje (and I suspect many more) doesn't support MI,
> IF gtk is going to have MI, how that impact us ?

It wouldn't affect you.  Languages without MI (or even objects
for that matter) just wrap the final widgets.  Since the wrap
of the final widget would be the same then there should be no
difference.  For languages like java or C++ where some type
of MI is possible there would be improvements in the wrapper
because we wouldn't have to wrap the same function in 5 places.

Example: all the gtk_*_set_adjustment interfaces would become
1 function callable on all the types that had that function before.
Languages without MI would wrap just as before.  Languages with
MI would place set_adjustment in a class and derive only those
few classes with set_adjustment from that adjustment class.

In other words "Don't Panic".  Even if by some fluke I convince
people it is a good idea, these issues would be addressed.  I
don't beleive there will be any harm to other bindings. 

You can look over test2.c in my example of the MI system and
find from your prospective of wrapping TypeD (equivelent to
gtk+ class) there would be no changes.

--Karl