Rockbox mail archiveSubject: Re: Plan for skin changeover?
Re: Plan for skin changeover?
From: Dominik Riebeling <dominik.riebeling_at_gmail.com>
Date: Wed, 2 Jun 2010 22:07:34 +0200
On Tue, Jun 1, 2010 at 1:03 PM, Jonathan Gordon <jdgordy_at_gmail.com> wrote:
> access?) I want to copy the current theme site and disable updates.
> The reason to do this is because there is a script in
> utils/skinupdater which (should) extract a given zip file, run the
> update program over it and zip it back up so the entire theme site can
> get updated in one hit. But if that happens no themes will work for
> 3.6... so for a while it would great if we hosted 2 copies of the
> theme site....
So why make the theme site read only? IMO this is a good chance to add
syntax version handling for themes. Basically, I'm thinking of
something like this:
- add a theme syntax version number to the build-info files retrieved
by Rockbox Utility (and / or to rockbox-info.txt)
- modify Rockbox Utility to send this version number to t.r.o when
requesting the list of themes.
- make t.r.o respect that version and return a different list of
themes (and adjusted download locations). Depending on the checkwps
results the version number could even get figured automatically during
upload. checkwps would need to be able telling about the syntax
version its checking against, but adding this functionality should be
I see several advantages with this:
- when the next incompatible change to the syntax comes up we only
need to increment the version number. We had such changes a few times
in the past already, especially when the parser became stricter
(though that wasn't exactly tag changes).
- we have proper handling for themes with different syntax. IMO this
is much better than some workaround solution just for the current case
(especially from a view of a tool that gets distributed). Besides,
currently Rockbox Utility doesn't care about compatibility of themes.
So if a theme runs with the current build but not the latest release
Rockbox Utility won't notice the user about it and even install that
theme, even if the installation is the latest release. This is
something that needs to get fixed anyway. Instead of fiddling around
with revision numbers a version number looks like a simple solution to
- people can still access old themes (is there a reason to drop them?
Disk space shouldn't be an issue I guess?). This also leaves the door
open for people to pick up old themes and port them to the new syntax
(obviously only an issue if there is no update tool). Or have themes
around if they decide to run an older version of Rockbox for whatever
- eventually a tag could get introduced that holds the theme file
version, so there would be a way for Rockbox itself to have a
user-friendly notification of the user if a theme is incompatible.
The drawback I see is that it is some work to do. But some work has to
get done anyway :)
Received on 2010-06-02