Re: [Evolution-hackers] Python plugin interface?
- From: Alessandro Decina <alessandro nnva org>
- To: Evolution Hackers <evolution-hackers ximian com>
- Cc:
- Subject: Re: [Evolution-hackers] Python plugin interface?
- Date: Thu, 26 May 2005 13:04:16 +0200
On gio, 2005-05-26 at 14:38 +0530, Not Zed wrote:
> I had thought of writing a code parser which could scan the structures
> and convert them to xml or something, so then you could more easily
> write marshallers for every language by using this pre-parsed data.
> But thats a lot of work in itself to do right, so for the mono plugin I
> just started wrapping stuff by hand. At least in mono wrapping C
> structures is pretty simple, so although tedious it isn't a huge amount
> of work since there arent that many structures to wrap (e*popup, etc).
It is certainly easier to wrap E*Popup. The real problem is camel.
> Another idea which may be useful for some backends would be to include
> type information in the 'function spec', the string used to identify
> methods as passed to invoke(). That way you could pre-marshal types so
> that the callbacks get the right type rather than a C pointer they have
> to marshal themselves. But I dont know if you've already done that or
> if it is doable or even worth it. e.g. with mono it really only saves
> one line of code in each callback anyway.
Well I can not pass a C pointer to the python interpreter (I could wrap
it in a CObject but it would be still unusable from python).
So for the py wrappers I am using an hash table of hook-IDs and
target-marshallers. Every time a callback is invoked I marshal its
target according to the hook id.
> Camel is another issue too, simply because of the size of the interface.
> Perhaps the CORBA interface i'm working on could get around part of that
> problem ...
Yes a CORBA interface would definitely help.
So for the moment I will not wrap camel.
I am new to GNOME and bonobo, but with the-eyes-of-a-plugin-writer I'd
like to see CORBA everywhere :)
> Oh, I presume python handles threads easily? FYI some of the
> e_plugin_invoke()'s can come from arbitrary threads.
Yes I noticed this reading the code.
One thread must acquire the CPython Global Interpreter Lock before using
the CPython API. The loader has already support for this.
Cheers
--
Alessandro Decina <alessandro nnva org>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]