+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: My 30 Add-on API wishes (/showthread.php?tid=154805)
RE: My 30 Add-on API wishes - sphere - 2013-10-09
(2013-10-07, 22:54)Fice Wrote: 8.1 got merged yesterday
https://github.com/xbmc/xbmc/pull/3059
Yes I already noticed, thank you!
RE: My 30 Add-on API wishes - Roman_V_M - 2013-10-09
The ability to use skin-independent fonts in Python GUI Controls would be a good addition. I'm not sure how it can better be done, maybe via a new Font class, e.g.
PHP Code:
bold_font14 = xbmcgui.Font('c:\Windows\Fonts\arialbd.ttf', size=14)
...
label = xbmcgui.ControlLabel(100, 100, 200, 50, 'Some text', font=bold_font14)
RE: My 30 Add-on API wishes - Basje - 2013-11-16
Out of curiosity: will 1.5 ever be implemented? I would really like to be able to set the |proxy=http://username:password@servername:port/ for listitems
RE: My 30 Add-on API wishes - jmarshall - 2013-11-16
I think a patch would be accepted. By the looks of it all it would require "all" would be for you to detect Proxy in the appropriate block in CurlFile.cpp and fill in the m_http* variables.
The only tricky bit would be the proxy type by the looks. Something like the top commit here:
https://github.com/jmarshallnz/xbmc/commits/proxy_protocol_option
Feel free to test/enhance etc. Once confirmed working and suitable I'm happy to PR it.
Cheers,
Jonathan
RE: My 30 Add-on API wishes - Basje - 2013-11-16
(2013-11-16, 01:04)jmarshall Wrote: I think a patch would be accepted. By the looks of it all it would require "all" would be for you to detect Proxy in the appropriate block in CurlFile.cpp and fill in the m_http* variables.
The only tricky bit would be the proxy type by the looks. Something like the top commit here:
https://github.com/jmarshallnz/xbmc/commits/proxy_protocol_option
Feel free to test/enhance etc. Once confirmed working and suitable I'm happy to PR it.
Cheers,
Jonathan
Ok, I will see what I can do. Is there any preferred way to set the Proxy type? I was thinking of adding another parameter besides "Proxy", like "ProxyType". Does that sound OK?
EDIT: I also ran into an issue with RTMP streams. If I add |Proxy=.... to rtmp streams it will be passed on to librtmp which does not understand that parameter. I guess the code that calls librtmp should also be updated to either ignore the proxy or pass it on as a valid SOCKS proxy parameter.
RE: My 30 Add-on API wishes - jmarshall - 2013-11-17
I dunno if it's needed or not. You could always name it HttpProxy as the main setting. Note that this handles only stuff passed through CCurlFile. I dunno if that is how RTMP is handled.
RE: My 30 Add-on API wishes - Basje - 2013-11-17
(2013-11-17, 04:23)jmarshall Wrote: I dunno if it's needed or not. You could always name it HttpProxy as the main setting. Note that this handles only stuff passed through CCurlFile. I dunno if that is how RTMP is handled.
So would you suggest to name it HttpProxy and SocksProxy for URL parameters and consider the librtmp out of scope?
RE: My 30 Add-on API wishes - jmarshall - 2013-11-18
With librtmp we just throw the URL at it directly. Thus, I'd expect that the proxy stuff would be needed on the librtmp end of things - it may already support this, I don't know.
For http:// URLs, I'd only suggest specifying the proxy type if it will actually be needed. Most proxy's in use tend to be http anyway, so I don't know if you'll really need much more than this (I don't know what you're attempting to achieve - one presumes to bypass geolock and the like?)
RE: My 30 Add-on API wishes - Basje - 2013-11-18
(2013-11-18, 00:46)jmarshall Wrote: With librtmp we just throw the URL at it directly. Thus, I'd expect that the proxy stuff would be needed on the librtmp end of things - it may already support this, I don't know.
For http:// URLs, I'd only suggest specifying the proxy type if it will actually be needed. Most proxy's in use tend to be http anyway, so I don't know if you'll really need much more than this (I don't know what you're attempting to achieve - one presumes to bypass geolock and the like?)
I don't know what user will do with the proxy, I just want to enable them to set a proxy for streams. Anyways, I will ignore the librtmp for now and I will add a HttpProxy and perhaps add other types later.
RE: My 30 Add-on API wishes - zag - 2013-11-18
(2013-02-05, 18:23)sphere Wrote: 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
I've been pushing for these to be updated as documentation is the number one thing that will help people get started writing add-ons!
If anyone can write some guides I will update the wiki and stickies.
RE: My 30 Add-on API wishes - Basje - 2013-11-19
@jmarshall: does this look like anything that is usable? https://github.com/basrieter/xbmc/compare
It does seem to work.
RE: My 30 Add-on API wishes - jmarshall - 2013-11-19
The idea is sound, yes. I've made some comments, mostly regarding cosmetics, on your commits. If you'd like to clean them up (and rebase down onto master) and do a PR, I'd be happy to merge.
RE: My 30 Add-on API wishes - Basje - 2013-11-19
(2013-11-19, 01:23)jmarshall Wrote: The idea is sound, yes. I've made some comments, mostly regarding cosmetics, on your commits. If you'd like to clean them up (and rebase down onto master) and do a PR, I'd be happy to merge.
Great! I will have a look at your comments tomorrow and then do a rebase and PR.
EDIT: here is the pull request: https://github.com/xbmc/xbmc/pull/3682
RE: My 30 Add-on API wishes - queeup - 2013-12-01
@Basje
I was working on it once
https://github.com/xbmc/xbmc/pull/2003
Re: RE: My 30 Add-on API wishes - Basje - 2013-12-02
(2013-12-01, 18:17)queeup Wrote: @Basje
I was working on it once
https://github.com/xbmc/xbmc/pull/2003
Really? Let's hope pull request makes it in XBMC 13.