2010-09-18, 04:37
D-Bus might be present under Linux but not on OSX and Windows. Any solutions involving addons must be compatible with all three platforms, Linux, OSX and Windows.
davilla Wrote:D-Bus might be present under Linux but not on OSX and Windows. Any solutions involving addons must be compatible with all three platforms, Linux, OSX and Windows.
dbrobins Wrote:To jfcarroll: If, at some future time, more language bindings are added and an add-on is written in a language not supported on a client, how would that be indicated? Would the add-on show as gray in the browser with status "Language 'x' is required for this add-on.", or not show up at all? Doing either of those seems user-hostile ("I don't care what language it's written in, I just want to be able to install and play Merlin's Amazing Party Tetris!") Or is the plan to just include every language in the tree?
jfcarroll Wrote:I had been thinking about this and thought it might be a good idea for "language support modules" to be themselves "plugins" that if not installed, get automatically installed (or they can all be installed as part of the xbmc install). Then Python (as well as a Jvm, etc.) would be installed along with the SWIG bridge code, in shared libraries.
jfcarroll Wrote:If by "not supported" you mean that language is not available for that platform at all (is Tcl available for Windows?) then the facility that allows addon's to identify the platforms they are targeted for will specify that.
If you mean the particular computer doesn't have that scripting language installed (e.g. a Jvm isn't currently installed) then there's more than one way to solve it. I don't think that, for example, requiring the installation of a Jvm is all that hostile - but if that doesn't work for people, there are ways to include it as a prerequisite and have it installed automatically as a step in the process of installing the plugin.
Quote:I had been thinking about this and thought it might be a good idea for "language support modules" to be themselves "plugins" that if not installed, get automatically installed (or they can all be installed as part of the xbmc install). Then Python (as well as a Jvm, etc.) would be installed along with the SWIG bridge code, in shared libraries.
In any case the issue here is not that there isn't a possible solution, it's that there's several that we would need to pick from.
alcoheca Wrote:This is how I see it too. Probably more useful on windows that any other OS, as I believe there was plans to support running the current scripts through the distro's libPython, rather than custom compiling and loading our own SO - might be out of the loop on that though..
The bridge code libraries would certainly be addons though
On this subject, won't your C++ API have binary compatibility issues with these 'bridging libs' loaded on-demand by c-pluff?
dbrobins Wrote:Ack, that's a perilous minefield to tread. How many binary versions will an addon repository have to keep (of the paired bridge library and language library) to match all the relevant architectures and OS versions (and distributions)? Maybe it is better for some of the language dependencies to be pulled from known good sources (e.g., for Windows+perl, grab the ActivePerl 5.x installer and run it, if their license allows for that - but then there's a million Linux distros, even though Ubuntu? is the only officially supported one IIRC).
Quote:On this subject, won't your C++ API have binary compatibility issues with these 'bridging libs' loaded on-demand by c-pluff?
[email protected]:jimfcarroll/xbmc-multi-language-addons.git
./configure --enable-external-python --enable-newswiggyaddons