Preparing MAFW to be used

Out-of-process
In-process

Initialization

As the framework is GObject-based, first of all you need to init GType.

g_type_init ();

Out-of-process

As we already pointed out, with the out-of-process approach plugins are loaded by the mafw-dbus-wrapper and they are shared by all applications using the wrapper, so first of all we have to initialize the connection with mafw-dbus-wrapper:

/* Register plugins */
registry = MAFW_REGISTRY(mafw_registry_get_instance());
if (registry == NULL) {
        /* Error management here */
}

mafw_shared_init(registry, &error);
if (error != NULL) {
        /* Error management here */
} 

g_signal_connect(registry,
		 "renderer-added", G_CALLBACK(renderer_added_cb), NULL);

g_signal_connect(registry,
		 "renderer-removed", G_CALLBACK(renderer_removed_cb), NULL);

g_signal_connect(registry,
		 "source-added", G_CALLBACK(source_added_cb), NULL);

g_signal_connect(registry,
		 "source-removed", G_CALLBACK(source_removed_cb), NULL);

As one can see, we first get a reference to the MafwRegistry object, which is a singleton. The MafwRegistry object provides an interface for application developers to access the available extensions (sources and renderers). In the case of out-of-process extensions, the registry will provide proxies to the actual remote extensions that handle the DBUS communications transparently for the application developer.

The next step is to initiate the extension discovering with mafw_shared_init. After that we can connect to signals emitted on the registry object to be notified on the addition and removal of individual renderers and sources available.

We should also consider the possibility of plugins being loaded in the registry before our application was started. We can access the list of already available renderers and sources doing something like this:

extension_list = mafw_registry_get_renderers(registry);
while (extension_list)
{
	renderer_added_cb(registry, G_OBJECT(extension_list->data), NULL);
	extension_list = g_list_next(extension_list);
}

extension_list = mafw_registry_get_sources(registry);
while (extension_list)
{
	source_added_cb(registry, G_OBJECT(extension_list->data), NULL);
	extension_list = g_list_next(extension_list);
}

Notice that these lists of already available extensions should not be freed.

The source added and renderer added callbacks look like this:

static void 
source_added_cb(MafwRegistry * registry, GObject *source, gpointer user_data)
{
	/* Get a reference to the available source */
	if (MAFW_IS_SOURCE(source)) {
                /* Code to manage new sources here */
	}
}

static void 
renderer_added_cb(MafwRegistry * registry, GObject *renderer, gpointer user_data)
{
	/* Get a reference to the available renderer */
	if (MAFW_IS_RENDERER(renderer)) {
                /* Code to manage new renderers here */
	}
}

In-process

Contrary to the out-of-process approach, in-process plugins are loaded in the same address space of the application process. As always, the first step is to get a reference to the MafwRegistry instance.

/* Register plugins */
registry = MAFW_REGISTRY(mafw_registry_get_instance());
if (registry == NULL) {
        /* Error management here */
}

Loading plugins

Loading all available plugins

After initializing the registry, just run:

mafw_registry_load_plugins(registry);

Loading plugins manually

You can load a plugin manually like this:

mafw_registry_load_plugin(MAFW_REGISTRY(registry),
                           "mafw-plugin.so", &error);
if (error != NULL) {
        /* Error management here */
}

The second parameter of mafw_registry_load_plugin can be just a filename (in this case the default plugin directory will be used) or a absolute path of a plugin file.

Being aware of loaded plugins

It can be done in the same way as for the out-of-process approach because plugins are used in the same way in both cases. Switching from in-process to out-of-process should not be a difficult task and something to take into account is that in case of loading the same plugin in both in-process and out-of-process versions, the in-process will be used. The same code as for out-of-process plugins can be used.

Querying after loading

This means loading the plugins in the registry first and then querying it for the lists of available renderers and sources, like this:

mafw_registry_load_plugins(registry);

extension_list = mafw_registry_get_renderers(registry);
while (extension_list)
{
	renderer_added_cb(registry, G_OBJECT(extension_list->data), NULL);
	extension_list = g_list_next(extension_list);
}

extension_list = mafw_registry_get_sources(registry);
while (extension_list)
{
	source_added_cb(registry, G_OBJECT(extension_list->data), NULL);
	extension_list = g_list_next(extension_list);
}

Using signals and callbacks

This approach is more asynchronous and it is recommended because it can easily handle sources or renderers added after the application initialization. It is done by connecting callbacks to the source added and renderer added signals. As soon as a plugin is loaded, a signal is emitted and the application can react to it, preparing everything to use that source or renderer, like this:

registry = MAFW_REGISTRY(mafw_registry_get_instance());
if (registry == NULL) {
        /* Error handling here */
}

g_signal_connect(registry,
		 "renderer_added", G_CALLBACK(renderer_added_cb), NULL);

g_signal_connect(registry,
		 "source_added", G_CALLBACK(source_added_cb), NULL);

g_signal_connect(registry,
		 "renderer_removed", G_CALLBACK(renderer_removed_cb), NULL);

g_signal_connect(registry,
		 "source_removed", G_CALLBACK(source_removed_cb), NULL);

mafw_registry_load_plugins(registry);

One can see we also defined callbacks to handle the removal of renderers and sources from the registry.