[Livin]

To make customizations easier for someone that just wants to add a button or two or change fonts/text/etc...

If in the UserData folder we could have a way to specify a modification XML file for XMLs in the skin.

I have changed the MyWeather.XML to add a button so now I must remove the original and replace it with my mod'd one every time I update the skin (I have several XMLs I must do this with).

Instead it would be nice to be able to include a "Skin" folder under UserData and have a file named the same: MyWeather.XML

In this file there would be two items...
1) the modifications/additions
2) the placement of those - including line # for where to insert/replace

Example MyWeather.XML in UserData\Skin\Project Mayhem III\PAL folder
- this code would be "inserted" in the regular XML at the line specified, 81.

Code:

<insertatline 81>
   <control>
     <description>Radar Button</description>
     <type>button</type>
     <id>50</id>
     <posx>60</posx>
     <posy>157</posy>
     <width>135</width>
     <height>35</height>
     <label>Radar</label>
     <font>font13</font>
     <onclick>Q:\scripts\Xradar\Xradar.py</onclick>
     <onleft>3</onleft>
     <onright>3</onright>
     <onup>2</onup>
     <ondown>2</ondown>
     <align>center</align>
       <include>buttonpanelslide</include>
   </control>
</insertatline 81>

If this is not easy to do then at least allow us to have a centralized folder in UserData where we can place our complete XMLs to be substituted for the ones in the Skin folder.

[Ph03n1x]

I agree this would be a nice feature, the ability to redefine controls within an existing skin would be great. As this feature would be primarily for skin mods, one way to handle this would be to create a theme package that contained the necessary files as well as a <theme-name>.xml file which defined the controls that needed to be modified. This would make installing and distributing mods easier for the user and the modder.

[jmarshall]

Write a script to do it on the PC side.

[Livin]

Makes more sense to have it built into the system itself... just like themes are.

[Freddo]

it'd be cool if you could toggle your custom xml's on and off individually from the skin settings page too.

then you would have like a whole new angle for people to create interesting themes and addons and gizmo's for existing skins, users could try them out much more easily if they didnt have to faff around over-writting files and stuff.

[Livin]

it'd be cool if you could toggle your custom xml's on and off individually from the skin settings page too.

then you would have like a whole new angle for people to create interesting themes and addons and gizmo's for existing skins, users could try them out much more easily if they didnt have to faff around over-writting files and stuff.

JM, see... these people get it... it makes thing soooo much more flexible!

[jmarshall]

Each skin update would mean manually merging your changes anyway (as the skin's structure/positioning may mean that your mods make no sense, or must be changed accordingly).

Thus, you mayaswell do it once and not bog down XBMC with lots of code for the 0.1% of users that may benefit from it. If those users want it, you're most welcome to code it and supply a patch.

[Livin]

JM,
I know you may not be a fan of this one but I will ask you to reconsider since we are past the point release.

If you could add code to have XBMC check a folder, like \UserData\Skin\<appropriate folder structure> when loading the skin and substitute whatever files we have there for the files with the same name in the skin, it would be appreciated.

Right now with each update, I need to rename 6 original files in the skin folder and copy over my custom XMLs. Not that this is a HUGE issue but since we have a UserData folder I think it would be nice to have a consolidated place to put all custom, user specific, files.

I'm no coder but I'd hope this was a simple routine to check the folder structure before loading the skin files?

Please consider this once again, thank you.

[jmarshall]

As I stated before in this thread:

You only have to update the skin when the skin gets changed. When the skin gets changed, your changes probably won't function, so will need re-merging etc. manually anyway. Allowing users to load skin xml files from elsewhere just asks for trouble when the skin changes and there modified files no longer function.

With that said, the skin can in fact reference files outside it (via includes). If you include a file from the userdata folder then that will already accomplish what you want. You will, ofcourse, still require at least one change to the skin files to allow this to happen.

Cheers,
Jonathan

[Livin]

As I stated before in this thread:

You only have to update the skin when the skin gets changed. When the skin gets changed, your changes probably won't function, so will need re-merging etc. manually anyway. Allowing users to load skin xml files from elsewhere just asks for trouble when the skin changes and there modified files no longer function.

With that said, the skin can in fact reference files outside it (via includes). If you include a file from the userdata folder then that will already accomplish what you want. You will, ofcourse, still require at least one change to the skin files to allow this to happen.

Cheers,
Jonathan

Actually I disagree, using my own experience as an example. My 5 or so custom XMLs (home, weather, etc) nearly never need to change. I believe I have changed them maybe 2x in 2 years due to skinning engine changes.

The includes, I do not believe, solves the problem since with every "refresh" of the build I'd need to overwrite the same files with Include statements inside (that do not exist in the SVN files) ... right?

Thus the only solid solution is to allow the user to place any XML files that need to be overridden / replaced inside the UserData folder in the corresponding skin directories and have XBMC read that structure during skin loading... this should pertain to any skin files, including Includes.xml.

Multiple benefits to my method:

a) Easier and more efficient updating to new builds for those of us that customize our skins... right now it is a small pita.

b) Easier and more efficient testing of skin mods... easier to rename folders (in order to insert/remove test files) then to copy multiple files back/forth and/or rename files in multiple folders in the main skin structure.

c) Single point of backup and recovery for customizations.

[jmarshall]

I don't understand why you move the skin folder over every single time, and if you do, why you can't simply batch this with the normal batch file that is in CVS (the one that builds PM3).

This could be trivially altered to allow replacement of files from outside straight in to your skin.

It's just not something that I'm going to bother going to the hassle of doing - particularly when it could cause all sorts of headaches for the support folk - it's just yet another point of failure.

Others can, ofcourse, feel free to do so - this is the joy of opensource. The loading code is pretty straight forward - see CGUIWindow::Load(). That path to the file is set somewhere in the CSkinInfo class.

Cheers,
Jonathan

[SandmanCL]

To me this sounds like a relatively easy thing to code that many people would benefit from.