Kodi Community Forum

new skin system.

just wanted you guys' opinions on the includes.xml file.

currently it operates as follows:

1. includes.xml is in one (or more) of the folders. if you just want to use the one, then put it in the default resolution folder.

2. format is:

Quote:<includes>
<include name="includename">
<tags to include>
</include>
...
</includes>

3. xbmc reads the includes.xml when the skin is loaded. it only reads the one from the resolution folder that best matches the resolution you are in (ie it'll start in the resolution the user is using, then drop down as occurs with the normal window xml files).

4. whenever xbmc reads another xml file, it looks for <include>includename</include> tags. it does it in the following places:

* top part of the window xml file (ie under the <window> tag).
* inside the <controls> tag (allows including whole controls)
* inside the <controlgroup> tag (allows including whole controls)
* inside the <control> tag.

it only looks at the direct "children" off the above tags - ie if there is a 2 layer tag, it won't look into the second layer at this point (don't think there is any situations of this, other than the button scroller button defines i guess, and that is easy to take care of)

if it finds an <include> tag, it grabs the tag name, and replaces it with the tags contained within it's block in includes.xml. it checks things one by one, so you can have <include>'s of <include>'s in includes.xml with no problems.

another change i've made that i mentioned before is that you can now specify font colours and font shadow colours in fonts.xml directly. this means you can define the colour of the labels once, rather than throughout the skin files. i previously mentioned that you shouldn't have more than 2 font definitions with the same font file (ie same font, different colors) as it used twice the memory, but i have fixed this now - they now share the font file memory. the shadow colour is for a 1 pixel offset (right and below) rendering of the label first. this allows a little bit more contrast to the font when it's on dark (or light) backgrounds.

let me know what you think. it's not in cvs yet obviously (as it's untested)

cheers,
jonathan

will you be able to "overwrite" the setting in the fonts.xml and strings.xml files using info in the includes.xml?

ideally a person moding an existing skin would be able to change any aspect of the existing skin via a single file (includes.xml), thus being able to in effect create a theme without modifying the original skin files.

you may misunderstand how it works then. the user will only be able to change things that are in use in includes.xml - if it's not being used for a particular thing, then they'll have to edit the other files. any additions to the skin via includes.xml will require at least an <include> tag added to the window skin file concerned.

and no, this has nothing to do with fonts.xml or strings.xml. the first is to define the fonts - i don't see much use of requiring an include file there (though i agree that adding new fonts should be made easier where it can, such as with ttf fonts - just dumping the font file in should be enough in that case, as the size of the font is really the only crucial bit.).

strings.xml is a different animal. while skin labels can ofcourse be defined in includes.xml (anything can be, after all) as it can also be used for other things, it may be advantageous to have a separate skin strings.xml file that is consulted when the normal strings.xml file yields no labels. i'm not sure about that - which is why i ask for suggestions

this really has nothing to do with themes at this point, and is not designed for that - it's designed to make skinning simpler first and foremost. obviously it may help some skin mods become simpler, that's not its goal.

cheers,
jonathan

