OPluginManager
NicolasTrangez: On this page and subsections I'd like to dump some ideas on OPluginManager's goals and architecture. This is very work-in-progress. Please comment on it if you want features/dislike current solutions/... I really need input 
What is it
OPluginManager is a library in the Onion namespace to allow developers to add plugin functionality to their programs easily, and provide a consistent plugin management interface to user.
Current situation
Every project using plugins got its own code to load these, has its own User Interface to allow the user to enable/disable plugins, etc. This involves a lot of code duplication, and lacks a common user interface. For plugin developers it can also be hard to learn all different ways different projects want plugins to be written (ie what functions to export etc). Next to this, most projects only support C plugins.
What OPluginManager should bring
Simply put, these are the goals:
- Have one common way for developers to load all valid plugins from a directory/directories, get some data out of them, and use them.
- Provide one simple way to write plugins.
- Allow writing plugins in (at least) Python and C#. Other languages would be nice too, but I don't know eg Perl very well. I am not sure this goal is possible to achieve though.
- Writing plugins in Python should be possible. I played a little with Python/C calling (thanks to the Epiphany guys for providing some sample code), and this could even fit in the current plugin design.
Python plugin support is in CVS now, more information here.
- CLI PInvoke is very flexible, so this should not bring too much trouble either.
- Writing plugins in Python should be possible. I played a little with Python/C calling (thanks to the Epiphany guys for providing some sample code), and this could even fit in the current plugin design.
- Have one common user interface for enabling/disabling plugins.
What this is not
I had a little discussion on this with some people in #gnome-hackers yesterday. It looks like I should explicitly say this is not an attempt to unify all possible plugin systems, as obviously all plugin based apps got other requirements (think "vtables"). This is only a unified plugin loader infrastructure.
What it is based on
As most Gnome projects, this one will be mostly based on glib, and on GTK for the UI part. Plugins will essentially be based on gmodules.
Implementation details
I'll try to draw a diagram on this ASAP (exams now so it'll take a while). All possible plugins should have the same structure (the OPluginManager part, not the internal data, of course), whether they're written in C, Python or some other language. After playing around with Python/C interop, this should be possible, nearly trivial.
Modules should export a function (with a fixed name and prototype) which returns a structure with some common fields. These are the fields I got now.
Here's a sample plugin implementation.
This is a sample Python plugin.
Current work
You can find current code in Gnome CVS (help, how to wikify a CVS directory?), including some test cases as samples (Take a look in the tests directory to get a pretty decent overview of how things fir together). It should be working quite well, currently adding new functionality.
This is what's working now (could become outdated):
- Loading and using native (C) plugins
- Loading and using Python plugins (not 100% done)
What should be done:
- PluginManagerUI, so the user can enable/disable plugins
- Store which plugins are enabled/disabled, and be able to load only enabled plugins.
- Anyone got an idea on what's the best way to store this? Should OPluginManager store it itself, or should it create a string (XML document), and give that to the client app so it can store it the way it wants to? I think that's the best option as projects like Gaim could benefit from OPluginManager, but are not using GConf.