[SmSpillaz]

I'm not too sure if this fits in here.

Are there any plans to further modularize the XBMC code so that it is more accessible to plugins and the like? From what I can understand - scripts are more or less self-contained little applets that have to be launched separately of the rest of XBMC's core functions. How powerful are these scripts for adding major-ish new features into XBMC. From what I can see they can access the net and throw a few things up on screen and that is it.

As far as plugins go, all I can see is that they are useful as 'media providers' to xbmc and don't do much else (i.e they can provide media items in music / videos / tv / movies / programs etc).

Would it be better to modularize the code to make the xbmc core quite small and have all the other bits of functionality implemented as plugins? (like music, movies, tv etc). I think this might require a large rewrite of how skinning works but it could be worth it in the long run such that implementation of more complicated code that address many parts of the media center can easily be implemented.

This isn't a request - just merely an ask for an opinion.

[Clumsy]

Although I am far from being an expert on the code, there is for example work being done on an addon system, that will for example be used for the PVR frontend stuff for different backends. This is written in a way to support other features as well, but a developer would have to comment on the specifics.
Python also is exposed to quite a few core functions, but of course not everything. If I for example look at how slow and unstable firefox has become recently, especially with alot of plugins loaded - I kind of don't really like the idea of giving access to everything for plugins or similar. This could evolve into a support nightmare.

[SmSpillaz]

Although I am far from being an expert on the code, there is for example work being done on an addon system, that will for example be used for the PVR frontend stuff for different backends.
This is written in a way to support other features as well, but a developer would have to comment on the specifics.

Is this addon system independent of the PVR features or is it just an addon system _for_ the PVR features.

Python also is exposed to quite a few core functions, but of course not everything. If I for example look at how slow and unstable firefox has become recently, especially with alot of plugins loaded - I kind of don't really like the idea of giving access to everything for plugins or similar. This could evolve into a support nightmare.

Plugin systems tend not to be slow unless you either A) have a _lot_ of plugins loaded and B) they are written inefficiently.

I do development for compiz and I can say that the main problem for a pervasive plugin system is the issue of too much control to the plugins, which negatively affects the rest of the interface. As for us, we have had up until recently mandatory control passed to each plugin for each core event.

I think in something like XBMC, plugins are not likely to negatively impact upon each other since XBMC is generally a one-task-presented-to-the-user kind of interface.

As for the support nightmare, it's simple to make a list of supported and unsupported plugins, although I would imagine that for something as big as xbmc, 90% of users will hold the "I dont care fix it now" mentality.
[/quote]

[Clumsy]

I have moved the thread, since it is more general than python and more of a feature "request" or discussion.
I am the wrong guy to really specifically answer your questions, I am sure somebody will chime in who has the code knowlede, but I am pretty sure the addon framework is done in a way so it can be utilized for more than just the pvr frontends. Likely code changes will have ot be done there though, but I think screensavers for example where another usage example.
As performance and support issues goes: give them too much control, and it becomes a nightmare for both. I am unsure how this will pan out, but given my experience with the forums here, most users don't care for technical reasons at all - they just want everything to work perfect or they simply complain. And that annoys our devs

[SmSpillaz]

I have moved the thread, since it is more general than python and more of a feature "request" or discussion.

Sure, you probably know better than I do

I am the wrong guy to really specifically answer your questions, I am sure somebody will chime in who has the code knowlede, but I am pretty sure the addon framework is done in a way so it can be utilized for more than just the pvr frontends.

OK

Likely code changes will have ot be done there though, but I think screensavers for example where another usage example.
As performance and support issues goes: give them too much control, and it becomes a nightmare for both. I am unsure how this will pan out, but given my experience with the forums here, most users don't care for technical reasons at all - they just want everything to work perfect or they simply complain. And that annoys our devs

Annoys our devs too ;-). We even have a factoid in IRC about that.

20:58 < SmSpillaz> !doesntwork
20:58 < FusioBot> Doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific! Examples of
what doesn't work tend to help too.

[analogue]

Check the link in my sig for what a non-trivial python script can do. It is unfortunate that more of XBMC's internals aren't easily pluggable or expandable and also require development in C/C++ when other languages are vastly more productive (assuming utmost efficiency is not an issue). Something more akin to the Eclipse (http://www.eclipse.org) feature/plugin eco-system would probably be more general but would require massive refactoring.

[rwparris2]

I think giving addons access to extend the context menu would extend the possibilities of addons greatly. I requested it a while ago, iirc spiff said it was doable

http://trac.xbmc.org/ticket/5442

Is this addon system independent of the PVR features or is it just an addon system _for_ the PVR features.

From what I understand Alcoheca's work is for addons in general, but was needed for him to complete the PVR. I've spoken with him about it briefly, but to be honest I was a bit confused as to what all it would add.

It would be great if we could get some comments from him to clarify.

[SmSpillaz]

Check the link in my sig for what a non-trivial python script can do. It is unfortunate that more of XBMC's internals aren't easily pluggable or expandable and also require development in C/C++ when other languages are vastly more productive (assuming utmost efficiency is not an issue). Something more akin to the Eclipse (http://www.eclipse.org) feature/plugin eco-system would probably be more general but would require massive refactoring.

I tried out mythbox once. It's fairly impressive, however is it tied to the one skin [pm3.hd]?

[jmarshall]

In all cases it would be tied to one skin - after all, the skinner has to skin whatever any magic plugin provides.

This was the whole reason that the current plugin system for directory listing was added - it allows rich media content without the scripter having to care about the skinning side.

You either have a powerful skinning system that can skin everything, with the disadvantage of skinners having to skin addons, or you restrict how you can skin stuff for addons to ensure universal support across skins. Scripts do the former, plugins do the latter.

More ideas on this front are always welcome.

Note that the upcoming addons branch handles visualisations, screensavers, scrapers and pvr addons - it provides a common interface for many addons. We'd welcome extensions to other areas.

Cheers,
Jonathan