Re: How to Try Currently Useable Skins?

[Ross Gardler <rg...@apache.org>]

[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