Kodi Community Forum

Now that I've finally got a handle on how the skinning system works and how all the pieces fit together, I've got some thoughts.

I'm an Android app developer. I've noticed that the XBMC ecosystem is a lot like the Android system (XML gui, and java APIs) in some ways. XBMC has XML GUI, some core APIs (http://wiki.xbmc.org/index.php?title...t_In_Functions) and Python scripting.

The big difference is that XBMC programmatically limits the structure of the overall skin by by making the built-in controls available only in the context of certain windows, which are predefined and are not skinner configurable.

http://wiki.xbmc.org/index.php?title=Lis...n_Controls

XBMC as a media engine could be used for many more things than just a typical media center. Right now it's limited to a certain way of doing things by exposing only certain controls in certain windows. It could be a one-stop shop for creating any kind of media based application.

Here's a hypothetical example. Say I want to make a skin that turns the computer into a basic, mulitlingual CD player. I want to only have one screen that shows playback controls, language selection, and displays fetched cover art when a CD is inserted. Right now I can't put the language selection on the home screen, because that built-in control can only be accessed from WINDOW_SETTINGS_APPEARANCE.

Likewise, when building a Boxee-like home screen. Say I want to place a group list on the home screen that was, for example, a list of all the videos in the Classic Cinema App in the Sci-Fi category. Currently I can't display that list on any screen except WINDOW_ADDON_BROWSER ( I think).

All of these limitations can be overcome by de-coupling the built-in controls from the pre-defined window definitions, making them available in any window . This would let the skinner define which built-in controls to use on any window. This can be accomplished by giving each built in control a globally unique ID, rather than just a locally unique ID in each pre-defined window definition like it is now.

This could be done with a window definitions master xml file that acts like the current internal table, linking the name, definition, window ID, source xml file, and built in control-ids for each window.

What do you guys think? Is this something the XBMC team would be interested in for future versions? It would simplify things, I think, because XBMC would no longer have to define and maintain all the current window definitions and their associated built-in controls. Skinners would have no limitations with what they could do in regards to layout and navigation for all controls.

Similar to the way Android lets you just build xml windows and define what controls to use (or what they do with java), XBMC could do the same thing, opening up the full functionality of its exceptional media engine so anyone could make any kind of media-based application very very easily.

jerimiah797 Wrote:Now that I've finally got a handle on how the skinning system works and how all the pieces fit together, I've got some thoughts.

I'm an Android app developer. I've noticed that the XBMC ecosystem is a lot like the Android system (XML gui, and java APIs) in some ways. XBMC has XML GUI, some core APIs (http://wiki.xbmc.org/index.php?title...t_In_Functions) and Python scripting.

The big difference is that XBMC programmatically limits the structure of the overall skin by by making the built-in controls available only in the context of certain windows, which are predefined and are not skinner configurable.

http://wiki.xbmc.org/index.php?title=Lis...n_Controls

XBMC as a media engine could be used for many more things than just a typical media center. Right now it's limited to a certain way of doing things by exposing only certain controls in certain windows. It could be a one-stop shop for creating any kind of media based application.

Here's a hypothetical example. Say I want to make a skin that turns the computer into a basic, mulitlingual CD player. I want to only have one screen that shows playback controls, language selection, and displays fetched cover art when a CD is inserted. Right now I can't put the language selection on the home screen, because that built-in control can only be accessed from WINDOW_SETTINGS_APPEARANCE.

Likewise, when building a Boxee-like home screen. Say I want to place a group list on the home screen that was, for example, a list of all the videos in the Classic Cinema App in the Sci-Fi category. Currently I can't display that list on any screen except WINDOW_ADDON_BROWSER ( I think).

All of these limitations can be overcome by de-coupling the built-in controls from the pre-defined window definitions, making them available in any window . This would let the skinner define which built-in controls to use on any window. This can be accomplished by giving each built in control a globally unique ID, rather than just a locally unique ID in each pre-defined window definition like it is now.

This could be done with a window definitions master xml file that acts like the current internal table, linking the name, definition, window ID, source xml file, and built in control-ids for each window.

What do you guys think? Is this something the XBMC team would be interested in for future versions? It would simplify things, I think, because XBMC would no longer have to define and maintain all the current window definitions and their associated built-in controls. Skinners would have no limitations with what they could do in regards to layout and navigation for all controls.

Similar to the way Android lets you just build xml windows and define what controls to use (or what they do with java), XBMC could do the same thing, opening up the full functionality of its exceptional media engine so anyone could make any kind of media-based application very very easily.

Well, not being a developer, my opinion means jack haha..

But I think you are under estimating the possibility that these limits are placed by design in order to maintain some degree of continuity from skin to skin. That is to say, specifically to limit the functionality of skins to merely being skins of a program that behaves in a consistent way, rather than allowing skins and plugins to redefine the program's functionality all together.

To me, what you are talking about sounds like a really interesting branch idea, but should probably not be added to XBMC itself.

That being said, it would be nice to have more free reign in terms of what can appear in what window.

I agree - the current system is well suited to what it's doing - that is, keeping the application consistent in how it functions and making the skin exactly that - the UI for the program as written.

What I'm talking about is definitely a different direction than how we think of skins right now. The skins that I'm suggesting could be built would be custom and probably not installed by XBMC itself - they would be manually added and activated in a user directory.

Any easy way to maintain general compatibility for traditional skins would be to have the master xml file like I described embedded in the app, like it currently is, so normal skins would work, but make it so an external xml file can override it. This would be non-disruptive to the general XBMC user base and skinning scene, while providing the flexibility to use the XBMC engine as the core for an app.

Don't apologize for not being a dev. I don't discriminate. I think good insights are good insights, regardless of the source.

There's a couple of things to note here:

1. Many of the builtin buttons/controls only make sense in a single place. i.e. they're specific to the context that the user is browsing. Simple examples would be the Stack button in videos - it makes no sense to have that toggle be anywhere else.

2. Similarly, the code to do these things has to be somewhere. Thus the reason all (or at least the vast majority of) the settings are in the same place - the code can then be placed in the window classes and all the usual sorts of control structures can be put in place (eg you set setting foo and it disables setting bar automatically). This would be difficult to do if the code for setting foo and setting bar were placed elsewhere.

3. XBMC is a media center, so we at least try and stay to that goal, so don't really give too much thought to how to do things completely differently unless the completely differently makes sense for a media center interface.

With that said, there's generally been a goal to decouple functions from windows where that makes sense. eg many of the current controls (view as controls, sort by etc.) can be placed outside of the main window as you have builtin functionality for toggling these things.

Similarly, there's definitely a goal of allowing listings outside the main view(s). In particular, we accept that what a user wants on their homescreen should really be up to them, rather than up to the skinner (or enforced by a lack of flexibility in XBMC core).

Thus, we're definitely wanting to allow listings to be generated anywhere - i.e. just specify a URI and XBMC fills the list automatically. There's several technical problems with this though, not the least of which is what to do regarding how things should sort in said lists, and what should happen when you click on things etc. As an example, I can guarantee that as soon as we add the ability to place a list on screen with arbitrary content, that a music screen where you have 3 lists (artists, albums, songs) that automatically update themselves when you click on the various categories is going to be attempted. Sorting these various lists is then something that will be desired, so now you don't just have "give me a list" but you have "give me a list, sort it this way". In addition, users will expect that things like the context menu should popup on these lists. This leads the "dumb" lists which are easy to implement to dragging around code that describes what should be doable on these lists, and things get out of hand very quickly.

Thus, you need a clear design guideline as to what we want to achieve with these lists, and these will need to include all of these cases that skinners + users will be expecting. Once that is done we can see whether it's feasible or whether limitations need to be put in place.

Cheers,
Jonathan