All Blogs

I tried to stabilize the OPluginManager interface today, after a terrible exam. Look at the OPluginManager page at live.gnome.org to get a view of the current structure.

I updated the test cases I got here locally (one example is the plugin code I got on that wiki page too). The directory-loader is finished too, almost everything is in place now actually, except the UI part and the "only-load-enabled-modules" feature. These things should be fairly trivial (don't we love that word, NVDB?) to implement.

Here's a sample app:

#include <glib.h>

#include "o-plugin-manager.h"
#include "o-plugin-manager-plugin.h"

gint main(guint argc, gchar *argv[]) {
        gint cnt = 0;
        gchar *dir = NULL, *dir2 = NULL, *modulepath = NULL;
        const OPluginManagerPlugin *plugin = NULL;
        OPluginManager *manager = NULL;

        g_type_init();

        manager = O_PLUGIN_MANAGER(o_plugin_manager_new());
        o_plugin_manager_load_modules(manager, ".libs", "test-init-data", NULL);        

        g_print("\n\nFound %d modules\n", o_plugin_manager_get_num_modules(manager));

        /* Check whether we got a 0'st module, call its configure function */
        if(o_plugin_manager_get_num_modules(manager) > 0) {
                plugin = o_plugin_manager_get_module(manager, 0);
                g_debug("Dumping module 0:\n");
                o_plugin_manager_plugin_dump(plugin);
        }

        g_object_unref(manager);

        return 0;
}

As you can see, this code loads all valid modules in .libs with the string "test-init-data" as init data, then checks whether a 0st plugin is available, and dumps the plugin info.

This is the current output:

** (process:14246): DEBUG: Loading all modules in .libs, suffix is so
** (process:14246): DEBUG: Suffix for .libs/libtestplugin.so is so, loading module
** (process:14246): DEBUG: [OPluginManagerPlugin] [test-plugin] Got an init function
** (process:14246): DEBUG: [test-plugin] Init with data "test-init-data"
** (process:14246): DEBUG: Module .libs/libtestplugin.so is valid, adding


Found 1 modules
** (process:14246): DEBUG: Dumping module 0:


================================================
Dumping data for: .libs/libtestplugin.so
=================
* Name: test-plugin
* Summary: A simple test plugin
* Description: This is a sample test plugin, to test the OPluginManager functionality
* Version: 0.1
* URI: http://www.eikke.com
* Authors:
        ikke
        -----------
                Email: eikke eikke com
                URI: http://www.eikke.com
        John Doe
        -----------
                Email: foo@bar.com
                URI: http://www.foobar.foo
* Module got an init function
* Module got a data free function
* Module got a configure function
================================================

** (process:14246): DEBUG: Deleting 1 modules
** (process:14246): DEBUG: [OPluginManagerPlugin] Freeing "test-plugin" data
** (process:14246): DEBUG: [OPluginManagerPlugin] Running free function
** (process:14246): DEBUG: [test-plugin] Freeing data "Test plugin data"

Here libtestplugin.so is the plugin you can see in the live.gnome wiki.

I also tried to implement a plugin structure in Python, although I'm no Python-expert at all. Current code is available here.
To give a little overview: every Python-based plugin should be a class extending from OPluginManagerPlugin, in this sample PluginTest is an implementation. There should be one fixed-name function in the __main__ module that returns an instance of this plugin class. Like this we just have to call that fixed-name function in our C wrapper, get it's return value in a PyObject *, then check whether it's type descends from OPluginManagerPlugin, and if that's the case start using the object as if it's just an OPluginManagerPlugin, we don't have to care about the details.
The code needs lots of enhancements and cleanups. If you could elaborate on this, please contact me. Especially the function-pointer part (passing (int)0 if no function is given) is ugly: I need to be able to check whether the var is a real function pointer before I call it, not only checking whether it's != 0. Next to this, I should figure out how to do proper error handling. Once that's done, I should be able to write a small wrapper plugin in C so I can start using plugins written in Python from within C.