WARNING: skin format changing on the weekend!

[JdGordon]

After 3.6 is release I will be changing the skin syntax a bit which will make every single skin out there break!

I have updated checkwps to be able to update current skins to the new format (code in my git repo... http://github.com/jdgordon/rockbox skinbreak branch) but other than that there has been no work to update skins.

If someone would like to volunteer to make a web frontend for checkwps to go on the theme site that would be very much appreciated.

http://www.rockbox.org/wiki/SkinBreakingChange outlines the changed tags, the major thing is ()'s are being used for parameterised tags now with comma being the seperator and | only seperating conditional options. (also not that the colours are being taken off the viewport tags and put into new tags).

[Yotto]

2 things:

1) I think I know enough php to write the code to handle the files, run the program on them, and modify as needed (unless the program outputs modified WPS code) but I don't know the front-end part. I'm not a developer but I do file manipulation as my job and do a fair bit of scripting in both dos batch and korn shell, and bash for my personal computer. Plus I maintain my own website which uses php. I've just never written a submit form wrapper around it. Also, I've never done anything with javascirpt, ruby, or any other web development tools.

So, with all those warnings I'm offering my help.

2) Would the site still offer the 3.6-compatible themes? I don't have plans on upgrading past 3.6 when it comes out.

[JdGordon]

(I deleted a bunch on off topic posts, I didnt think splitting was really appropriate, I can undelete them if asked)...

I've written a better update program and put it in svn (although it doesnt work 100% yet)... its in utils/skinupdater if anyone wants to try it (there is also a boiler plater perl script to update a full theme zip file).

I need someone who knows perl to fix that script though. My goal for it is to run it on every theme zip on the site and have that diff file emailed to the theme author.

Yotto: re 2), One thing we might do is clone the current site and make the clone read only which will work for the pre-break builds which includes 3.6

[audio-i]

One thing we might do is clone the current site and make the clone read only which will work for the pre-break builds which includes 3.6

Meaning the 3.6 compatible versions couldn't then be corrected/updated/etc?

Which theme versions would the Rockbox Utility be able to download?

[JdGordon]

it gets tricky... there is talk that a quick fix in rbutil to grab from the 3.6/cloned theme site if it is installing the 3.6 or earlier build. We need to wait for the weekend to see if that happens or not though (Both main rbutil guys are going to be at devcon iirc so it is possible.)

[atsakir]

Should we post 2 different versions of our themes to the themes site to support both 3.5.1 and svn builds that used the old syntax and current builds with the new syntax until the 3.6 release is out?

[csavery]

These skin files aren't very big. Why not just add a conditional tag into the format that allows loading either a new or old section according to loader version? Similar to an #ifdef directive. Then the converter could convert all skins in place and they would work for any version. This would make changes to the web site minimal and no need to manage duplicate skins.

Or maybe it's too late for this...

(To clarify - it could just be a comment line that the reader uses as a trigger for what to ignore in the file. eg. Older loaders ignore after #version X, new loaders ignore before #version X)

[JdGordon]

because the rockbox build can only load one format, leaving the parser for the old format would add a massive amount of dead code which we don't want.

The current scheme is going to be a copy of the current theme site for some time until rbutil and the themesite work nicely together to ask for thmes which worked before some revision.

Plan is still to do the changeover today.. waiting for the themesite to happen

[csavery]

There wouldn't be a need to leave the old parser in the code. The new parser would simply ignore code it doesn't read. Eventually the .wps files could all be trimmed to drop the old format codes.

Anyway, I guess there's no point in me commenting on this as it's already in progress. It just seems a little more planning into the new format could have aided a simpler transition with no sites changes or skin author interventions.

[JdGordon]

maybe I misunderstood...

Oh you want both formats in the one file? na that would be crazy :p

[Llorean]

Having both copies of the theme in the same file would be useless - the old parser would always reject them (since it rejects anything it doesn't know as an "invalid" tag). The only way this could work is if the old theme versions were updated to be forward compatible with ignoring the new theme version first, which would of course still break all prior builds anyway.

There's basically always going to be a point of time after which the new files won't work on older builds.

[csavery]

Only useless because not well designed to start with. Introducing a version tag (like "#>3") now would make transitions easy in the future. Comments can be used to make code backward compatible but any new parser would have to understand when it should read a comment as code. As a transition device it would work until the 99% of users are on the new version. Then comments could be removed automatically.

eg.

# this is old code only read by old parser
#<3 this special comment tells the new parser not to read this block
%Vl|blah blah|

#now some new code skipped by old parser but understood as a transition block by new parser
#>3
#%Vl(blah, blah)
# and so on
## double comments still really a comment
#>4 version greater than current parser so not read
# someday a batch process removes old code and cuts first # between #>3 and #>4

It just seems like adding an escape sequence understood by the new parser would bypass website issues and make the transition pretty transparent to most users. Adding version tags now would be useful for future updates and the comment escape hack wouldn't be needed once versions tags were standard.

[audio-i]

Since I don't see the reason for not adapting the simplest solution (from a user standpoint), I feel I'm looking at this in a very naive way, but anyway... why not just leave the current theme site as it is, modifying this:
The "normal" download would work for 3.6 compatible themes (i.e. the current versions). The current parser puts a "Works with current build", that would be changed for "Doesn't work with current build" and a link for downloading the converted version. If a theme is uploaded with the new syntax, it would work as it works currently (i.e "Works with current build" and no "Works with realease 3.6)

I don't know the statistics, but my guess is, the majority of users use the stable version when available for the target, so IMHO, things should be oriented accordingly. When the new syntax is in the stable version (3.7?), the current themesite scheme could be used again having only the new syntax compatible theme versions.

[csavery]

Here's a refinement on my suggestion above to make code changes simpler...

Old parser skips comments anyway - no change.
New parser understands two new comment escapes:

#>N
means skip if N > parser version - for future updates to avoid comment hacks
(could be generalized for < >= <= etc if desired)

#>-
means remove first # from following code
as a transition mode comment hack since we don't have a version tag now

Adding these two comment escapes would allow for old version compatibility and future version tags.
Then the converter app just converts old version code updated into a comment block in the new version file.

The beauty of this is nothing needs to be changed on the website at all.
Just run the converter on all .wps files and it's done.

If a user edits old version code then the converter can re-save it with comment added.
These files are typically only a few hundred bytes long so it's not like size is a concern and once an old version is finally deprecated the #>- block can be copied back in as normal code. In future only the version tag is needed to transition to new versions.

[Llorean]

Yes, but saying "it wasn't well designed in the first place" doesn't solve anything, it's still the case. Your solution won't solve this transition.

And to be honest, we generally like themes breaking when someone's using an outdated version of Rockbox - it's a good reminder that you should update from time to time. Major rewrites of the whole theme syntax are few and far between, but there doesn't really need to be a system in place for authors to ensure that their themes remain compatible with drastically outdated versions of Rockbox.