Re: [Evolution-hackers] Python plugin interface?

[Not Zed <notzed ximian com>]

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.
>