2013-02-05, 18:23
A few months ago (mainly since the feature freeze of Frodo release) I started collecting my wishes regarding the actual XBMC Python Add-on API.
I know that some of these ideas would break backward-compatibility, but hey, it's nearly one year until the next release :-D
I'm open for any comments and will try to keep this thread updated with new ideas, workarounds or maybe even mark them as solved.
They aren't special priorized or ordered but my favourites are:
5.6, 4.1, 4.3, 2.1, 5.2
1 Playback-API
1.1 Expires-Header
It would be nice if XBMC would respect the "Expires"-Header on playable files (e.g. on .MP3s) using a real harddisk cache.
I guess this would require some big changes like any kind of "cache-management" (clear cache, show used cache size, set cache path, ...).
1.2 Download-and-Play
Nice would be if there would be a possibility to also save any remote stream while playing - defined in the add-on code. On music-plugins it doesn't make sense to always download a streamed MP3 on every playback.
1.3 Playable Python Pipe (planned, Memphiz)
It would be really cool to playback from any kind of "pipe" or python controlled virtual file handle. Ideally this should work for images/thumbs/icons AND playable-URLs.
Example for streams: Some Streams require any kind of modification or decryption, this could be done in a small python class which acts like a regular file handle to the xbmc internal player.
1.4 External Subtitle/Audio-Streams
It should be possible to be able to set one (or multiple) subtitle and/or audio streams before playback. At the moment you need to use a subclassed player which adds an additional subititle stream after playback has been started.
Something like:
1.5 plugin defined stream-Proxy (merged, PR)
What about the possibility to pass a plugin-defined proxy to xbmc like with the user-agent?
Example:
2 Skin related changes
2.1 always included skin graphics
It would beautify and unify the look of most plugin add-ons if skins would include (and this should be a requirement) reusable graphics (with a defined naming scheme) like:
- "NextPage.png"
- "PreviousPage.png"
- "MoreItems.png"
- "Search.png"
- ...
Then add-on devs could trust on that such graphics exist on EVERY skin and could start using them for their pagination (and search).
2.2 View-IDs
In some cases a Plugin view looks better (or even only makes sense) if the skin is forced to use a thumbnail-view (the default view in most skins is "list view").
At the moment you can do - but you need to know the view-id for the wanted "style" (thumb/list/...) for the skin the user is using.
Example, if you want to force any kind of thumbnail-like view you need to have a look to EVERY skin manually to find a matching view (and recheck on every update of the skin!) and hardcode it in the add-on code. Here is an example for the a "thumbnail"-view for some major skins:
One possible solution would be if skin authors would be able to (and pleased to do so *g*) define some "basic" view-IDs for plugin-usage by name in their addon.xml. And this defines should be accessable by plugins.
One simpler (at least I guess it is simpler...) solution would be to allow view-ids to be strings and add the convention that every skin needs to have some basic views defined.
Example:
2.3 Big Text Dialog/Window
It would be a good addition for add-on developers if every skin would include one additional xml defined dialog: A "Big Text Dialog" Something like a huge OK-Dialog. Add-ons could open that dialog modal to show a changelog or a small how-to-use-this-addon-text on their own - but with matching the look of the current in use skin.
2.4 Skin defined fonts and font sizes (thanks to bossanova808)
Some definition of standard fonts and font sizes - so that a WindowXML will at least somewhat across most skins without awful font overlaps etc. At the moment if you do a WindowXML of any complexity you basically need all the skinners to hop on board for it to be usable. If there were some standardised options:
- Very Large
- Large
- Normal
- Small
- Very Small
....always the same sized, then addons would instantly be at least usable on other skins...
3 Additional Content-Types
3.1 audio-live-stream
At the moment there is no real matching content-type for endless live Radio-Stations. If my plugin uses "music", the playable listitems will have (visible) infolabels primary meant for audio-tracks (e.g. artist/album/track-number/...). What about a new content-type with (visible) fields like "listeners, rating, votes"?
Also the behaviour of skipping a not working item and try the next one (without a script error) doesn't make sense on radio stations.
3.2 video-live-stream
Like above but for video (live) streams.
3.3 video-clip
Also no dedicated content-type for "clips". Clips have (mostly) no cast/plot/year//other-movie-related-fields, but "clip"-related ones: comments, external-playcount, rating, votes
4 Add-on Manager
4.1 Add-on Sub Categories
At the moment We have >300 Installable Add-ons, no one reads every add-on description to find e.g. a news plugin.
It would great if we would have categories like:
And Add-ons should be able to be in more than one Category!
4.2 Add-on Rating
Will this ever be implemented? If not please hide all hints to that.
4.3 Download Stats (planned, Martijn)
To find popular or maybe "fresh" add-ons it would be cool if the add-on manager would track and show some simple properties like:
4.4 Rich and translatable changelog
Like alrady meantioned here (http://forum.xbmc.org/showthread.php?tid=141594) it would be cool if the changelog file would be an rich/structured xml file - with a tagged section for each new version. This would give us the ability to highlight (or maybe even show via popup) the changes regarding an update from x to y.
5 General Add-on API/Python XBMC Modules
5.1a Async listitems infolabels
It would be nice if some listitem infolabels or properties could be fetched only when needed.
Example: cast/plot got fetched if info dialog is opened using "setResolvedItem" (similar to setResolvedUrl):
5.1b Or a general async (similar to lazyloading) workflow maybe?
5.2 Context-Menu Add-ons
See PR (https://github.com/xbmc/xbmc/pull/1654).
GREAT idea, please continue development :-)
Example use cases:
- "Search trailer for this movie" on movie database entries
- "Add to my whish list on amazon.com" on trailers
- "Add to Couchpotato" on trailers
- context related Facebook/Twitter/Google+ Post
5.3 Missing context-Menu commands
Plugins can add commands to the context menu. They can also clear all original items while adding new items. But they can't clear and add some original items back because not all are available, e.g. "Add to favourites".
5.4 Non-Modal/Background Progress-Dialog (merged, https://github.com/xbmc/xbmc/pull/2484)
Like for the Simple Downloader Add-on it would be cool if we could open a non modal/non blocking/background progress dialog like the one for PVR-EPG Sync/Database scanning.
This is espacially useful for service downloads like artwork downloader.
Example:
5.5 Return setting's value in correct python type
It would prettify some code and would simplify the api if the settings-value would be in the correct python type.
Examples. Type=number should return int-instance. Type=bool should return bool-instances. Returning python unicode would also help in some cases avoiding encoding issues.
5.6 Native persistant xbmc-database storage for Python Add-ons
Storing data persistant (between single plugin calls) makes some cool features possible (like "My Stations" in my Radio Addon or any kind of cache). But it slows down the execution because of the unnecessary overhead of opening/closing files or even databases on each call. Espacially on slow machines like RasberryPi or ATV2.
It would be nice if every add-on could load and dump python objects (maybe using cPickle?) to an by xbmc managed database.
Example read:Example cache read/write:
5.7 New Extension Point: Cron
In addition to the always running service addons a new extension point for "started every x minutes"-add-ons would be cool. IMO waiting-while-not-abortRequested is a less beautiful design.
Example addon.xml:
5.8 Python Scrapers
Are there any news on Python based Scrapers?
When they will be available it would be nice if add-ons could use them as well to get metadata.
5.9 Split VFS-providing and PLAYURL-providing Plugins
Plex has splitted up plugins to the VFS-providing and the stream-resolving ones. Stream-resolving add-ons can register regular expression for playback/website URLs. VFS Add-ons can provide a VFS and end up with a website-url. Plex then can use the playback-service plugin to receive the "real playable url". This would simplify and unify much add-ons.
Example addon.xml from resolving addon:
Example vfs providing addon:
5.10 Multiple-Thumbnails/Video Preview
What about multi-thubmnails? It would be cool if a selected item (not only within plugin vfs) would cycle through multiple thumbnails (e.g. thumbnail of minute 0, 10, 20, ...) - each shown for a second.
Maybe not only for add-on generated listitems?
5.11 General xbmc Download method
A general background working download method (For example via context-menu) for playable plugin-list-items.
Ideally this method should be able to handle all by xbmc playable protocols/streams/files (http/ftp/scp/rtmp/...)
Example:I know about the simple Downloader python add-on, but it requires external libraries/binaries (e.g. rtmpdump) which are xbmc internally already available. Also it doesn't provide the same interface like xbmc does.
5.12 infolabel format
- The duration infolabel should accept int(seconds) (see here: http://forum.xbmc.org/showthread.php?tid=146794).
- rating should be float 0-1. This would unify video and music rating (video is 0-10, music 0-5)
- date could be UTC timestamp to automatically match the local timezone
If interested I could bring up more.
5.13 Show Python Error/Traceback as dialog
What about showing the Python Error message in a dialog (when xbmc debug is enabled)?
6 Translations
6.1 Automatic transifex translations update
What about having automatically generated "translation addons", this would reduce the overhead for add-on developers and also shorten the time a new translation will be available for the users.
Idea 1: "plugin.audio.radio" could automatically require "plugin.audio.radio.en_US" which is auto generated and updated.
Idea 2: like above but the translation is automatically fetched/updated from transifex without the "virtual" language add-on.
7 Forum/Wiki/Developer-docs
7.1 I know this is work no one wants to do (including me), but there are dozen of sticky-threads/linked-manuals which are extremly outdated. Or really bad (Python) Code.
As a first step: Please unstick (and maybe close?) threads with outdated informations. Examples: the last three sticky threads in python add-on development
8 Script Development
8.1 actions by name in onAction()/constants for action IDs (merged, https://github.com/xbmc/xbmc/pull/3059)
In the WindowXML().onAction(action)-method you need to compare the passed action object (or the id you get via action.getId()) to a list of (more or less) "mysterios" integers. Why not expose the action IDs by constants?
Example:
Comments are welcome!
But please, if you want to comment one or more wishes, don't forget to tell the number.
Thanks for reading, regards,
sphere
I know that some of these ideas would break backward-compatibility, but hey, it's nearly one year until the next release :-D
I'm open for any comments and will try to keep this thread updated with new ideas, workarounds or maybe even mark them as solved.
They aren't special priorized or ordered but my favourites are:
5.6, 4.1, 4.3, 2.1, 5.2
1 Playback-API
1.1 Expires-Header
It would be nice if XBMC would respect the "Expires"-Header on playable files (e.g. on .MP3s) using a real harddisk cache.
I guess this would require some big changes like any kind of "cache-management" (clear cache, show used cache size, set cache path, ...).
1.2 Download-and-Play
Nice would be if there would be a possibility to also save any remote stream while playing - defined in the add-on code. On music-plugins it doesn't make sense to always download a streamed MP3 on every playback.
1.3 Playable Python Pipe (planned, Memphiz)
It would be really cool to playback from any kind of "pipe" or python controlled virtual file handle. Ideally this should work for images/thumbs/icons AND playable-URLs.
Example for streams: Some Streams require any kind of modification or decryption, this could be done in a small python class which acts like a regular file handle to the xbmc internal player.
1.4 External Subtitle/Audio-Streams
It should be possible to be able to set one (or multiple) subtitle and/or audio streams before playback. At the moment you need to use a subclassed player which adds an additional subititle stream after playback has been started.
Something like:
PHP Code:
li = ListItem(icon=foo, path='http://server.com/video.flv')
li.addProperty(['subtitle-file', 'http://server.com/video_subtitle.srt'])
li.addProperty(['audio-file', 'http://server.com/video_audiotrack.mp2'])
1.5 plugin defined stream-Proxy (merged, PR)
What about the possibility to pass a plugin-defined proxy to xbmc like with the user-agent?
Example:
PHP Code:
li = ListItem(path="http://foo.com/video.flv?foo=bar|proxy=http://user:[email protected]")
return xbmcplugin.setResolvedUrl(li)
2 Skin related changes
2.1 always included skin graphics
It would beautify and unify the look of most plugin add-ons if skins would include (and this should be a requirement) reusable graphics (with a defined naming scheme) like:
- "NextPage.png"
- "PreviousPage.png"
- "MoreItems.png"
- "Search.png"
- ...
Then add-on devs could trust on that such graphics exist on EVERY skin and could start using them for their pagination (and search).
2.2 View-IDs
In some cases a Plugin view looks better (or even only makes sense) if the skin is forced to use a thumbnail-view (the default view in most skins is "list view").
At the moment you can do - but you need to know the view-id for the wanted "style" (thumb/list/...) for the skin the user is using.
Example, if you want to force any kind of thumbnail-like view you need to have a look to EVERY skin manually to find a matching view (and recheck on every update of the skin!) and hardcode it in the add-on code. Here is an example for the a "thumbnail"-view for some major skins:
Code:
'thumbnail': {
'skin.confluence': 500,
'skin.aeon.nox': 551,
'skin.confluence-vertical': 500,
'skin.jx720': 52,
'skin.pm3-hd': 53,
'skin.rapier': 50,
'skin.simplicity': 500,
'skin.slik': 53,
'skin.touched': 500,
'skin.transparency': 53,
'skin.xeebo': 55,
},
One simpler (at least I guess it is simpler...) solution would be to allow view-ids to be strings and add the convention that every skin needs to have some basic views defined.
Example:
PHP Code:
return xbmcplugin.endOfDirectory(success=True, default_view='thumbnail')
2.3 Big Text Dialog/Window
It would be a good addition for add-on developers if every skin would include one additional xml defined dialog: A "Big Text Dialog" Something like a huge OK-Dialog. Add-ons could open that dialog modal to show a changelog or a small how-to-use-this-addon-text on their own - but with matching the look of the current in use skin.
2.4 Skin defined fonts and font sizes (thanks to bossanova808)
Some definition of standard fonts and font sizes - so that a WindowXML will at least somewhat across most skins without awful font overlaps etc. At the moment if you do a WindowXML of any complexity you basically need all the skinners to hop on board for it to be usable. If there were some standardised options:
- Very Large
- Large
- Normal
- Small
- Very Small
....always the same sized, then addons would instantly be at least usable on other skins...
3 Additional Content-Types
3.1 audio-live-stream
At the moment there is no real matching content-type for endless live Radio-Stations. If my plugin uses "music", the playable listitems will have (visible) infolabels primary meant for audio-tracks (e.g. artist/album/track-number/...). What about a new content-type with (visible) fields like "listeners, rating, votes"?
Also the behaviour of skipping a not working item and try the next one (without a script error) doesn't make sense on radio stations.
3.2 video-live-stream
Like above but for video (live) streams.
3.3 video-clip
Also no dedicated content-type for "clips". Clips have (mostly) no cast/plot/year//other-movie-related-fields, but "clip"-related ones: comments, external-playcount, rating, votes
4 Add-on Manager
4.1 Add-on Sub Categories
At the moment We have >300 Installable Add-ons, no one reads every add-on description to find e.g. a news plugin.
It would great if we would have categories like:
Code:
Video
News
Trailers
Movies
Clips
Live Channels
Gaming
Hardware
...
Audio
Radio Stations
Songs
Podcasts
Comedy
...
4.2 Add-on Rating
Will this ever be implemented? If not please hide all hints to that.
4.3 Download Stats (planned, Martijn)
To find popular or maybe "fresh" add-ons it would be cool if the add-on manager would track and show some simple properties like:
Code:
Downloads: 200/5.213 (Last week/Total), last Updated on: (01.12.2013), Rating: (4,6; 3453 votes)
4.4 Rich and translatable changelog
Like alrady meantioned here (http://forum.xbmc.org/showthread.php?tid=141594) it would be cool if the changelog file would be an rich/structured xml file - with a tagged section for each new version. This would give us the ability to highlight (or maybe even show via popup) the changes regarding an update from x to y.
5 General Add-on API/Python XBMC Modules
5.1a Async listitems infolabels
It would be nice if some listitem infolabels or properties could be fetched only when needed.
Example: cast/plot got fetched if info dialog is opened using "setResolvedItem" (similar to setResolvedUrl):
PHP Code:
def onInfoDialogOpend(item_id):
li = ListItem(info={'plot': 'Lorem Ipsum'}
return xbmcplugin.setResolvedItem(li)
5.1b Or a general async (similar to lazyloading) workflow maybe?
5.2 Context-Menu Add-ons
See PR (https://github.com/xbmc/xbmc/pull/1654).
GREAT idea, please continue development :-)
Example use cases:
- "Search trailer for this movie" on movie database entries
- "Add to my whish list on amazon.com" on trailers
- "Add to Couchpotato" on trailers
- context related Facebook/Twitter/Google+ Post
5.3 Missing context-Menu commands
Plugins can add commands to the context menu. They can also clear all original items while adding new items. But they can't clear and add some original items back because not all are available, e.g. "Add to favourites".
5.4 Non-Modal/Background Progress-Dialog (merged, https://github.com/xbmc/xbmc/pull/2484)
Like for the Simple Downloader Add-on it would be cool if we could open a non modal/non blocking/background progress dialog like the one for PVR-EPG Sync/Database scanning.
This is espacially useful for service downloads like artwork downloader.
Example:
PHP Code:
pd = xbmcgui.BackgroundProgressDialog()
for i, job in enumerate(jobs):
percent = i / len(jobs) * 100
pd.update(percent)
job()
pd.close()
5.5 Return setting's value in correct python type
It would prettify some code and would simplify the api if the settings-value would be in the correct python type.
Examples. Type=number should return int-instance. Type=bool should return bool-instances. Returning python unicode would also help in some cases avoiding encoding issues.
5.6 Native persistant xbmc-database storage for Python Add-ons
Storing data persistant (between single plugin calls) makes some cool features possible (like "My Stations" in my Radio Addon or any kind of cache). But it slows down the execution because of the unnecessary overhead of opening/closing files or even databases on each call. Espacially on slow machines like RasberryPi or ATV2.
It would be nice if every add-on could load and dump python objects (maybe using cPickle?) to an by xbmc managed database.
Example read:
PHP Code:
import xbmcaddon
addon_obj = xbmcaddon.Addon(id='my.cool.addon')
my_storage = addon_obj.getAddonStorage('foo')
foo_data = my_storage['foo_data']
PHP Code:
import xbmcaddon
addon_obj = xbmcaddon.Addon(id='my.cool.addon')
my_storage = addon_obj.getAddonStorage('foo', TTL=3600)
if 'foo_data' in my_storage:
# we have data in cache
pass
else:
my_storage['foo_data'] = 'data which gets outdated after one hour'
my_storage.sync()
5.7 New Extension Point: Cron
In addition to the always running service addons a new extension point for "started every x minutes"-add-ons would be cool. IMO waiting-while-not-abortRequested is a less beautiful design.
Example addon.xml:
Code:
<addon id="my.cool.addon">
<extension point="xbmc.python.cron" library="script.py">
<run>*/5 * * * *</run>
</extension>
</addon>
5.8 Python Scrapers
Are there any news on Python based Scrapers?
When they will be available it would be nice if add-ons could use them as well to get metadata.
5.9 Split VFS-providing and PLAYURL-providing Plugins
Plex has splitted up plugins to the VFS-providing and the stream-resolving ones. Stream-resolving add-ons can register regular expression for playback/website URLs. VFS Add-ons can provide a VFS and end up with a website-url. Plex then can use the playback-service plugin to receive the "real playable url". This would simplify and unify much add-ons.
Example addon.xml from resolving addon:
Code:
<addon id="my.cool.addon">
<extension point="xbmc.python.stream_resolver" library="resolver.py">
<regex>http://www.youtube.com\?v=.*</regex>
</extension>
</addon>
PHP Code:
li = ListItem(path="http://www.youtube.com?v=12345")
xbmcplugin.setResolvedUrl(li)
5.10 Multiple-Thumbnails/Video Preview
What about multi-thubmnails? It would be cool if a selected item (not only within plugin vfs) would cycle through multiple thumbnails (e.g. thumbnail of minute 0, 10, 20, ...) - each shown for a second.
Maybe not only for add-on generated listitems?
5.11 General xbmc Download method
A general background working download method (For example via context-menu) for playable plugin-list-items.
Ideally this method should be able to handle all by xbmc playable protocols/streams/files (http/ftp/scp/rtmp/...)
Example:
PHP Code:
downloader = xbmcvfs.Downloader()
downloader.download('rtmp://foo.bar playpath=baz, swfUrl=asd')
downloader.download('ftp://my.server.com/beach_2012.avi')
5.12 infolabel format
- The duration infolabel should accept int(seconds) (see here: http://forum.xbmc.org/showthread.php?tid=146794).
- rating should be float 0-1. This would unify video and music rating (video is 0-10, music 0-5)
- date could be UTC timestamp to automatically match the local timezone
If interested I could bring up more.
5.13 Show Python Error/Traceback as dialog
What about showing the Python Error message in a dialog (when xbmc debug is enabled)?
6 Translations
6.1 Automatic transifex translations update
What about having automatically generated "translation addons", this would reduce the overhead for add-on developers and also shorten the time a new translation will be available for the users.
Idea 1: "plugin.audio.radio" could automatically require "plugin.audio.radio.en_US" which is auto generated and updated.
Idea 2: like above but the translation is automatically fetched/updated from transifex without the "virtual" language add-on.
7 Forum/Wiki/Developer-docs
7.1 I know this is work no one wants to do (including me), but there are dozen of sticky-threads/linked-manuals which are extremly outdated. Or really bad (Python) Code.
As a first step: Please unstick (and maybe close?) threads with outdated informations. Examples: the last three sticky threads in python add-on development
8 Script Development
8.1 actions by name in onAction()/constants for action IDs (merged, https://github.com/xbmc/xbmc/pull/3059)
In the WindowXML().onAction(action)-method you need to compare the passed action object (or the id you get via action.getId()) to a list of (more or less) "mysterios" integers. Why not expose the action IDs by constants?
Example:
PHP Code:
def onAction(self, action):
if action == xbmcgui.KEY_INFO:
pass;
elif action == xbmcgui.KEY_EXIT_ALL:
self.close()
Comments are welcome!
But please, if you want to comment one or more wishes, don't forget to tell the number.
Thanks for reading, regards,
sphere