Re: Introspection API



Dnia 25-02-2005, pią o godzinie 14:06 -0500, Owen Taylor napisał:
> > yeah, portability.
> > 
> > it's not very encouraging that everyone seems to adopt
> > their own local copy of libffi.  it means trying out
> > glib on new platforms is going to be a pain, subject to
> > bugs, etc.  by contrast, generating marshallers is totally
> > portable, and we do it anyways, i believe, for signals.
> 
> I'd love to get rid of marshaler generation for signals ...
> something we could make optional if we had a libffi dependency
> or equivalent.
> 
> Dynamic marshaling code is available for an extremely wide
> range of platforms and new architectures don't pop up every
> day... and I think our emphasis has to be on making GTK+ work
> well on the architectures where people actually run it.
> 
> The amount of marshalers generated for something the size of
> GTK+ would be non-trivial. I'd guess somewhere in the 200k-500k
> of object code range.
> 
> And for demarshalers (calling from C into non-native code) it 
> gets worse, since the main ways I know of doing that
> require multiple copies of each demarshaler. (How do you tell
> if widget_class->expose_event or widget_class->button_press_event
> was called if they are the same demarshaler?)

Note also that having compiled marshallers means you'd still need to
generate them and package as FooGTK, and J. R. Hacker would still need
to apt-get foogtk before using it from Foo interpreter, instead of
simply issuing 

import gobject
import gtk

and have GObject set up things at import time so that any subsequent
import statement would search amongst installed GObject-using libs (I'm
pretty sure you can do that in Python, as well as in Ruby and probably
other dynamic languages too). That would reduce amount of work required
to get any GObject-using lib accessible from GObject-aware language to
calling update-gobject-metadata (or similar) from apt-get / emerge /
make install. Isn't that wonderful perspective? :)

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]