(jmarshall @ jan. 06 2006,05:57 Wrote:it may be advantageous to have a separate skin strings.xml file that is consulted when the normal strings.xml file yields no labels.  i'm not sure about that - which is why i ask for suggestions

sounds like what i suggest recently in this thread. my thought was originally for skinners who use their own keymap.xml, but i realized the same approach would be perfect for strings.xml as well. i thought about how they current keymap.xml "fall-through" system works between global controls and window specific controls. i think this same concept could be applied for this purpose so regardless what the main strings.xml says, if an id is otherwise specified in the skin specific strings.xml, the skin specific strings.xml should take priority and be used instead of the main strings.xml (even if it isn't a new id in my opinion). personally, i'd like to see this approach for both keymap.xml and strings.xml.

los93sol

you and the damn keymap fall through... you just wont give up will you? i, personally, would be really pissed off if a loaded up a skin which altered *my* keymap.

kraqh3d, i think its a good idea (keymap.xml), the system would be more flexible.

sollie.

a fall-thru system so that a skin can override keymap is absolutely idiotic. the keymap needs to be kept completely isolated from the skin. there is no reason why a skin would require changes to keymap. and like i said before, i'd be really pissed off i loaded a new skin and found that it changed *my* custom button assignments.

sollie, your request is completely different. you want to be able to "select" a keymap.xml from within the gui. while i think this is a useless request for the 0.01% of users who happen to use more than one remote, i honestly couldnt care less about it as it wouldnt allow a skinner to change my button assignments.

personally i think the current system works well enough... xbmc is designed to be used with the xbox remote and controller and does this flawlessly so i cannot see why changes are needed. the last thing i want is to have to guess what button i need to press relevant to the skin im using yuk!

(kraqh3d @ jan. 06 2006,12:35 Wrote:you and the damn keymap fall through... you just wont give up will you?  i, personally, would be really pissed off if a loaded up a skin which altered *my* keymap.

kraqh3d, geez man, my last post wasn't intended to push for the keymap.xml, i'd like to see it, but really, i was just using it moreso as an example to explain how the strings.xml stuff could work since the keymap is already on a similar system. sorry for the misunderstanding.

now your changing your statement? i see no misunderstanding... to quote you:

Quote:i think this same concept could be applied for this purpose so regardless what the main strings.xml says, if an id is otherwise specified in the skin specific strings.xml, the skin specific strings.xml should take priority and be used instead of the main strings.xml (even if it isn't a new id in my opinion). personally, i'd like to see this approach for both keymap.xml and strings.xml.

skins, gui , key mappings... they do overlap along the way. skins are not just visual, they are a complete gui revamps which imo does include keymapping. generally it is very desireable to have xbmc maintain a consistant keymapping. this makes the transition from skin to skin more familiar for each user.

that said, there are circumstances where users may want various keymapping. this also allows for skinners to more easily experiment with new keypad and remote mappings. this opens the posibilities for a new, possibly more friendly keypad/remote interface for xbmc. keymap overriding is not the best way to impliment it, but a keymap selection could be a welcome addition.

imo the xbmc skinning process is already complicated as it is now, without adding more xml files to it, so no! strings.xml or keymap.xml in the skin please.
if a  skinner want, can always provide it within the skin and  the user will decide to use it or not.

look @ the main skins sites and count how many skins are out there (i mean original skins,  not mockups or copies), there are not more than the fingers of a hand, and i beleive they will be less after 2.0 skin vers. i personally don't even know if i'll never release a widescreen version of my skin because it took me already a lot of time.

the topic say "proposed changes for skin v2.0" but i still find bugs from 1.3 version...

(kotix @ jan. 06 2006,20:38 Wrote:look @ the main skins sites and count how many skins are out there (i mean original skins, not mockups or copies), there are not more than the fingers of a hand, and i beleive they will be less after 2.0 skin vers. i personally don't even know if i'll never release a widescreen version of my skin because it took me already a lot of time.

the topic say "proposed changes for skin v2.0" but i still find bugs from 1.3 version...

and yours is original .. right , if you take a look at it closely you see that every skin is based on project mayhem in one way or another..so that's totall bull.. and if its taking to much time to make it in 16x9 then why even start in the first place... nofi , and if you still find bugs in v1.3 than why the heck didn't you say so..than it would be allready fixed.. and if you not like the includes.xml than you always have the choice of not using it... personally i think there will be coming out a few excellent skins for v2.0.

the executive decision has been taken. i won't be adding support for a separate strings.xml file, nor will i be supplying a separate keymap.xml for skins. as for alternative keymaps selectable via the gui, please supply a patch and it will be discussed as a team.

if you want to use new labels, then i suggest you place them at the top of includes.xml so that they're easily changeable in one location for others.

for those skinners wishing to alter the keymap for whatever reason, i want to know the reasons, as they might be worthwhile things that we can do a different way. this isn't the thread for it, however.

lastly, if there are any bugs in the skin system i want to know about them. they are a top priority.

as kotix has said, it's not an easy thing making an xbmc skin, and i don't want to do anything that makes it more difficult. if you have any ideas to simplify the process, i'm all ears.

cheers,
jonathan