forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: multiple skin descriptors, skin versions
Date Tue, 03 Feb 2004 16:37:59 GMT
Dave Brondsema wrote:
...
> So each skin needs to declare what version it is and what versions of
> forrest it is compatible with.  We could put this in the skins.xml
> along with the other info (url, name, etc) of the skin.  However, the
> version info needs to be self-contained in the skin and remain in a file
> on the local installation of forrest.  skins.xml files are temporary on
> local installations.

IIRC I had added a filename convention too, so a skin would be for example:

  skinname-f0.5-0.3.jar (version 0.3 compatible with forrest 0.5)

But I still don't see why I would want an "old" skin for my Forrest (IE 
why get skinname-f0.5-0.2.jar if skinname-f0.5-0.3.jar is available?)

> So I propose a skin.xml definition file to be in the base directory of
> each skin.  It would contain the <skin> content from skinconf.xml in
> addition to version information.  Skins.xml would just references these
> files (they would have to be available outside the .zip also for easy
> fetching).

Hmmm... a bit complicated for what we will be dealing with, that is some 
skins. My skins webpage idea is something like this:

   http://texturizer.net/firebird/themes/

I don't think we will be getting more skins than Mozilla ;-)

ATM the skin fetching, as you know, works by getting the skin that is 
compatible with current Forrest (or at least it should be), by searching 
for the filename that has the same number in the name.

As Marshall has shown, the Forrest version is not a true indicator of 
the skin contract version.

On the other hand, I really don't see why one would want to download an 
older version of a skin that works with his Forrest. (Note that if the 
skin becomes different, it should change name, which BTW can also 
contain numbers).

So, in the sake of simplicity, and following what happens with Mozilla 
skins, I propose that we define a skin version, and that this scheme is 
applied to the filenames of the skins just as it happens for Mozilla.

To be able to update a skin, what I propose is to make the skin 
downloader add in the local unpacked skin the publish date if the skin 
on the site: in this way, in subsequent checks it can easily see if the 
skin has changed, and propose an update.

WDYT?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message