2010-09-20, 10:06
During a recent effort to document addon development for XBMC and coming at it from the point of view of a complete beginner to the subject, I struggled with what exactly constitutes an addon, a plugin, a script etc. Granted, this is in no small part due to reading some existing documentation aimed at pre Dharma XBMC. So I thought I'd post this and see what others think about the subject. I stress, this is my own point of view.
From my research, XBMC is now classing all userland supplied (and a lot of in-built functionality,) as an "addon" and have provided new functionality to manage installing, updating and managing addons from within XBMC itself, a great step forward that will simplify distribution and therefore give greater incentive to addon developers. But this leads to some problems;
Addons can be classified into 4 groups;
The repository and skin addon types are fairly well self contained. It's in the plugin and script types that I believe some confusion exists. There are a couple of issues;
Symantics
According to existing documentation, a plugin is supposed to add to the functionality of the existing XBMC system. Its principle purpose is to add additional content to the system and achieve this by integrating into the UI that XBMC defines for content retrieval, i.e. the directory and file listing. This is well supported by the XBMC Python API and the basic construction of a plugin is relatively straightforward. The API also provides a mechanism whereby a developer can tell the system under which section of the main menu the plugin should appear as an addon in the extension point <provides> tag of the addons.xml definition file, (i.e audio, video, image or executable, which correspond to the Music, Video, Pictures and Program menu items.) Similarly a 'script' is well supported by the API and is expected to run in its own window, effectively outside the control of XBMC.)
Here is the first problem, we have a duplication in defining a script. A program script can be defined in two ways;
The second problem I have found is that there is nothing to stop a developer breaking the convention of providing content with their plugin that breaks the establish UI guidelines. The Grooveshark addon does just that. It does not provide content in a directory listing as I believe is intended, but runs as a program and takes over the XBMC console. You cannot for instance display a picture slide show at the same time as using Grooveshark. Please note I have nothing against Grooveshark as a program, it is a great bit of software and I use regularly myself, I am simply using it to exemplify a problem. The core of the issue is that it acts in a non conformist manner and breaks the XBMC UI convention. As Apple are very quick to tell us when someone tries to break UI in a phone app, don't do it - it confuses the user.
Missing definition
The current definition of a plugin is I think, inappropriate. It actually describes a 'Content Provider'. in that the software package adds content to XBMC. What is missing (unless I have completely missed it somewhere,) is a true plugin or "Extension", that adds functionality to XBMC. An Extension would allow developers to extend the context menu by hooking in new functionality. For example, how about the ability to rotate an incorrectly aligned image whilst browsing your pictures or even an editor option that calls up GIMP (or some other user definable editor,). An extension could provide this by adding a new option to the context menu. A second type of 'extension' could be used to hook into playback operation by perhaps adding support for media file types that aren't supported in the standard XBMC build. there may be others.
I have my own thoughts on how these issues could be addressed, but I was really just wondering if Addon devs perceived the same issues.
From my research, XBMC is now classing all userland supplied (and a lot of in-built functionality,) as an "addon" and have provided new functionality to manage installing, updating and managing addons from within XBMC itself, a great step forward that will simplify distribution and therefore give greater incentive to addon developers. But this leads to some problems;
Addons can be classified into 4 groups;
- repository - adds alternative addon repositories to the addon manager
- plugin - adds to the functionality of XBMC. Plugins appear under the relevant media section of the main home menu.
- script - a runnable, standalone, program that will appear in the XBMC program section and can take over the console, e.g. Rss editor
- skin - a skin definition and its supporting script files
The repository and skin addon types are fairly well self contained. It's in the plugin and script types that I believe some confusion exists. There are a couple of issues;
- Symantics - There is an uncontrolled blurring of what a plugin type actually means
- Missing definition - an additional type is required
Symantics
According to existing documentation, a plugin is supposed to add to the functionality of the existing XBMC system. Its principle purpose is to add additional content to the system and achieve this by integrating into the UI that XBMC defines for content retrieval, i.e. the directory and file listing. This is well supported by the XBMC Python API and the basic construction of a plugin is relatively straightforward. The API also provides a mechanism whereby a developer can tell the system under which section of the main menu the plugin should appear as an addon in the extension point <provides> tag of the addons.xml definition file, (i.e audio, video, image or executable, which correspond to the Music, Video, Pictures and Program menu items.) Similarly a 'script' is well supported by the API and is expected to run in its own window, effectively outside the control of XBMC.)
Here is the first problem, we have a duplication in defining a script. A program script can be defined in two ways;
- As a script, with an extension type of xbmc.python.script
- As a plugin, as an extension type xbmc.python.pluginsource that provides an executable
The second problem I have found is that there is nothing to stop a developer breaking the convention of providing content with their plugin that breaks the establish UI guidelines. The Grooveshark addon does just that. It does not provide content in a directory listing as I believe is intended, but runs as a program and takes over the XBMC console. You cannot for instance display a picture slide show at the same time as using Grooveshark. Please note I have nothing against Grooveshark as a program, it is a great bit of software and I use regularly myself, I am simply using it to exemplify a problem. The core of the issue is that it acts in a non conformist manner and breaks the XBMC UI convention. As Apple are very quick to tell us when someone tries to break UI in a phone app, don't do it - it confuses the user.
Missing definition
The current definition of a plugin is I think, inappropriate. It actually describes a 'Content Provider'. in that the software package adds content to XBMC. What is missing (unless I have completely missed it somewhere,) is a true plugin or "Extension", that adds functionality to XBMC. An Extension would allow developers to extend the context menu by hooking in new functionality. For example, how about the ability to rotate an incorrectly aligned image whilst browsing your pictures or even an editor option that calls up GIMP (or some other user definable editor,). An extension could provide this by adding a new option to the context menu. A second type of 'extension' could be used to hook into playback operation by perhaps adding support for media file types that aren't supported in the standard XBMC build. there may be others.
I have my own thoughts on how these issues could be addressed, but I was really just wondering if Addon devs perceived the same issues.
