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
