forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Lanselle <>
Subject Re: How to Try Currently Useable Skins?
Date Fri, 27 May 2005 09:53:51 GMT
Ross Gardler said the following on 26/05/2005 22:07:

Thank you for taking the time to address my questions, I'm sure you have 
plenty else to do.

> Yes, this is true, we welcome patches for improvements once you 
> understand things. Right now I'll try and help you get through the 
> inadequate docs.

I will gladly contribute to the documentation once I understand things.

>> 2) Customize the colors of the chosen skin.
>> This is not as simple or successful as I expected.  There seems to be 
>> inconsistent information on what skins are currently useable, and 
>> also the inclusion of their color tags in skinconf.xml.
>> a) The "available-skins" command gives out-of-date information : 
>> "crust, pelt, tigris"
> We only actively support pelt. All other skins are either in 
> development or deprecated, although some are still usable (you can 
> find out what they are by looking in the skins directory of the 
> distribution).

Checking my Forrest.home, I see my /context/skins/ has "common", 
"krysalis-site", "forrest-site", "leather-dev" as well as "pelt", 
"plain-dev", and "tigris"; it is which prevents access to 
them.  Why not just remove them from the distribution?

Pelt is clean and effective, I just wonder how different a Forrest site 
can look-and-feel.  As I've done with my (local) wiki and blog and, to a 
lesser extent, with spip.  I'm a bit disoriented with Forrest because I 
don't understand the code (more comfortable with php), but that will pass.

> You comment above indicates that the list provided by availabl-skins 
> is out of date, please raise an issue for us so we can remember to fix 
> it for the upcoming 0.7 release.
Okay, I'll add the issue.  I guess I expected the command to scan the 
souce of skins (much as can do using   <property 
name="forrest.skins-dir"   location="${forrest.home}/context/skins"/>  ) 
to see what is available (the approach many apps use for cataloguing 
available plug-ins) rather than consult a stored list which requires 
maintenance.  Ideally, each skin would have a file (rdf ?) in the spirit 
of .htaccess or .cvsignore which would enable forrest to know the status 
and facilitate the aliasing that is currently handled in  I believe that skins should, like plugins, be 
expected to conform to certain standards, but need not be developed by 
the Forrest project; to manage them by name in seems 
to me to add an unnecessary centralisation of skin administration by 
making it the build file maintainer's job rather than the skin 
maintainer's.  But I certainly don't claim that there are not good 
reasons for it being the way it is.

>> b) When I asked for "crust" (no longer exists), the handler chooses a 
>> deprecated skin : "krysalis-site" , which in turn provokes a warning 
>> and a recommendation to use "pelt".
> It should default to pelt, please add an issue about this too.
Okay, will do.  It appears the that it was planned for  "krysalis-site" 
to default to "pelt" eventually, but that is commented out:

        <!-- temporarily bring back krysalis-site
            <equals arg1="${}" arg2="krysalis-site"/>
                <property name="" value="pelt"/>

>> c) skinconf.xml has color tags for "krysalis", "Forrest", 
>> "Collabnet", "Lenya using pelt", but these are all either deprecated 
>> or not mentioned in the available and defaults lists. So how would I 
>> change the colors for, say, tigris (which does work for me)? How 
>> could I (easily) obtain the color tags to use the correct names and 
>> know the initial settings?
> The sections in skinconf do not relate to a specific skin. They are 
> used to create the CSS. The included sections are provided as examples.

I think Tim Williams's annotation for skinconf would have helped me, and 
it is a welcome addition.

> If you want to experiment with the colours for tigris (for example) 
> simple look at the class names you want to affect and add an 
> appropriate entry to skinconf.

Will do, thanks.

On the other hand, are there constraints on the ids assigned to blocks 
by the document2html.xsl files? Or can a skin use whatever class 
identifiers it wants as long as  the  outer wrapper on the content is a 
<div class='content'> to make site2xhtml happy? I don't have a real need 
for this flexibility today, but take the example of a table with varying 
row background colors...then this skin would need "table-cell-even" and 
"table-cell-odd" instead of "table-cell" .  Conclusion: a skin author 
should provide a list of all targets for colors and their standard 
values to enable the site designer to manage adjustments.

> Oooopa, this is a result of us being in the middle of preparing for 
> the 0.7 release (which is currently development).
Yes, I know you are finalizing 0.7, and look forward trying it soon; I 
hope my questions and remarks didn't eat too much of your time. I'll go 
post my issues now.


View raw message