2010-07-25, 12:21
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
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