2015-12-03, 13:24
i assume the idea with this layering of the API is to be able to have outdated addons work but with limited functionality ?
2015-12-03, 16:40
While you are in binary addons area, you can nuke the wrapping for osx/ios. Legacy stuff that is no longer needed.
Also, nuke the versioning and symlink creations and treat it just like android that is, libXXXX.dylib. More legacy bits.
Also, nuke the versioning and symlink creations and treat it just like android that is, libXXXX.dylib. More legacy bits.
2015-12-03, 22:59
Hi @ironic_monkey, yeah that's one of my main goal in mind. Will have the opportunity to extend this without the right all the add-ons have to be changed.
Using a Web browser a lot more is needed because the languages are to be used for Kodi. Furthermore, I want the opportunity to expand Add-ons in C ++ format to bring and eventually into the base "C" system has the chance to improve even integrate other languages.
Hi @MrMC, this with different Folder names and namespaces was on begin the most secure way for me to have them independent and related header text as small as possible. But thanks, I'll look at me when it's good to take it can be changed.
Also is in newest version no library needed anymore, the add-on access Kodi direct.
Has also done the first step of documentation for, visible here: https://github.com/AlwinEsch/kodi/tree/b...addon.api2
Using a Web browser a lot more is needed because the languages are to be used for Kodi. Furthermore, I want the opportunity to expand Add-ons in C ++ format to bring and eventually into the base "C" system has the chance to improve even integrate other languages.
Hi @MrMC, this with different Folder names and namespaces was on begin the most secure way for me to have them independent and related header text as small as possible. But thanks, I'll look at me when it's good to take it can be changed.
Also is in newest version no library needed anymore, the add-on access Kodi direct.
Has also done the first step of documentation for, visible here: https://github.com/AlwinEsch/kodi/tree/b...addon.api2
2015-12-06, 05:23
Has updated my commits and reduced to one (now two 
)
https://github.com/AlwinEsch/kodi/tree/b...b-rework-2
With the current changes for level two are only the following old headers on "./xbmc/xbmc/addons/include" needed:
- kodi_adsp_dll.h
- kodi_adsp_types.h
- kodi_audiodec_dll.h
- kodi_audiodec_types.h
- xbmc_addon_cpp_dll.h
- xbmc_addon_dll.h
- xbmc_addon_types.h
- xbmc_audioenc_dll.h
- xbmc_audioenc_types.h
- xbmc_pvr_dll.h
- xbmc_pvr_types.h
- xbmc_scr_dll.h
- xbmc_scr_types.h
- xbmc_vis_dll.h
- xbmc_vis_types.h
The new library headers are included also with the folder to this and no more on "./xbmc/lib/addons/
The last old headers are only for the work from Kodi to the add-on. The best way for me, to change them for API level type is after the new library comes in and the old becomes away to prevent conflicts.
Has updated also my commit to pvr.vdr.vnsi addon with this library rework, see https://github.com/AlwinEsch/pvr.vdr.vns...644ed97328
)https://github.com/AlwinEsch/kodi/tree/b...b-rework-2
With the current changes for level two are only the following old headers on "./xbmc/xbmc/addons/include" needed:
- kodi_adsp_dll.h
- kodi_adsp_types.h
- kodi_audiodec_dll.h
- kodi_audiodec_types.h
- xbmc_addon_cpp_dll.h
- xbmc_addon_dll.h
- xbmc_addon_types.h
- xbmc_audioenc_dll.h
- xbmc_audioenc_types.h
- xbmc_pvr_dll.h
- xbmc_pvr_types.h
- xbmc_scr_dll.h
- xbmc_scr_types.h
- xbmc_vis_dll.h
- xbmc_vis_types.h
The new library headers are included also with the folder to this and no more on "./xbmc/lib/addons/
The last old headers are only for the work from Kodi to the add-on. The best way for me, to change them for API level type is after the new library comes in and the old becomes away to prevent conflicts.
Has updated also my commit to pvr.vdr.vnsi addon with this library rework, see https://github.com/AlwinEsch/pvr.vdr.vns...644ed97328
2015-12-08, 06:34
Has worked a bit on the documentation for the binary add-ons.
Still not finished but visible to see what comes.
https://github.com/AlwinEsch/kodi/blob/b.../Readme.md
Not want to use the normal wiki from Kodi, I think there is more easy do change together with the related code and also is on code view the needed documentation always present.
The only point where I'm not sure is how the docs folder becomes handled.
- one way is to leave there
. - good = together with code
. - bad = a lot of commit messages to change
- and the other is to pass on github repository wiki.
. - good = prevent not needed commit messages
. - bad = That will forget an update again.
. - bad = Not possible for separate to the branches
Now the question to the add-on developers, is this way OK about documentation and better to leave in code?
Her on this small is the most finished:
https://github.com/AlwinEsch/kodi/blob/b...CPVRLib.md
Still not finished but visible to see what comes.
https://github.com/AlwinEsch/kodi/blob/b.../Readme.md
Not want to use the normal wiki from Kodi, I think there is more easy do change together with the related code and also is on code view the needed documentation always present.
The only point where I'm not sure is how the docs folder becomes handled.
- one way is to leave there
. - good = together with code
. - bad = a lot of commit messages to change
- and the other is to pass on github repository wiki.
. - good = prevent not needed commit messages
. - bad = That will forget an update again.
. - bad = Not possible for separate to the branches
Now the question to the add-on developers, is this way OK about documentation and better to leave in code?
Her on this small is the most finished:
https://github.com/AlwinEsch/kodi/blob/b...CPVRLib.md
