Re: [Evolution-hackers] Python plugin interface?
- From: Not Zed <notzed ximian com>
- To: Alessandro Decina <alessandro nnva org>
- Cc: evolution-hackers lists ximian com
- Subject: Re: [Evolution-hackers] Python plugin interface?
- Date: Wed, 25 May 2005 16:44:07 +0530
For your enjoyment, i've just committed work which allows plugin drivers
to become plugins themselves. I've moved the mono extender to be a
plugin to demonstrate/test the idea, although i haven't tested it a lot.
See plugins/mono for an example.
But basically you just setup a library plugin like normal and add a
hook:
<hook classid="org.gnome.evolution.plugin.type:1.0">
<plugin-type get-type="get_type_function"/>
</hook>
Where the get-type parameter is the name of the function which returns
the GType of the plugin that you would normally register.
You should be able to actually add a plugin type in this way and any
hooks that use it, in the same plugin; although i can't really see a
reason you'd want to do that :)
I've yet to update the docs to reflect this stuff.
On Mon, 2005-05-23 at 10:37 +0200, Alessandro Decina wrote:
> On lun, 2005-05-23 at 09:33 +0530, Not Zed wrote:
>
> > Nice!
> > I will try to extend eplugin so that the loaders themselves can become
> > plugins. That way this extension can just be a standalone external unit
> > without having to patch the source and add dependencies.
> Great.
> Now I am going to expose some evo internals to python (only hook
> targets at the moment). Next, I'll consider wrapping camel.
> Right now the loader uses the Python runtime system to call PyGTK so it
> only needs PyGTK header files.
>
> > If it turns out to be too much work we can just patch the source
> > anyway :)
> I think it would be much better to make it standalone so I could
> manage/build it with Python's own distutils.
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]