You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Maurice Lanselle <la...@evc.net> on 2005/05/26 12:57:30 UTC
How to Try Currently Useable Skins?
I am learning to use Forrest v0.6. I am very confused by the
information on changing skins and skin properties, and I think there may
be issues. I would like to simply:
1) Try the available skins, to see how they look and how they vary so I
can choose my favorite.
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"
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".
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?
Regards,
Maurice
Docs I consulted :
- In the doc at
http://forrest.apache.org/docs/your-project.html#skin-configuration it
says to "edit the forrest.properties file to set
project.skin=leather-dev or some other skin name." and provides a link to
- a list of default skins [http://forrest.apache.org/docs/skins.html]:
pelt, leather-dev, tigris, and plain-dev. It says "krysalis-site" and
"forrest-site" are old and deprecated.
- On the page Skin packages
[http://forrest.apache.org/docs/skin-package.html], it says "To see the
names of the remote skins: forrest available-skins".
P.S
Also confusing for me, at [http://forrest.apache.org/0.7/docs.html] in
the body it lists
0.6 - the current release
0.7 - the current development version
but in the menu under "Other>Overview" it lists
- 0.8-dev
- 0.7 (current)
- 0.6
Re: How to Try Currently Useable Skins?
Posted by Tim Williams <wi...@gmail.com>.
Will the following not do what you want?
$> forrest site -Dproject.skin=krysalis-site
You'd have to rename the directory after each build if you wanted to
compare side by side. I couldn't find a property to change the
build-directory on the command line but I don't doubt that it exists
too.
As for your number 2, skinconf.xml will allow you to customize most things.
--tim
On 5/26/05, The Web Maestro <th...@gmail.com> wrote:
>
> On May 26, 2005, at 3:57 AM, Maurice Lanselle wrote:
>
> > I am learning to use Forrest v0.6. I am very confused by the
> > information on changing skins and skin properties, and I think there
> > may be issues. I would like to simply:
> > 1) Try the available skins, to see how they look and how they vary so
> > I can choose my favorite.
> > 2) Customize the colors of the chosen skin.
>
> I would second this. It would be nice to have the ability to generate
> output for each type of skin, so they can be compared. This could be
> done using the seed, or alternately using someone's forrest generated
> site. They could output like this:
>
> build/site_crust/
> build/site_pelt/
> build/site_leather/
>
> etc.
>
> Regards,
>
> Web Maestro Clay
> --
> <th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
> My religion is simple. My religion is kindness.
> - HH The 14th Dalai Lama of Tibet
>
>
Re: How to Try Currently Useable Skins?
Posted by The Web Maestro <th...@gmail.com>.
On May 26, 2005, at 3:57 AM, Maurice Lanselle wrote:
> I am learning to use Forrest v0.6. I am very confused by the
> information on changing skins and skin properties, and I think there
> may be issues. I would like to simply:
> 1) Try the available skins, to see how they look and how they vary so
> I can choose my favorite.
> 2) Customize the colors of the chosen skin.
I would second this. It would be nice to have the ability to generate
output for each type of skin, so they can be compared. This could be
done using the seed, or alternately using someone's forrest generated
site. They could output like this:
build/site_crust/
build/site_pelt/
build/site_leather/
etc.
Regards,
Web Maestro Clay
--
<th...@gmail.com> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet
Re: How to Try Currently Useable Skins?
Posted by 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
Re: How to Try Currently Useable Skins?
Posted by 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
Re: How to Try Currently Useable Skins?
Posted by Maurice Lanselle <la...@evc.net>.
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
Re: How to Try Currently Useable Skins?
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> > 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.
> >
> > 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.
>
> Is the following technically accurate as a proposed comment update for
> skinconf.xml? I also moved the "Forrest" section of colors to the top
> of the block because having a "named" skin at the top was initially
> misleading to me. Anyway, just a thought.
> --tim
Good suggestion Tim. I just added some comments based on your words.
--David
Re: How to Try Currently Useable Skins?
Posted by Tim Williams <wi...@gmail.com>.
> 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.
>
> 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.
Is the following technically accurate as a proposed comment update for
skinconf.xml? I also moved the "Forrest" section of colors to the top
of the block because having a "named" skin at the top was initially
misleading to me. Anyway, just a thought.
--tim
...
<colors>
<!--
These values are used for the generated CSS files. They
essentially "override" the colors defined in your project's skin.
There are four duplicate "sections" of colors below denoted by
comments: Forrest, Krysalis, Collabnet, and Lenya using Pelt. They
are
provided for example only. To customize the colors of any skin
you choose simply uncomment the color element relating to the class
you want to override in the skin and change the appropriate values.
<!-- Forrest -->
<!--
<color name="header" value="#294563"/>
...
Re: How to Try Currently Useable Skins?
Posted by Ross Gardler <rg...@apache.org>.
Maurice Lanselle wrote:
> I am learning to use Forrest v0.6. I am very confused by the
> information on changing skins and skin properties, and I think there may
> be issues.
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 would like to simply:
> 1) Try the available skins, to see how they look and how they vary so I
> can choose my favorite.
edit the forrest.properties file to set project.skin to the name of the
skin you want to use.
or
forrest site -Dproject.skin=SKINNAME
(as is correctly suggested later in this thread by Tim Williams)
> 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).
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.
> 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.
> 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.
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.
> Also confusing for me, at [http://forrest.apache.org/0.7/docs.html] in
> the body it lists
> 0.6 - the current release
> 0.7 - the current development version
>
> but in the menu under "Other>Overview" it lists
> - 0.8-dev
> - 0.7 (current)
> - 0.6
Oooopa, this is a result of us being in the middle of preparing for the
0.7 release (which is currently development).
Thanks for taking the time to highlight confusions with our docs. One of
the hardest things for us to do is write docs that are useful to the
newcomer. We have all been using Forrest for quite some time and don't
often have to think about these issues. Your feedback is important.
It would be really useful, both to the devs and to subsequent newbies if
you could provide a patch or suggested improvement to the docs as an
issue once you fully grasp what we try to explain here. We'll happilly
apply your improvements.
Ross