View Full Version : XBMC-Skin version system of some sort?
currently there is no way to differentiate between skins that are compatible with the current xbmc cvs and skins that are not compatible.
perhaps creating a seperate "skin version" that is changed whenever there is a change in cvs that would require a skin update would be useful?
the skinners could define a <minversion> and a <maxversion> in skin.xml and xbmc could warn the user that they are trying to load a non-compatible skin.
i.e. "the skin you are trying to load may not work properly with this build of xbmc. do you wish to continue loading this skin? (yes/no)"
jmarshall
2004-08-24, 21:52
i've had this in mind for some time, but have yet to come up with a reasonable solution.
the problem is, that cvs is updated all the time, and people then release builds from cvs. these builds all have the same version number of the previous "official" version (at the moment 1.0.0) yet changes have been added to the skin and/or skin subsystem between these dates.
how would you suggest we get around this, given that the xbmc team do not distribute builds of xbmc, and have no control over those who do?
cheers,
jonathan
is anything in the skin.xml read in by xbmc? or is it just info?
if so-and this is only my own opinion but if a version number was added which chokemaniac or one of the rest of team could update if any of the other skin related xml's are modified/added (i don't think replacing the xpr or substiuent pngs/jpgs/gifs warrants a rev change).
then if the version no. in the "other" skin.xml was < the version no. in the default skin.xml then a warning along the lines of "this skin is out of date- proceeding with skin may cause xbmc to crash- in case of crash please delete xbmc game save"
if as will be the current case the skin version is not there then also produce the warning
just my opinion- maybe this is too much work for you guys
i was thinking along the lines of a seperate version number just for skin compatibility.
something that is hardcoded into the application so that it is included with every build.
in mozilla firefox the required extension version is set as a hidden preference.
"pref("app.extensions.version", "0.9");"
the default value of that setting is changed when necessary.
perhaps it could be implemented in a similiar way?
or would the user have to delete the settings.xml file in the tdata folder for the new default setting to take effect? :hmm:
anyways... just an idea.
there is probably an easier (better) way to implement it in xbmc.
i realy do not know if this works or if it even can be done:
update the xbmctex.exe source to include a date macro of some sort that can be reported to the settings screen (as done by xbmc to the mplayer.dll)
hope this made some sense as i am rather tired when i write this.
jmarshall
2004-08-25, 13:22
nimbles: i do like that idea, but it does rely on the default skin being present, which, although is probably true in 99.999% of cases, is not actually a prerequisite for xbmc running (though to run without it on first install requires some fiddling which no one would ever bother with).
i think it's probably the best plan, i've heard of so far, as it poses no limitations on the actual build version/date of xbmc. another option is to automate the build version/date in xbmc - this needs to be done anyway. then the skin could simply keep a last updated date which would tie it to the build date. this relies, ofcourse, on whoever makes a build to have the date correct on their computers, but that is highly likely to happen anyway.
any other suggestions/comments?
Gamester17
2004-08-25, 15:00
fyi, maybe off-topic but i think this suggestion/thread is closly related to this other request for "auto-download of gui skins (link) (http://www.xboxmediaplayer.de/cgi-bin/forums/ikonboard.pl?act=st;f=4;t=1636)".
maybe other devs should consider bringing that idea back to life since frodo is obviouly not doing it and got no code from avalaunch?
since the build number doesn't change (not sure why this is, if you add new features and or fix bugs, then it should get a new version number, even if it's just a minor number update. just imho), maybe you could code the date on which it was pulled form cvs? not sure if this is even possible, just trying to come up with something to fix these skinning issues.
Hullebulle
2004-09-04, 21:23
since the build number doesn't change (not sure why this is, if you add new features and or fix bugs, then it should get a new version number, even if it's just a minor number update. just imho), maybe you could code the date on which it was pulled form cvs? not sure if this is even possible, just trying to come up with something to fix these skinning issues.
the version shown on the info screen is just a textstring in the enlish strings.xml. ofcourse you can change it before you do a build (or even after), but since we don't rlease any builds we can't take care of it.
btw we add the date to the info screen on build since a few days.
wabidwoveren
2004-09-05, 21:28
a simple <date> string in skin.xml would say what date the skin was released.
then tell xbmc to ignore any skin created before a certain date, or gray it out. this way xbmc is doing the calculation, and the last working skin date would be hard coded into the xbe. this also overcomes the problem of version numbers. every time a skin change is made that breaks, or freezes the xbox, the source code us updated to not allow skins made after that date. xbmc would also benefit from an override button (maybe hidden in settings.xml), or just let the user modify skin.xml.
so far everyone seems to be saying grab the version from xbmc, but all xbmc needs is a "best used if created after" filter.
why not only use a skincompability version number?
every time something is done that relates to the skin. (maybe adding or removing features that might be of importance to the skinning comunity) someone (projectmanager) writes it down in a well documented maner. in that way it will be very clear if the skin you want to use will work. and it will help those who makes the skin.
but it all depends on the source beeing well documented.
i think it's a great idea. ( and it's not very often the interface to the skin changes, does it?)