forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Lanselle <lanselle.als...@evc.net>
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 forrest.build 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 forrest.build.xml 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 
forrest.build.xml.  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 forrest.build.xml 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
        <elseif>
            <equals arg1="${project.skin}" arg2="krysalis-site"/>
            <then>
                <property name="project.new-skin-name" value="pelt"/>
            </then>
        </elseif>
        -->

>> 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.

Maurice

Mime
View raw message