Support and General Use > Theming and Appearance Customization

WARNING: skin format changing on the weekend!

<< < (3/13) > >>

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page