Re: Scripting in Gnome
- From: James Henstridge <james daa com au>
- To: Bob Smith <bob thestuff net>
- Cc: jamie <jamiemcc blueyonder co uk>, Bill Haneman <Bill Haneman Sun COM>, GNOME Desktop Hackers <desktop-devel-list gnome org>
- Subject: Re: Scripting in Gnome
- Date: Fri, 06 Feb 2004 22:56:09 +0800
On 06/02/04 11:33, Bob Smith wrote:
Hmm... This would be a lot of work to program in all this information
manually.
I believe the GTK# project has a program that analyzes C files and
produces an XML description of the GObjects... If they do, maybe it
could be modified or an XSLT document be created to convert that
information to a form that can be automatically linked into a
library/program.
The interface descriptions in GTK# (which are actually quite similar to
the s-expression based ones most other language bindings use) are not
quite what I was referring to, since it doesn't really tie into a type
system very well. If you look at the ORBit2 code, you get a
CORBA::TypeCode for each function argument and one for the return value.
Each typecode has a kind (which is picked from a fixed size enum), such
as "int", "enum", "string", "struct", "sequence" or "interface". For
the struct type, you can get a list of the struct member names along
with TypeCodes describing the types of the members. This makes it quite
easy to write a finite amount of code that can convert pretty much any
CORBA type into a Python equivalent, for instance.
The other reason for not picking XML is that it isn't very shareable, so
each application that loads the interface description will have a
separate copy in memory. In contrast, ORBit IInterfaces are usually
static data loaded from a shared library, so are quite shareable.
Similarly Mozilla's XPCOM type libraries are structured in such a way
that they can be mmaped read only, making it shareable between multiple
processes.
* Some way to invoke a method on an instance programatically.
The last one is probably most difficult. The two ways to solve it are
to generate marshalling code (similar to what we do for signals), or use
something like libffi to construct the function calls (probably making
use of the interface information to help construct the call).
Yeah. Mono seems to be doing fairly well doing this sort of thing. Maybe
their team can provide a good solution to the problem.
Yep. It looks like they are using libffi. If the scripting framework
ended up using libffi, I would hope that it has some layer on top that
is a bit easier to use ...
Know how COM on Python works? Does it create proxy Python objects? We
could do the same thing...
Invocations are performed using the IDispatch interface, IIRC. It can
run in two modes -- in one it generates Python source files that call
Dispatch from a COM typelib. In the other it does everything at runtime.
James.
--
Email: james daa com au
WWW: http://www.daa.com.au/~james/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]