Kodi Community Forum

Full Version: My 30 Add-on API wishes
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
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:
PHP Code:
li ListItem(icon=foopath='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 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:
PHP Code:
return xbmcplugin.endOfDirectory(success=Truedefault_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
    ...
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:
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 
ijob in enumerate(jobs):
    
percent 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'
Example cache read/write:
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>
Example vfs providing 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'
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:
PHP Code:
def onAction(selfaction):
    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
4.3
Will be working on that after my holiday to try and split up the stats into repo version and also for each version release. That way know how much time each version was installed from which repo.

2.3
Something like this?
http://img820.imageshack.us/img820/9688/...t034yn.png
http://img823.imageshack.us/img823/9739/...ot035x.png
http://img96.imageshack.us/img96/1943/sc...t036lt.png
Code:
https://github.com/XBMC-Addons/script.ar.../viewer.py

7.1
Already scrapped to stickies that were outdated two weeks ago. Alos been doing massive wiki reorganizing to make it more structured.
In the end I only want one sticky with most import info and pointing to the wiki starting pages and from there you need to be able to find it easy.

Overall good suggestion and some of them were also discussed by us Smile
2.1 and 2.2
I like this. I remember talk about allowing skinners to make the layouts for the addons to keep the look and feel.
But the other way around is probably better. It would also help with some addon views needing list and others icon.
Should be no problem to keep 2-3 views with consistent id's in all skins. It would then also be nice if addons could provide an extra view id they'd prefer, so that skinners could make a view that will only be used by that addon (instead of visible conditions based on addon path). So that they could make addon specific views for every addon if they wish (to override the use of those default views).
Though i foresee some square shadows (that should not be there) behind real icons and such. But nothing that can't be fixed i guess.
Consider adding:

2.4 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...



addition:
7.2: i would like to see all kind of xbmc versions in the wiki, meaning that the wiki pages for (example) eden won't be overwritten. a new "tab" for frodo should be added, so everyone can see the changes between these versions. it is sometimes really confusing if a wiki page was updated while using a previous version of xbmc. the information is kinda lost (ok, you can go to "view history" and see all the changes, but tbh that's not very user-friendly nor helpful).

just a wish!
(2013-02-06, 09:47)marv_el Wrote: [ -> ]addition:
7.2: i would like to see all kind of xbmc versions in the wiki, meaning that the wiki pages for (example) eden won't be overwritten. a new "tab" for frodo should be added, so everyone can see the changes between these versions. it is sometimes really confusing if a wiki page was updated while using a previous version of xbmc. the information is kinda lost (ok, you can go to "view history" and see all the changes, but tbh that's not very user-friendly nor helpful).

just a wish!

you can read the API changes pages and changelog. Between Eden and Frodo there are only some slight additions and removal of HTTP API. It's already enough work to keep pages up to date so i won't even bother keeping Eden pages. Dharma is no longer supported so it's silly to keep that info. Also on most page there's a "frodo feature" tag next to the addition.
(2013-02-05, 19:16)Martijn Wrote: [ -> ]4.3
Will be working on that after my holiday to try and split up the stats into repo version and also for each version release. That way know how much time each version was installed from which repo.
Cool, ping me if you need any coding help.
(2013-02-05, 19:16)Martijn Wrote: [ -> ]2.3
Something like this?
http://img820.imageshack.us/img820/9688/...t034yn.png
http://img823.imageshack.us/img823/9739/...ot035x.png
http://img96.imageshack.us/img96/1943/sc...t036lt.png
Code:
https://github.com/XBMC-Addons/script.ar.../viewer.py
Basically yes. But in my idea this dialog should be seperated from the changelog dialog and dedicated for add-on usage.

(2013-02-06, 02:33)bossanova808 Wrote: [ -> ]Consider adding:

2.4 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...
I added it to the list, good idea Smile
Dude. Great list! Want pretty much everything here but top of my wishlist is still 5.1 (Async listitems infolabels). Like the idea of setResolvedItem, but It should really work for images too. That's the main thing I currently need it for
Also, want to add:
5.14
Better API for adding/moving/removing from library. Currently, the api for removing (cleanlibrary builtin) is global, blocking and incredibly slow.
1.2 would be very important API feature. Seeing that most plugins delivers live streams I think that streaming API should deliver some form of PVR. There are plugins which allow epg for streams, which allow saving of streams (but only in certain plugins) and even planning of recording (pvr). It looks like doubling functionality of pvr module.
I imagine it would be possible to create pvr plugin for iptv, and in fact it's possible now (VDR have iptv plugin which probably can be shared through vnsi plugin).
Hovewer I'm afraid that there is some general problem with allowing for recording any stream (YouTube doesn't like it for example)
I would also add PiP so plugin would play his own stream on top of currently played movie.
1.3 will come once i manage to factor the airplay stuff out into an python addon.
Unfortunately I can't edit my first post - it is too big.
To prevent that, I already initially posted it in two different posts, but the forum software just appended my second post to the first one (which results in a non editable big post). Can any Moderator/Administrator can do anything against that?
argh, tried to split your post, but it only would create a new topic. All I could do is to increase the max post length to fix it Sad

edit: just increased the max length for posts, so you should be able to edit it again.
Streaming API with PiP would allow for video conferencing or displaying streams from multiple cameras
(2013-02-06, 19:43)Marx1 Wrote: [ -> ]Streaming API with PiP would allow for video conferencing or displaying streams from multiple cameras

Keep on topic. PiP is not done since we can't play more than one stream at a time.
Pages: 1 2 3 4 5 6 7 8