[This discussion has migrated to dev issues, I've cc'd the dev list and
subsequent replies will go there, if you want to follow along you need
to join the dev list]
Maurice Lanselle wrote:
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.
And so our time is well spent :-)
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?
This is a good question, if it is not possible to use them why are they
present. I will bring this up on the dev list.
Note that common is used by other skins and provides common behaviour
between them.
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.
Q. How different can it look?
A. Totally different, there are no limitations
Skins are a collection of XSL stylesheets that take the internal formats
and arrange the content within a plain XHTML file. Since everything is
controlled by XSL the way this XHTML file is organised is *completely*
under the control of the skin.
The XHTML produced by the XSL's is then styled using the CSS.
In otherwords layout is controlled by XSL, style by CSS.
Of course, you can do the layout in CSS as well if you so desire.
There are, theoretically, no limitations in the skinning process. In
fact, you need not produce HTML. For example, the FO stylesheets produce
Formatting Objects (from which we create PDF). If you use the Text
plugin you get plain text output. If you use the POD plugin you get
Plain Old Documentation format.
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.
The reason for the list is that there is a skin package system that
allows third parties to provide skins that are not a part of the Forrest
distribution. Forrest therefore cannot scan a directory to find the
skins since some of them can be hosted elsewhere.
> 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.
Yes, I agree. In fact the meta-data idea is something I have been
considering for the plugins framework.
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.
It *should* work the way you describe, like plugins. In fact when I
built the plugins infrastructure I copied the download and install
mechanism from the skins packaging mechanism.
If this has subsequently been broken then it needs to be fixed. Please
make this not in your issue (copy this discussion since you highlight
some key points). Unfortunately, the skin packaging system has not
really been used, therefore it doesn't get tested. I would like to see
it being utilised in the same way that plugins are, as you describe.
I think Tim Williams's annotation for skinconf would have helped me, and
it is a welcome addition.
Indeed it is a welcome addition, that is now in SVN thanks Tim (and
David for committing it).
On the other hand, are there constraints on the ids assigned to blocks
by the document2html.xsl files?
I am not aware of any constraints, although if you utilise the files in
common then you need to be careful not to overlap with that.
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?
site2xhtml is just another part of the skin, you only need to respect
the existing class names if you reuse existing code that has them.
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.
+1
Ross