Thursday, January 22, 2009

Extending MediaBox: Creating a Simple Component

Note: If you're reading this article in a feed aggregator like planet.maemo.org, it might be truncated. Please click the link to the original feed to read the full article.

Get your text editor ready because this time I'm showing you the basics of plugin development for MediaBox.

Last time, I have explained the component system of MediaBox. If you haven't read this article yet, please do so as it will help you understand what's going on.
Now we're going to write a simple plugin that displays a short notification when the application has started.

As I have told you before, a plugin is a directory with some components in it. MediaBox looks for the plugin directories in its components directory. So we put a new directory in there with two empty files __init__.py and StartupNotifier.py in it:

mediabox
|
+-- components
|
+-- my_first_plugin
|
+-- __init__.py
|
+-- StartupNotifier.py

Every plugin needs the __init__.py file. This is the place where components are loaded and messages are defined. In this example, we will only load our StartupNotifier component, though.

Put the following code into __init__.py:

def get_classes():

from StartupNotifier import StartupNotifier
return [StartupNotifier]

The function get_classes is called by MediaBox to load the components. This function must return a list of the classes (not instantiated objects) of your components.

Now we are going to fill StartupNotifier.py with life. It is a simple component, so we derive StartupNotifier from the Component baseclass:

from com import Component, msgs

class StartupNotifier(Component):

def __init__(self):

Component.__init__(self)


def handle_message(self, msg, *args):

if (msg == msgs.CORE_EV_APP_STARTED):
self.call_service(msgs.NOTIFY_SVC_SHOW_INFO,
"Application Startup Complete")

That's all. This simple form of a component is called a mediator component, because it just listens for and emits messages. When a component wants to listen to the message bus, it simply overrides the method handle_message and checks for the message types it's interested in. The call_service method on the other hand sends a service call to the message bus.

When you now start MediaBox, you will be greeted by your new plugin.

Next time will be a bit more theoretical again. Then I'll talk about the different types of components and what they do in MediaBox.

3 comments:

mk said...

Hi! I am reading all your instruction with great interest. For some time already I am looking for something that would enable me to use my N800 as a remote control for a VLC running on a separate linux box. So the N800 would basically be a frontend just like your MediaBox - except that all media (music, movies, photos) would be displyed on that VLC on a separate machine. Do you think that the plugins mechanism would allow for this or I have to dig up in the source ...

mk said...

I've forgot to add that all media would be stored on that machine as well - therefore it would have to be possible to add remote locations to the list of monitored folders.

Martin Grimme said...

I think the best way would be to add UPnP control point functionality to MediaBox. However, I don't think VLC can do UPnP by itself, so some more work would be required on the remote machine.

It should also be possible to implement a storage device plugin for MediaBox to browse the content of the remote machine, and a mediaplayer backend that does send commands to the remote VLC.