[psyborg]

Hi folks,

I am new to your community and would like to use XBMC for my purpose, because this is really nice piece of multimedia software, respect!

However, during the development of my own script I realized that some things are currently not possible. So for example, when create a new windowXML (or dialogXML) out of python one can specify an XML file which will be parsed for that window. The underlying mechanism treats this file as a skin file.

However, unfortunately neither includes.xml nor fonts.xml are loaded then. Hence one cannot use own includes and fonts for each of the window created by a python script. Yeah, even worse also the underlying mechanism in xbmc/lib/libPython/winxml.cpp uses CSkinInfo for loading, but seems only to use it to resolve the path correctly and not used further. I would expect that it stores a CSkinInfo object along each window loaded from a skin file. There were two Tickets in the Trac (http://trac.xbmc.org/ticket/6212 and http://trac.xbmc.org/ticket/7171) asking for the function of specifying Font.xml and includes.xml for scripts, I think the request was exactly about this feature, which I also need.

Hence, I would like to write a patch which will store a corresponding CSkinInfo along with every such a window loaded by an XML file. For the part of includes.xml I have already a patch which loads correct includes.xml when creating window in python. However, this seems not to work completly well, includes are parsed wrong, because they are parsed from the global skin info. Also fonts are not loaded at all. I mean the only way now to use my own fonts or includes or whatever Skin specifics in my own windows or dialogs, would mean to include them into the skin itself. Hence, the script wouldn't not be publicable, because it will going beyond its own directory.

My question goes to developers activelly patching XBMC. Is it a feature you would like me to add? What if I have to make changes to the API, so potentially breaking the API (of course the python API will not be touched, to prevent backward compatibility), is it a bad idea? Maybe you can point me on special caveats to take care on, when writing a patch for the first time for XBMC?

Thank you in advance
Art

P.S. I am currently using svn rev32125

[psyborg]

Good news, I finally have done the patch So following is the information about the patch. I will also submit that one to the trac, so that main developers get noticed about it.
-------------------------------------------------
Skin context based patch:

Problem Statement:
Current situation in XBMC scripting is that one can create new windows in Python by deriving classes from WindowXML or WindowDialogXML. The window information is stored in XML files. The implementation assumes some special skin structure (see: http://xbmc.sourceforge.net/python-docs/...#WindowXML), i.e. it assumes a directory structure similar to this (resources/skins/Default/PAL). From script-developer point of view, at least as I have seen that, the main idea is to have some kind of local skin context. Unfortunately it seems that it was not implemented to the end, since one cannot use any includes.xml or Font.xml files. So, there is currently, at aleast I haven't found it, possibility to specify own includes and own fonts in the context of the script.

Solution Overview:
This patch tries to solve that issue. Here we store a CSkinInfo context information within each window. Afterwards whenever includes.xml file is loaded it is loaded in the directory structure of this local skin. Also when fonts are used, they are also created only in the context of this skin. Whenever there is no context specified, i.e. NULL, a standard behaviour is used, so global classes like g_fontManager or g_skinInfo are used.

Benefit:
All script developers do benefit of this. One can now populate scripts with their own font set. Using of own includes.xml allows to prevent duplicates for dialogs and windows of the script.

Test:
The patch was written for svn version rev32125. It makes pretty much changes in the main C++ API, however the default behaviour shouldn't changed. The patch was tested on my Linux machine with my own script. I could also provide small test script showing the functionality, if required.

I hope that the patch get included into the svn trunk, since not only me need this functionality

Patch file can be found in the trac: http://trac.xbmc.org/ticket/9742
Best regards,
art

[giftie]

I'll be following this closely... It really will be nice to be able to use a font(s) special to the script/plugin.

Hope it does make it to the svn!!

[garbear]

I'm attempting to tackle this in my pull request 452 (PR).

If I understand #9742 correctly, psyborg gives every window its own skin context (includes, fonts, maybe other stuff).

I take a different approach, a script's includes.xml is simply added to the global skin. With regards to namespace pollution, if there is a name clash, the end result is identical to the case where a skin's includes.xml uses the name twice -- a debug statement is logged and the new include ignored. (todo for me: verify this ). Due to the reason of addons having the ability to support multiple skins with a "Default" fallback, multiple includes.xml files can be used for each skin/resolution if desired. Ex:

• addon.id/skins/Default/720p/includes.xml
  
• addon.id/skins/Default/NTSC/includes.xml
  
• addon.id/skins/skin.transparency/includes.xml
  

My approach is much more lightweight and accomplishes pretty much the same thing. Is my strategy proper? Is there any merit to psyborg's approach?

[giftie]

I wish I could do more to help other than testing(need to read and play with C++ more). I appreciate the work..

[garbear]

I wish I could do more to help other than testing(need to read and play with C++ more). I appreciate the work..

As long as you keep working on that cool auto-cd-ripper option, I think both of us will be happy