[alwinus]

Still working on my add-on library rework. Is now the biggest project on Kodi for me.

Whats done:
- It have now a complete reworked Binary add-on library system for C++.
- It have a improved exception handling for the Binary add-ons and if everything is finished can it not come to a crash of Kodi anymore, only to a dialog message that a Add-on is crashed.
- The libraries are now complete in C++, no C parts on add-on side needed anymore (no malloc, or free needed).
- All headers are cleaned up and shows only the for add-on development needed parts.
- The libs support everything, now with the same functions as add-ons with Python
- Created a complete new Documentation for it and also included all the Python API docs to them. Also few parts from Wiki added and related text is inside code, this allow Doc. updates direct with code changes.
- The binary add-on parts are now all together in a nearly independent place to allow "Development Kits" in the future.
- The new library system is also thought to extend for other languages, like Java or JavaScripts (maybe planned after this changes are in)
- The libraries are Version independent and after a API Level change the old is still usable, this bring more time for add-on updates.

What is to do:
- Add a way to run Binary add-ons for everything, like them on Python.
- Cleanup the changes (over 80000 lines now)
- Maybe add more documentation on them.
- Rework maybe all CGUIInfoMessanger strings, like the on "const infomap system_labels[]..." to static places, to allow documentation with Doxygen style there.

What comes after it is in:
- Then comes a rework of the Add-on system functions itself (Add-on -> Kodi) e.g. the PVR, to allow also Version independent Versions (Not possible to do together, then gets conflicts)
- Continue the Webbrowser system, thats why this comes before, there is a bit more needed as on all other add-ons before.

Here are the Links to them:
- New documents - http://alwinesch.github.io/
- Reworked add-on system headers for C++ - https://github.com/AlwinEsch/kodi/tree/b...on-dev-kit


So now my question to the Developers and Users:
- Is the new Document style OK?
- Is the way to accept, as it is introduced in the Code? See e.g. https://github.com/AlwinEsch/kodi/blob/b...#L487-L565
> This way, allow for me to do changes on code direct with related docs and prevent wiki from missing updates.
- Can someone also introduce document parts, maybe taken from Wiki?
- From my side I want everything for development together there on the new documents and nearly independent from Wiki (Wiki for user and Doxygen parts for developer), also for others OK?

The old thread:
http://forum.kodi.tv/showthread.php?tid=246108

Points to fix or improve on rework
- If a CPlayerLib::UnregisterMe is not called and the CAddonLib::UnRegisterMe(); becomes called, comes on class destruction a crash with missing parts for the UnregisterMe

[ironic_monkey]

my .02c; the documentation is awesome (some spelling mistakes so it would probably benefit from a somebody more experienced in english helping out a bit). splitting the documentation makes sense and doxygen is the way to go.

[da-anda]

I can't say much about the code/implementation as I'm not at all into this, your description on what's possible etc (especially the backwards compatibility thing) sounds just great though. Also I think using Doxygen is the way to go. While I think the Wiki is fine for tutorials, code documentation only makes sense in the code.

One small thing I noticed while following one of your links above: The builtin player function "playdvd" should likely be changed to "playdisc" and the method description would have to be adjusted to something like "Plays the inserted disc, like CD, DVD or Blu-ray, in the disc drive.". https://github.com/AlwinEsch/kodi/blob/b...s.cpp#L570

I also think you should create a PR and try to merge this as soon as possible and not try to bring in all the new features you have in mind in one go as giant and unreviewable PR. It's better to PR in smaller chunks. So if what you already have is working and not breaking anything, shove it in and do further cleanup and improvements step by step in follow up PRs (like the PVR changes, rework of GUI infomanager, ...).

[zag]

Documentation... \0/

And yes what Da-anda says is best, get each PR up as you go along. Its very hard to get big changes merged sometimes.

What I would also like to see is a tutorial of how to make a simple binary Add-on

EDIT: Is there a way to edit this documentation? I can fix the English spellings if wanted.

[ironic_monkey]

there's no sane way to split this PR up. it changes all addon bindings in one go.

zag, it's all doxy (inline comments in the code) plus some .doxy files.

[alwinus]

Thanks to all,

commits comes on end a bit separated to different parts. (was currently for my own review better to have always in one commit to see what is changed )

For the doxygen I use normally on Linux "doxywizard" where it is easy to change the settings, it create the html's and starts load with browser.
Then I edit the text by hand, starting the button "Run Doxygen" and I say to my browser (for present local website) reload
For bigger texts (like them from wiki) I use Markdown which is partly supported from doxygen and for this the editor Haroopad

With a simple binary was planned from me after the system is independent and not fixed to parts like PVR...

[da-anda]

there's no sane way to split this PR up. it changes all addon bindings in one go.

Yeah, I thought so. I just mentioned it because it sounds like alwinus will add more and more stuff to it and I think it's better to PR current state (if working) and do the additional improvements after that.

[alwinus]

From the todo is then only now to add few missing parts to GUIListItem and the documentation for them and the window, thats all.

And @zag,

thanks a lot to you if you help me to improve this english

[Martijn]

there's no sane way to split this PR up. it changes all addon bindings in one go.

Yeah, I thought so. I just mentioned it because it sounds like alwinus will add more and more stuff to it and I think it's better to PR current state (if working) and do the additional improvements after that.

No way in splitting up the binary and python part as it's now one big lump which is huge.....?
My feeling is that all the Python doc changes could be split of to make it a bit manageable

[ironic_monkey]

problem is that afaik the python implementation also change with the binary addons changes (common bits of code). so the python things aren't pure doxy. i guess it would be doable but it would take a lot of coffee and stamina to handle the rebase.

[alwinus]

About the Python parts, on the code of them is nothing from me changed, is only the documentation. On the pull request becomes the Python system separated in a own commit to separate it in review.

[ironic_monkey]

righty'o.

[da-anda]

btw, alwinus, did you continue discussion with jfcarrol in regards to swig and interface generation?

[alwinus]

I can speak with him, to use swig nearly complete over the reworked library was also in my mind.

Only not sure with Python, not all functions are using the same way, a good example is the handling of Info tags on a GUI list item, seen on Python every value is identified with a string and seen a very big list of string compares there, with this reason I changed the way to Integer identifier for binaries and becomes checked by a "switch".

[alwinus]

@da-anda have added "playdisc" and a not marked "playdvd" as deprecated. Also fixed the last night some compile errors (comes in on last reworks ).

On test I found few places to fix, but looks until now.

One good point what I found for all PVR add-ons, have added the possibility for add-on to open SettingsDialog, this fixes a issue on vnsi where it fails to init without set of the settings one time.