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. > _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
