You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Addison Berry (JIRA)" <ji...@apache.org> on 2005/10/17 18:48:45 UTC
[jira] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
[ http://issues.apache.org/jira/browse/FOR-180?page=all ]
Addison Berry updated FOR-180:
------------------------------
Attachment: forrestbar.diff
forrestbar.xpi
forrestbar.xml.diff
This new extension will work with Mozilla 1.x and Firefox 0.9 - 1.5 versions. The .xpi file attached is the one built running the forrestbar target. I'm not sure how we get the .xpi file that is on the web site - if it is built or just put on the server in it's final form - so I included it here.
> Update forrestbar to be installablein Mozilla Firefox 0.9
> ---------------------------------------------------------
>
> Key: FOR-180
> URL: http://issues.apache.org/jira/browse/FOR-180
> Project: Forrest
> Type: Bug
> Components: Forrestbar
> Environment: Mozilla Firefox 0.9
> Reporter: Nicola Ken Barozzi
> Assignee: Nicola Ken Barozzi
> Priority: Minor
> Attachments: forrestbar.diff, forrestbar.xml.diff, forrestbar.xpi
>
> Firefox 0.9 will get a new extension install system, with which we must be compatible to be usable there. Being listed in the standard toolbars could be cool too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: alternate stylesheet switching in Forrest
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Thanks Thorsten for all your help. I have updated and done a seed-v2
all is good :) I will look at the contracts closer now I understand
the inline idea. Not seen v2 before so I was way off track.
Kevin
On Thu, 2005-10-27 at 17:15 +0200, Thorsten Scherler wrote:
> El jue, 27-10-2005 a las 15:41 +0100, Kevin escribió:
> > Thanks Thorsten more inline
> >
> > On Wed, 2005-10-26 at 23:57 +0200, Thorsten Scherler wrote:
> > > El mié, 26-10-2005 a las 18:20 +0100, Kevin escribió:
> > > > Thought I'd have another go at what I called "theme switching" but this
> > > > time with the pelt skin/view using corner images and doing things within
> > > > Forrest. No Perl script to (a) generate the stylesheets from data
> > > > structures and (b) use another Perl script to generate a library of sets
> > > > of corner images in different color themes. Each alternate stylesheet
> > > > needs it's own set of themed corner images.
> > > >
> > > > I was sucessful in using Forrest to solve the two parts of the problem
> > > > (a) & (b) above. They work independantly but not together. I have tried
> > > > but *failed* in this and understanding what I can do with Forrest.
> > > >
> > > > Here are my ideas so far:
> > > >
> > > > (a)
> > > > themeconfig.xml:
> > > > <themeconfig>
> > > > <themes>
> > > > <theme name="pelt.hot">
> > > > <color name="header" value="#294563"/>
> > > > <color name="tab-selected" value="#4a6d8c" link="#0F3660"
> > > > vlink="#0F3660" hlink="#000066"/>
> > > > ...
> > > > <!-- like skinconf but change ^^^^ to hot shades of red -->
> > > > </theme>
> > > > <theme name="pelt.cool">
> > > > <color name="header" value="#294563"/>
> > > > <color name="tab-selected" value="#00ff00" link="#0F3660"
> > > > vlink="#0F3660" hlink="#000066"/>
> > > > ...
> > > > <!-- like skinconf but change ^^^^ to cool shades of blue -->
> > > > </theme>
> > > > </themes>
> > > > </themeconfig>
> > > >
> > > > Requests in the form of **skin/view.theme.css ie:
> > > > skin/pelt.hot.css
> > > > skin/pelt.cool.css
> > > >
> > >
> > > Hmm, maybe I have a certain understanding of themes.
> > > A theme is a presentation layer that provides an aggregation of
> > > a) theme structure information (*.fv)
> > > b) theme style information (*.css & *.png|jpg|gif|...)
> > > c) theme functionality (*.js & *.ft)
> >
> > I agree with your point of view :)
> >
> > > What you describe is not actually theme but color-theme switching (b.).
> > > I added a branding-theme-profiler.ft which is doing this, but you cannot
> > > yet switch the colors dynamically (via jscript which is switching b.).
> > > You can do the exact thing you describe above by adding it more then
> > > once. BTW it is in v2 but also can be used in v1.
> >
> > What stylesheet does branding-theme-profiler.ft dynamically create,
> > I guess profile.css?
>
> No, till now it produces the css inline. I am looking for a way that
> contracts are standalone. This way it would be possible to request a
> contract via url (see status mail).
>
> > > The important property to define which theme the color belong to is
> > > <forrest:property
> > > name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> > >
> > > Your example in a structurer definition:
> > > <forrest:contract name="branding-theme-profiler">
> > > <forrest:properties contract="branding-theme-profiler">
> > > <forrest:property
> > > name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> > > <forrest:property name="branding-theme-profiler">
> > > <color name="header" value="#ff0000"/>
> > > <!-- more colors -->
> > > </forrest:property>
> > > </forrest:properties>
> > > </forrest:contract>
> > > <forrest:contract name="branding-theme-profiler">
> > > <forrest:properties contract="branding-theme-profiler">
> > > <forrest:property
> > > name="branding-theme-profiler-theme">pelt.cool</forrest:property>
> > > <forrest:property name="branding-theme-profiler">
> > > <color name="header" value="#00ff00"/>
> > > <!-- more colors -->
> > > </forrest:property>
> > > </forrest:properties>
> > > </forrest:contract>
> >
> > In forrest.properties:
> > project.theme=pelt.hot
> >
> > So I need a pelt.hot.fv file? Every instance of (b) "theme style"
> > will require a different view?
>
> no
>
> >
> > Perhaps?
> >
> > project.theme=pelt
> > project.theme.style=pelt.hot
> > project.theme-extension=.fv
> >
> > And use project.theme.style
> > <forrest:property
> > name="branding-theme-profiler-theme-style">pelt.hot</forrest:property>
> >
> > I'm making a bad guess?
>
> Hmm, I think I do not understand.
>
> The branding-theme-profiler.ft is adding inline e.g.
> <style title="Pelt" media="screen" type="text/css" rel="alternate
> stylesheet">
> #page .breadtrail {
> background: #cedfef;
> color: #0F3660;
> }
> //...
> </style>
>
> when used like
> <forrest:contract name="branding-theme-profiler">
> <forrest:properties contract="branding-theme-profiler">
> <forrest:property
> name="branding-theme-profiler-theme">pelt</forrest:property>
> ...
>
> It is independent from any value in forrest.properties. It is controlled
> by the pelt.fv. If you use the contract more then once in the pelt.fv
> then you can add colors themes like you want.
>
> > > A "real" theme switcher would change a/b/c. The browser based solution
> > > described in the other mail is *not* doing this either (it is switching
> > > only b as well).
> > >
> > > A "real" color-theme switcher should also provide a possibility to
> > > change each color with a WEB-GUI.
> >
> > Yes I understand what you say.
>
> That is right now a wish list. ;-)
>
> >
> > > > will be matched in resouces.xmap [1] and call template
> > > > 'view.theme.css.xslt' with a theme parameter ie: theme =
> > > > 'pelt.hot' or 'pelt.cool' and the style sheets will
> > > > be generated.
> > > >
> > > > view.theme.css.xslt is like profile.css.xslt but using
> > > > themeconfig.xml data and dealing with corner images.
> > >
> > > Why is this a file for its own and not a contract? Why are you not using
> > > the branding-theme-profiler.ft?
> >
> > view.theme.css.xslt generates all stylesheets based on all available
> > instances of (b) "theme style" ie: 'pelt.hot', pelt.cool ... pelt.common
> > (default). Now I think you mean these are called views?
> >
> > My pelt.fv:
> > <forrest:css url="pelt.common.css" media="screen" rel="stylesheet"
> > type="text/css"/>
> > <forrest:css url="pelt.hot.css" media="screen" rel="alternate
> > stylesheet" type="text/css" title="pelt.hot"/>
> > <forrest:css url="pelt.cool.css" media="screen" rel="alternate
> > stylesheet" type="text/css" title="pelt.cool"/>
> >
> > I can see branding-theme-profiler.ft provides the same information
> > as my themeconfig.xml idea. But what does it do with colors, create
> > profile.css as before and user would have to:
> >
> > pelt.hot.fv:
> > <forrest:css url="pelt.basic.css" media="screen" title="Pelt"/>
> > <forrest:css url="pelt.screen.css" media="screen" title="Pelt"/>
> > <forrest:css url="profile.css" media="screen" title="Pelt"/>
>
> No, please see
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themer/resources/themes/pelt.fv?rev=328340&view=markup
>
> > > > (b)
> > > > As each alternate stylesheet uses a differnet set of colors
> > > > matching a url in all style sheets of the form
> > > >
> > > > #header .round-top-left-small {
> > > > background: url(images/rc-t-l-5-1header-2searchbox-3searchbox.png) 0 0
> > > > no-repeat}
> > > >
> > > > won't work as header/searchbox will need to come from a different
> > > > color theme in each style sheet
> > >
> > > It depends with the current implementation you are certainly right, but
> > > we need to change that in v2. It has to be possible to generate this via
> > > a contract.
> > >
> > > > So 'view.theme.css.xslt' inserts the hex color values from
> > > > themeconfig.xml rather than names ie:
> > > >
> > > > #header .round-top-left-small {
> > > > background: url(images/rc-t-l-5-X294563-X4a6d8c-X4a6d8c.png) 0 0 no-
> > > > repeat;}
> > > >
> > > > Requests in the form skin/images**/*c-*-*-*-X*-X*-X*.png
> > > > will be matched in resources.xmap [2] and call 'rcX.svg.xslt'
> > > > etc. modified to use hex values.
> > >
> > > ok. That is maybe the part that I was missing. :) By passing the hex
> > > values it would be *a lot* more flexible and could be used in different
> > > color-themes. Nice.
> > >
> > > > Problem
> > > > =======
> > > >
> > > > Run "forrest site" and the link crawler matches the style sheet
> > > > requests in the view file
> > > > pelt.hot.css
> > > > pelt.cool.css
> > > > and they are generated correctly. Game Over :(
> > > >
> > > > Doh! I was expecting the link crawler to then parse the url corner
> > > > image requests and generated the png from svg as normal.
> > >
> > > > I can't understand this. If a static css file is requested it goes
> > > > through pipelines and serialized and the corner image links are
> > > > crawled and generated? Why can't I do this with a generated css?
> > >
> > > Hmm, maybe it is because the css is resulting from a xsl-transformation
> > > and only visible in the build/ and not in the src/ ¿?
> >
> > Could you say more on this. How to get xsl-transformation visible under
> > src tree?
>
> I do not know the crawler too much, sorry. Maybe someone else can speak
> up on that.
>
> > Using the existing system moving corner image from
> > pelt.screen.css:
> >
> > /*background: url("images/tab-left.gif") no-repeat left top;*/
> > #nav-main li a {
> > float: left;
> > ...
> > background-image: url(images/rc-t-l-5-1header-2tab-unselected-3tab-
> > unselected.png);
> > ...
> > }
> >
> > to template profile.css.xslt or what new branding-theme-profiler.ft uses
> > would show the problem. No need to use the hex version as it is a static
> > color choice view. So profile.css should be generated plus the tab-left
> > png.
>
> see
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themer/resources/themes/pelt/html/branding-theme-profiler.ft?view=markup
>
> we do not use any profile.css.xslt anymore that is within the contract.
> Due to this fact the transformation is done and the resulting css get
> injected inline. This inline css is available for the bot while crawling
> (but I actually have not test this yet). To the hex problematic I am
> afraid that this special part of forrest is still married to the
> skinconf, which means it the color scheme of the skinconf would be
> taken. To overcome it we should use your suggestion of hex colors.
>
> > > > I must be missing something, can someone help here? Thanks.
> > >
> > > Why don't you use the branding-theme-profiler.ft in combination with the
> > > hex-svg-png. That would overcome the problem of build/src dir and crawl
> > > the pics.
> >
> > Not sure how to use it with corner images as above.
> >
> > I'll do a svn up and copy over the branding-theme-profiler.ft to v1.
> >
> > Not done an update for a while if there is a hole I fall down it :)
> >
> > Do views v1 work out the box with forrest.properties workaround:
> >
> > project.view.internal.plugin=org.apache.forrest.plugin.internal.view
> > project.theme.plugin=org.apache.forrest.plugin.internal.view
> >
> > Thanks
>
>
> Actually I would like to ask you to try v2 because David just solved the
> main problem of it. Now a static export is working again which was the
> reason AFAIR for you to stick with v1.
>
> Thx Kevin for your constant work and suggestions.
>
> salu2
Re: alternate stylesheet switching in Forrest
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Thorsten Scherler" <th...@apache.org>
To: <de...@forrest.apache.org>
Sent: Thursday, October 27, 2005 11:15 PM
Subject: Re: alternate stylesheet switching in Forrest
| > What stylesheet does branding-theme-profiler.ft dynamically create,
| > I guess profile.css?
|
| No, till now it produces the css inline. I am looking for a way that
| contracts are standalone. This way it would be possible to request a
| contract via url (see status mail).
Aha, that answers my other mail then, thanks.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005
--
This message was scanned for spam and viruses by BitDefender.
For more information please visit http://linux.bitdefender.com/
Re: alternate stylesheet switching in Forrest
Posted by Thorsten Scherler <th...@apache.org>.
El jue, 27-10-2005 a las 15:41 +0100, Kevin escribió:
> Thanks Thorsten more inline
>
> On Wed, 2005-10-26 at 23:57 +0200, Thorsten Scherler wrote:
> > El mié, 26-10-2005 a las 18:20 +0100, Kevin escribió:
> > > Thought I'd have another go at what I called "theme switching" but this
> > > time with the pelt skin/view using corner images and doing things within
> > > Forrest. No Perl script to (a) generate the stylesheets from data
> > > structures and (b) use another Perl script to generate a library of sets
> > > of corner images in different color themes. Each alternate stylesheet
> > > needs it's own set of themed corner images.
> > >
> > > I was sucessful in using Forrest to solve the two parts of the problem
> > > (a) & (b) above. They work independantly but not together. I have tried
> > > but *failed* in this and understanding what I can do with Forrest.
> > >
> > > Here are my ideas so far:
> > >
> > > (a)
> > > themeconfig.xml:
> > > <themeconfig>
> > > <themes>
> > > <theme name="pelt.hot">
> > > <color name="header" value="#294563"/>
> > > <color name="tab-selected" value="#4a6d8c" link="#0F3660"
> > > vlink="#0F3660" hlink="#000066"/>
> > > ...
> > > <!-- like skinconf but change ^^^^ to hot shades of red -->
> > > </theme>
> > > <theme name="pelt.cool">
> > > <color name="header" value="#294563"/>
> > > <color name="tab-selected" value="#00ff00" link="#0F3660"
> > > vlink="#0F3660" hlink="#000066"/>
> > > ...
> > > <!-- like skinconf but change ^^^^ to cool shades of blue -->
> > > </theme>
> > > </themes>
> > > </themeconfig>
> > >
> > > Requests in the form of **skin/view.theme.css ie:
> > > skin/pelt.hot.css
> > > skin/pelt.cool.css
> > >
> >
> > Hmm, maybe I have a certain understanding of themes.
> > A theme is a presentation layer that provides an aggregation of
> > a) theme structure information (*.fv)
> > b) theme style information (*.css & *.png|jpg|gif|...)
> > c) theme functionality (*.js & *.ft)
>
> I agree with your point of view :)
>
> > What you describe is not actually theme but color-theme switching (b.).
> > I added a branding-theme-profiler.ft which is doing this, but you cannot
> > yet switch the colors dynamically (via jscript which is switching b.).
> > You can do the exact thing you describe above by adding it more then
> > once. BTW it is in v2 but also can be used in v1.
>
> What stylesheet does branding-theme-profiler.ft dynamically create,
> I guess profile.css?
No, till now it produces the css inline. I am looking for a way that
contracts are standalone. This way it would be possible to request a
contract via url (see status mail).
> > The important property to define which theme the color belong to is
> > <forrest:property
> > name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> >
> > Your example in a structurer definition:
> > <forrest:contract name="branding-theme-profiler">
> > <forrest:properties contract="branding-theme-profiler">
> > <forrest:property
> > name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> > <forrest:property name="branding-theme-profiler">
> > <color name="header" value="#ff0000"/>
> > <!-- more colors -->
> > </forrest:property>
> > </forrest:properties>
> > </forrest:contract>
> > <forrest:contract name="branding-theme-profiler">
> > <forrest:properties contract="branding-theme-profiler">
> > <forrest:property
> > name="branding-theme-profiler-theme">pelt.cool</forrest:property>
> > <forrest:property name="branding-theme-profiler">
> > <color name="header" value="#00ff00"/>
> > <!-- more colors -->
> > </forrest:property>
> > </forrest:properties>
> > </forrest:contract>
>
> In forrest.properties:
> project.theme=pelt.hot
>
> So I need a pelt.hot.fv file? Every instance of (b) "theme style"
> will require a different view?
no
>
> Perhaps?
>
> project.theme=pelt
> project.theme.style=pelt.hot
> project.theme-extension=.fv
>
> And use project.theme.style
> <forrest:property
> name="branding-theme-profiler-theme-style">pelt.hot</forrest:property>
>
> I'm making a bad guess?
Hmm, I think I do not understand.
The branding-theme-profiler.ft is adding inline e.g.
<style title="Pelt" media="screen" type="text/css" rel="alternate
stylesheet">
#page .breadtrail {
background: #cedfef;
color: #0F3660;
}
//...
</style>
when used like
<forrest:contract name="branding-theme-profiler">
<forrest:properties contract="branding-theme-profiler">
<forrest:property
name="branding-theme-profiler-theme">pelt</forrest:property>
...
It is independent from any value in forrest.properties. It is controlled
by the pelt.fv. If you use the contract more then once in the pelt.fv
then you can add colors themes like you want.
> > A "real" theme switcher would change a/b/c. The browser based solution
> > described in the other mail is *not* doing this either (it is switching
> > only b as well).
> >
> > A "real" color-theme switcher should also provide a possibility to
> > change each color with a WEB-GUI.
>
> Yes I understand what you say.
That is right now a wish list. ;-)
>
> > > will be matched in resouces.xmap [1] and call template
> > > 'view.theme.css.xslt' with a theme parameter ie: theme =
> > > 'pelt.hot' or 'pelt.cool' and the style sheets will
> > > be generated.
> > >
> > > view.theme.css.xslt is like profile.css.xslt but using
> > > themeconfig.xml data and dealing with corner images.
> >
> > Why is this a file for its own and not a contract? Why are you not using
> > the branding-theme-profiler.ft?
>
> view.theme.css.xslt generates all stylesheets based on all available
> instances of (b) "theme style" ie: 'pelt.hot', pelt.cool ... pelt.common
> (default). Now I think you mean these are called views?
>
> My pelt.fv:
> <forrest:css url="pelt.common.css" media="screen" rel="stylesheet"
> type="text/css"/>
> <forrest:css url="pelt.hot.css" media="screen" rel="alternate
> stylesheet" type="text/css" title="pelt.hot"/>
> <forrest:css url="pelt.cool.css" media="screen" rel="alternate
> stylesheet" type="text/css" title="pelt.cool"/>
>
> I can see branding-theme-profiler.ft provides the same information
> as my themeconfig.xml idea. But what does it do with colors, create
> profile.css as before and user would have to:
>
> pelt.hot.fv:
> <forrest:css url="pelt.basic.css" media="screen" title="Pelt"/>
> <forrest:css url="pelt.screen.css" media="screen" title="Pelt"/>
> <forrest:css url="profile.css" media="screen" title="Pelt"/>
No, please see
http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themer/resources/themes/pelt.fv?rev=328340&view=markup
> > > (b)
> > > As each alternate stylesheet uses a differnet set of colors
> > > matching a url in all style sheets of the form
> > >
> > > #header .round-top-left-small {
> > > background: url(images/rc-t-l-5-1header-2searchbox-3searchbox.png) 0 0
> > > no-repeat}
> > >
> > > won't work as header/searchbox will need to come from a different
> > > color theme in each style sheet
> >
> > It depends with the current implementation you are certainly right, but
> > we need to change that in v2. It has to be possible to generate this via
> > a contract.
> >
> > > So 'view.theme.css.xslt' inserts the hex color values from
> > > themeconfig.xml rather than names ie:
> > >
> > > #header .round-top-left-small {
> > > background: url(images/rc-t-l-5-X294563-X4a6d8c-X4a6d8c.png) 0 0 no-
> > > repeat;}
> > >
> > > Requests in the form skin/images**/*c-*-*-*-X*-X*-X*.png
> > > will be matched in resources.xmap [2] and call 'rcX.svg.xslt'
> > > etc. modified to use hex values.
> >
> > ok. That is maybe the part that I was missing. :) By passing the hex
> > values it would be *a lot* more flexible and could be used in different
> > color-themes. Nice.
> >
> > > Problem
> > > =======
> > >
> > > Run "forrest site" and the link crawler matches the style sheet
> > > requests in the view file
> > > pelt.hot.css
> > > pelt.cool.css
> > > and they are generated correctly. Game Over :(
> > >
> > > Doh! I was expecting the link crawler to then parse the url corner
> > > image requests and generated the png from svg as normal.
> >
> > > I can't understand this. If a static css file is requested it goes
> > > through pipelines and serialized and the corner image links are
> > > crawled and generated? Why can't I do this with a generated css?
> >
> > Hmm, maybe it is because the css is resulting from a xsl-transformation
> > and only visible in the build/ and not in the src/ ¿?
>
> Could you say more on this. How to get xsl-transformation visible under
> src tree?
I do not know the crawler too much, sorry. Maybe someone else can speak
up on that.
> Using the existing system moving corner image from
> pelt.screen.css:
>
> /*background: url("images/tab-left.gif") no-repeat left top;*/
> #nav-main li a {
> float: left;
> ...
> background-image: url(images/rc-t-l-5-1header-2tab-unselected-3tab-
> unselected.png);
> ...
> }
>
> to template profile.css.xslt or what new branding-theme-profiler.ft uses
> would show the problem. No need to use the hex version as it is a static
> color choice view. So profile.css should be generated plus the tab-left
> png.
see
http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themer/resources/themes/pelt/html/branding-theme-profiler.ft?view=markup
we do not use any profile.css.xslt anymore that is within the contract.
Due to this fact the transformation is done and the resulting css get
injected inline. This inline css is available for the bot while crawling
(but I actually have not test this yet). To the hex problematic I am
afraid that this special part of forrest is still married to the
skinconf, which means it the color scheme of the skinconf would be
taken. To overcome it we should use your suggestion of hex colors.
> > > I must be missing something, can someone help here? Thanks.
> >
> > Why don't you use the branding-theme-profiler.ft in combination with the
> > hex-svg-png. That would overcome the problem of build/src dir and crawl
> > the pics.
>
> Not sure how to use it with corner images as above.
>
> I'll do a svn up and copy over the branding-theme-profiler.ft to v1.
>
> Not done an update for a while if there is a hole I fall down it :)
>
> Do views v1 work out the box with forrest.properties workaround:
>
> project.view.internal.plugin=org.apache.forrest.plugin.internal.view
> project.theme.plugin=org.apache.forrest.plugin.internal.view
>
> Thanks
Actually I would like to ask you to try v2 because David just solved the
main problem of it. Now a static export is working again which was the
reason AFAIR for you to stick with v1.
Thx Kevin for your constant work and suggestions.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: alternate stylesheet switching in Forrest
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Thanks Thorsten more inline
On Wed, 2005-10-26 at 23:57 +0200, Thorsten Scherler wrote:
> El mié, 26-10-2005 a las 18:20 +0100, Kevin escribió:
> > Thought I'd have another go at what I called "theme switching" but this
> > time with the pelt skin/view using corner images and doing things within
> > Forrest. No Perl script to (a) generate the stylesheets from data
> > structures and (b) use another Perl script to generate a library of sets
> > of corner images in different color themes. Each alternate stylesheet
> > needs it's own set of themed corner images.
> >
> > I was sucessful in using Forrest to solve the two parts of the problem
> > (a) & (b) above. They work independantly but not together. I have tried
> > but *failed* in this and understanding what I can do with Forrest.
> >
> > Here are my ideas so far:
> >
> > (a)
> > themeconfig.xml:
> > <themeconfig>
> > <themes>
> > <theme name="pelt.hot">
> > <color name="header" value="#294563"/>
> > <color name="tab-selected" value="#4a6d8c" link="#0F3660"
> > vlink="#0F3660" hlink="#000066"/>
> > ...
> > <!-- like skinconf but change ^^^^ to hot shades of red -->
> > </theme>
> > <theme name="pelt.cool">
> > <color name="header" value="#294563"/>
> > <color name="tab-selected" value="#00ff00" link="#0F3660"
> > vlink="#0F3660" hlink="#000066"/>
> > ...
> > <!-- like skinconf but change ^^^^ to cool shades of blue -->
> > </theme>
> > </themes>
> > </themeconfig>
> >
> > Requests in the form of **skin/view.theme.css ie:
> > skin/pelt.hot.css
> > skin/pelt.cool.css
> >
>
> Hmm, maybe I have a certain understanding of themes.
> A theme is a presentation layer that provides an aggregation of
> a) theme structure information (*.fv)
> b) theme style information (*.css & *.png|jpg|gif|...)
> c) theme functionality (*.js & *.ft)
I agree with your point of view :)
> What you describe is not actually theme but color-theme switching (b.).
> I added a branding-theme-profiler.ft which is doing this, but you cannot
> yet switch the colors dynamically (via jscript which is switching b.).
> You can do the exact thing you describe above by adding it more then
> once. BTW it is in v2 but also can be used in v1.
What stylesheet does branding-theme-profiler.ft dynamically create,
I guess profile.css?
> The important property to define which theme the color belong to is
> <forrest:property
> name="branding-theme-profiler-theme">pelt.hot</forrest:property>
>
> Your example in a structurer definition:
> <forrest:contract name="branding-theme-profiler">
> <forrest:properties contract="branding-theme-profiler">
> <forrest:property
> name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> <forrest:property name="branding-theme-profiler">
> <color name="header" value="#ff0000"/>
> <!-- more colors -->
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
> <forrest:contract name="branding-theme-profiler">
> <forrest:properties contract="branding-theme-profiler">
> <forrest:property
> name="branding-theme-profiler-theme">pelt.cool</forrest:property>
> <forrest:property name="branding-theme-profiler">
> <color name="header" value="#00ff00"/>
> <!-- more colors -->
> </forrest:property>
> </forrest:properties>
> </forrest:contract>
In forrest.properties:
project.theme=pelt.hot
So I need a pelt.hot.fv file? Every instance of (b) "theme style"
will require a different view?
Perhaps?
project.theme=pelt
project.theme.style=pelt.hot
project.theme-extension=.fv
And use project.theme.style
<forrest:property
name="branding-theme-profiler-theme-style">pelt.hot</forrest:property>
I'm making a bad guess?
> A "real" theme switcher would change a/b/c. The browser based solution
> described in the other mail is *not* doing this either (it is switching
> only b as well).
>
> A "real" color-theme switcher should also provide a possibility to
> change each color with a WEB-GUI.
Yes I understand what you say.
> > will be matched in resouces.xmap [1] and call template
> > 'view.theme.css.xslt' with a theme parameter ie: theme =
> > 'pelt.hot' or 'pelt.cool' and the style sheets will
> > be generated.
> >
> > view.theme.css.xslt is like profile.css.xslt but using
> > themeconfig.xml data and dealing with corner images.
>
> Why is this a file for its own and not a contract? Why are you not using
> the branding-theme-profiler.ft?
view.theme.css.xslt generates all stylesheets based on all available
instances of (b) "theme style" ie: 'pelt.hot', pelt.cool ... pelt.common
(default). Now I think you mean these are called views?
My pelt.fv:
<forrest:css url="pelt.common.css" media="screen" rel="stylesheet"
type="text/css"/>
<forrest:css url="pelt.hot.css" media="screen" rel="alternate
stylesheet" type="text/css" title="pelt.hot"/>
<forrest:css url="pelt.cool.css" media="screen" rel="alternate
stylesheet" type="text/css" title="pelt.cool"/>
I can see branding-theme-profiler.ft provides the same information
as my themeconfig.xml idea. But what does it do with colors, create
profile.css as before and user would have to:
pelt.hot.fv:
<forrest:css url="pelt.basic.css" media="screen" title="Pelt"/>
<forrest:css url="pelt.screen.css" media="screen" title="Pelt"/>
<forrest:css url="profile.css" media="screen" title="Pelt"/>
> > (b)
> > As each alternate stylesheet uses a differnet set of colors
> > matching a url in all style sheets of the form
> >
> > #header .round-top-left-small {
> > background: url(images/rc-t-l-5-1header-2searchbox-3searchbox.png) 0 0
> > no-repeat}
> >
> > won't work as header/searchbox will need to come from a different
> > color theme in each style sheet
>
> It depends with the current implementation you are certainly right, but
> we need to change that in v2. It has to be possible to generate this via
> a contract.
>
> > So 'view.theme.css.xslt' inserts the hex color values from
> > themeconfig.xml rather than names ie:
> >
> > #header .round-top-left-small {
> > background: url(images/rc-t-l-5-X294563-X4a6d8c-X4a6d8c.png) 0 0 no-
> > repeat;}
> >
> > Requests in the form skin/images**/*c-*-*-*-X*-X*-X*.png
> > will be matched in resources.xmap [2] and call 'rcX.svg.xslt'
> > etc. modified to use hex values.
>
> ok. That is maybe the part that I was missing. :) By passing the hex
> values it would be *a lot* more flexible and could be used in different
> color-themes. Nice.
>
> > Problem
> > =======
> >
> > Run "forrest site" and the link crawler matches the style sheet
> > requests in the view file
> > pelt.hot.css
> > pelt.cool.css
> > and they are generated correctly. Game Over :(
> >
> > Doh! I was expecting the link crawler to then parse the url corner
> > image requests and generated the png from svg as normal.
>
> > I can't understand this. If a static css file is requested it goes
> > through pipelines and serialized and the corner image links are
> > crawled and generated? Why can't I do this with a generated css?
>
> Hmm, maybe it is because the css is resulting from a xsl-transformation
> and only visible in the build/ and not in the src/ ¿?
Could you say more on this. How to get xsl-transformation visible under
src tree? Using the existing system moving corner image from
pelt.screen.css:
/*background: url("images/tab-left.gif") no-repeat left top;*/
#nav-main li a {
float: left;
...
background-image: url(images/rc-t-l-5-1header-2tab-unselected-3tab-
unselected.png);
...
}
to template profile.css.xslt or what new branding-theme-profiler.ft uses
would show the problem. No need to use the hex version as it is a static
color choice view. So profile.css should be generated plus the tab-left
png.
> > I must be missing something, can someone help here? Thanks.
>
> Why don't you use the branding-theme-profiler.ft in combination with the
> hex-svg-png. That would overcome the problem of build/src dir and crawl
> the pics.
Not sure how to use it with corner images as above.
I'll do a svn up and copy over the branding-theme-profiler.ft to v1.
Not done an update for a while if there is a hole I fall down it :)
Do views v1 work out the box with forrest.properties workaround:
project.view.internal.plugin=org.apache.forrest.plugin.internal.view
project.theme.plugin=org.apache.forrest.plugin.internal.view
Thanks
Kevin
> > Kevin
> >
> > -------
> >
> > Well all is not lost I could run forrest site twice :(
> > a) forrest site to generate the css files
> > b) copy them from build/site/skin to src/documentation/skins/css/
> > c) forrest site to generate the corner images
>
> That fuels above guess.
>
> salu2
Re: alternate stylesheet switching in Forrest
Posted by Thorsten Scherler <th...@apache.org>.
El mié, 26-10-2005 a las 18:20 +0100, Kevin escribió:
> Thought I'd have another go at what I called "theme switching" but this
> time with the pelt skin/view using corner images and doing things within
> Forrest. No Perl script to (a) generate the stylesheets from data
> structures and (b) use another Perl script to generate a library of sets
> of corner images in different color themes. Each alternate stylesheet
> needs it's own set of themed corner images.
>
> I was sucessful in using Forrest to solve the two parts of the problem
> (a) & (b) above. They work independantly but not together. I have tried
> but *failed* in this and understanding what I can do with Forrest.
>
> Here are my ideas so far:
>
> (a)
> themeconfig.xml:
> <themeconfig>
> <themes>
> <theme name="pelt.hot">
> <color name="header" value="#294563"/>
> <color name="tab-selected" value="#4a6d8c" link="#0F3660"
> vlink="#0F3660" hlink="#000066"/>
> ...
> <!-- like skinconf but change ^^^^ to hot shades of red -->
> </theme>
> <theme name="pelt.cool">
> <color name="header" value="#294563"/>
> <color name="tab-selected" value="#00ff00" link="#0F3660"
> vlink="#0F3660" hlink="#000066"/>
> ...
> <!-- like skinconf but change ^^^^ to cool shades of blue -->
> </theme>
> </themes>
> </themeconfig>
>
> Requests in the form of **skin/view.theme.css ie:
> skin/pelt.hot.css
> skin/pelt.cool.css
>
Hmm, maybe I have a certain understanding of themes.
A theme is a presentation layer that provides an aggregation of
a) theme structure information (*.fv)
b) theme style information (*.css & *.png|jpg|gif|...)
c) theme functionality (*.js & *.ft)
What you describe is not actually theme but color-theme switching (b.).
I added a branding-theme-profiler.ft which is doing this, but you cannot
yet switch the colors dynamically (via jscript which is switching b.).
You can do the exact thing you describe above by adding it more then
once. BTW it is in v2 but also can be used in v1.
The important property to define which theme the color belong to is
<forrest:property
name="branding-theme-profiler-theme">pelt.hot</forrest:property>
Your example in a structurer definition:
<forrest:contract name="branding-theme-profiler">
<forrest:properties contract="branding-theme-profiler">
<forrest:property
name="branding-theme-profiler-theme">pelt.hot</forrest:property>
<forrest:property name="branding-theme-profiler">
<color name="header" value="#ff0000"/>
<!-- more colors -->
</forrest:property>
</forrest:properties>
</forrest:contract>
<forrest:contract name="branding-theme-profiler">
<forrest:properties contract="branding-theme-profiler">
<forrest:property
name="branding-theme-profiler-theme">pelt.cool</forrest:property>
<forrest:property name="branding-theme-profiler">
<color name="header" value="#00ff00"/>
<!-- more colors -->
</forrest:property>
</forrest:properties>
</forrest:contract>
A "real" theme switcher would change a/b/c. The browser based solution
described in the other mail is *not* doing this either (it is switching
only b as well).
A "real" color-theme switcher should also provide a possibility to
change each color with a WEB-GUI.
> will be matched in resouces.xmap [1] and call template
> 'view.theme.css.xslt' with a theme parameter ie: theme =
> 'pelt.hot' or 'pelt.cool' and the style sheets will
> be generated.
>
> view.theme.css.xslt is like profile.css.xslt but using
> themeconfig.xml data and dealing with corner images.
Why is this a file for its own and not a contract? Why are you not using
the branding-theme-profiler.ft?
> (b)
> As each alternate stylesheet uses a differnet set of colors
> matching a url in all style sheets of the form
>
> #header .round-top-left-small {
> background: url(images/rc-t-l-5-1header-2searchbox-3searchbox.png) 0 0
> no-repeat}
>
> won't work as header/searchbox will need to come from a different
> color theme in each style sheet
It depends with the current implementation you are certainly right, but
we need to change that in v2. It has to be possible to generate this via
a contract.
> So 'view.theme.css.xslt' inserts the hex color values from
> themeconfig.xml rather than names ie:
>
> #header .round-top-left-small {
> background: url(images/rc-t-l-5-X294563-X4a6d8c-X4a6d8c.png) 0 0 no-
> repeat;}
>
> Requests in the form skin/images**/*c-*-*-*-X*-X*-X*.png
> will be matched in resources.xmap [2] and call 'rcX.svg.xslt'
> etc. modified to use hex values.
ok. That is maybe the part that I was missing. :) By passing the hex
values it would be *a lot* more flexible and could be used in different
color-themes. Nice.
> Problem
> =======
>
> Run "forrest site" and the link crawler matches the style sheet
> requests in the view file
> pelt.hot.css
> pelt.cool.css
> and they are generated correctly. Game Over :(
>
> Doh! I was expecting the link crawler to then parse the url corner
> image requests and generated the png from svg as normal.
> I can't understand this. If a static css file is requested it goes
> through pipelines and serialized and the corner image links are
> crawled and generated? Why can't I do this with a generated css?
Hmm, maybe it is because the css is resulting from a xsl-transformation
and only visible in the build/ and not in the src/ ¿?
> I must be missing something, can someone help here? Thanks.
Why don't you use the branding-theme-profiler.ft in combination with the
hex-svg-png. That would overcome the problem of build/src dir and crawl
the pics.
> Kevin
>
> -------
>
> Well all is not lost I could run forrest site twice :(
> a) forrest site to generate the css files
> b) copy them from build/site/skin to src/documentation/skins/css/
> c) forrest site to generate the corner images
That fuels above guess.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
alternate stylesheet switching in Forrest
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Thought I'd have another go at what I called "theme switching" but this
time with the pelt skin/view using corner images and doing things within
Forrest. No Perl script to (a) generate the stylesheets from data
structures and (b) use another Perl script to generate a library of sets
of corner images in different color themes. Each alternate stylesheet
needs it's own set of themed corner images.
I was sucessful in using Forrest to solve the two parts of the problem
(a) & (b) above. They work independantly but not together. I have tried
but *failed* in this and understanding what I can do with Forrest.
Here are my ideas so far:
(a)
themeconfig.xml:
<themeconfig>
<themes>
<theme name="pelt.hot">
<color name="header" value="#294563"/>
<color name="tab-selected" value="#4a6d8c" link="#0F3660"
vlink="#0F3660" hlink="#000066"/>
...
<!-- like skinconf but change ^^^^ to hot shades of red -->
</theme>
<theme name="pelt.cool">
<color name="header" value="#294563"/>
<color name="tab-selected" value="#00ff00" link="#0F3660"
vlink="#0F3660" hlink="#000066"/>
...
<!-- like skinconf but change ^^^^ to cool shades of blue -->
</theme>
</themes>
</themeconfig>
Requests in the form of **skin/view.theme.css ie:
skin/pelt.hot.css
skin/pelt.cool.css
will be matched in resouces.xmap [1] and call template
'view.theme.css.xslt' with a theme parameter ie: theme =
'pelt.hot' or 'pelt.cool' and the style sheets will
be generated.
view.theme.css.xslt is like profile.css.xslt but using
themeconfig.xml data and dealing with corner images.
(b)
As each alternate stylesheet uses a differnet set of colors
matching a url in all style sheets of the form
#header .round-top-left-small {
background: url(images/rc-t-l-5-1header-2searchbox-3searchbox.png) 0 0
no-repeat}
won't work as header/searchbox will need to come from a different
color theme in each style sheet
So 'view.theme.css.xslt' inserts the hex color values from
themeconfig.xml rather than names ie:
#header .round-top-left-small {
background: url(images/rc-t-l-5-X294563-X4a6d8c-X4a6d8c.png) 0 0 no-
repeat;}
Requests in the form skin/images**/*c-*-*-*-X*-X*-X*.png
will be matched in resources.xmap [2] and call 'rcX.svg.xslt'
etc. modified to use hex values.
Problem
=======
Run "forrest site" and the link crawler matches the style sheet
requests in the view file
pelt.hot.css
pelt.cool.css
and they are generated correctly. Game Over :(
Doh! I was expecting the link crawler to then parse the url corner
image requests and generated the png from svg as normal.
I can't understand this. If a static css file is requested it goes
through pipelines and serialized and the corner image links are
crawled and generated? Why can't I do this with a generated css?
I must be missing something, can someone help here? Thanks.
Kevin
-------
Well all is not lost I could run forrest site twice :(
a) forrest site to generate the css files
b) copy them from build/site/skin to src/documentation/skins/css/
c) forrest site to generate the corner images
-------
[1]
<map:pipelines>
<map:pipeline>
<map:match pattern="**skin/*.*.css"> <!-- eg: pelt.hot.css -->
<map:call resource="theme-read">
<map:parameter name="path" value="css" />
<map:parameter name="name" value="{2}.{3}" />
<map:parameter name="mime-type" value="text/css" />
</map:call>
</map:match>
...
<map:resources>
...
<map:resource name="theme-read">
<map:select type="exists">
<map:when test="{project:skins-dir}{path}/{name}.css">
<map:call resource="read-linked-text">
<map:parameter name="path" value="{project:skins-
dir}{path}/{name}.css" />
</map:call>
</map:when>
<map:when test="{project:skins-
dir}{path}/view.theme.css.xslt">
<map:call resource="theme-transform">
<map:parameter name="path" value="{project:skins-
dir}{path}/view.theme.css.xslt" />
<map:parameter name="name" value="{name}" />
<map:parameter name="mime-type" value="{mime-type}" />
</map:call>
</map:when>
<map:otherwise>
<map:read src=".err./{path}/{name}.css" mime-type="{mime-
type}" />
</map:otherwise>
</map:select>
</map:resource>
<map:resource name="theme-transform">
<map:generate src="cocoon://themeconfig.xml" />
<map:transform src="{path}">
<map:parameter name="theme" value="{name}" />
</map:transform>
<map:serialize type="text" mime-type="{mime-type}"/>
</map:resource>
[2]
<map:pipelines>
<map:pipeline>
...
<map:match pattern="skin/images**/*c-*-*-*-X*-X*-X*.png">
<map:call resource="read-svg2png-corner-resource">
<map:parameter name="path" value="images/{1}" />
<map:parameter name="name" value="{2}cX" />
<map:parameter name="orientation-tb" value="{3}"/>
<map:parameter name="orientation-lr" value="{4}"/>
<map:parameter name="size" value="{5}"/>
<map:parameter name="bg-color-name" value="{6}"/>
<map:parameter name="stroke-color-name" value="{7}"/>
<map:parameter name="fg-color-name" value="{8}"/>
</map:call>
</map:match>
...
Re: Views (v1) - a user attempt
Posted by Kevin <fo...@kegcl.demon.co.uk>.
On Tue, 2005-10-18 at 10:27 +0200, Thorsten Scherler wrote:
> Kevin, very cool.
Thanks
> This contract is exactly what was missing to show the power of views. :)
> Would you like to commit it back to views.
Yes. I will sort something out. Though what I have done in
generating the alternate css files is outside of Forrest
using a Perl template system. Not maintainable applying one
say IE bug fix to five css files.
The contact is a simple javascript that used
window.onload=init
to read a cookie and set the alternate css.
I had to patch internal.view prepare.xhtml.xsl
to remove <body onload=init()>
Side note: multiple javascript contracts using init?
I changed nav-main.ft slightly too. Couldn't remove the
gap between main tabs within <ul><li>...
> (more inline)
>
> El lun, 17-10-2005 a las 22:31 +0100, Kevin escribió:
> > Thought I'd post my work in progress in trying to do switchable
> > alternate css stylesheets. I call it theme switching though not
> > sure if that is the correct terminology.
>
> maybe: branding-theme-switcher.ft
>
> > I've put four theme links at the bottom of the left bar home tab,
> > each setting an alternate stylesheet. In doing this I used a Perl
> > template system to generate my alternate css files based on three
> > colors and three contrasting text colors.
> >
> > While doing this it reminded me of the old skinconf with defined
> > colors that were used as parameters to an xslt to create one
> > css file. It got me thinking that Forrest could generate alternate
> > css files then perhaps have a contract that would emulate the
> > <forrest:css ...> tag in view files and insert all the required
> > alternate css files. Perhaps even part of something like the
> > publishedstrip contract to add the links to click to switch the
> > themes rather than what I have done in site.xml at the moment.
>
> NOTE: the structurer do not use the skinconf.xml anymore!
>
> Actually the skinconf colors can be brought back quite easy. I never
> forgot them, but on the archive you may find some mails from other devs
> that do not wanted that anymore, so I did not prioritized them. Anyway,
> it would be awesome to pass the colors into the contract from the view.
Sounds good. In views (v2) as a view still a collection of contracts?
> That leads to another contract that I want to create. genericCss.ft,
> which will bring back the extra-css from the skinconf.xml back. It would
> just take the css definition from the view and pass them into an inline
> css. More or less the same could be done with the colors from the old
> skinconf.
>
> > Anyway I'm probably way off track about what the new theme
> > plugin will allow users to do driven off config' parameters.
>
> jeje, no. The v2 has to be configured totally by the view (no default
> beside the fallback are given). You are right on track with the approach
> I took in v2.
Glad I'm on the right track.
> > Anyone with a slow dial up? Do you see an unacceptable problem
> > if pages aren't cached after choosing another theme other than
> > the default 'dull' theme?
>
> > http://www.kegcl.demon.co.uk/forrest/index.html
> >
>
> Can you can up with a patch that I can use to integrate this really nice
> feature into v2? Like I said above it is awesome to show off what you
> can do with views.
Attached file. Drop on a fresh forrest seed and
edit forrest.properties to get views (v1) working.
Can be dropped on forrest seed-basic but
cp site-basic.xml site.xml
Kevin
> Thanks
>
> salu2
Re: extra-css in views (was Re: Views (v1) - a user attempt)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 23:28 +0200, Thorsten Scherler escribió:
...
> Yes, you are right. I thought about this and I remembered that when we
> came up with
> <forrest:css url="profile.css" media="screen" title="Pelt"/>
>
> I original wanted to allow:
> <forrest:css media="screen">
> /* Extra css */
> #header {
> background: #ffffff;
> border-bottom: thick solid #002b3d;
> }
> </forrest:css>
>
> I will do that if no one speaks up.
done
> BTW I propose to change @title to @theme, that reflects the function of
> the attribute better.
> <forrest:css url="profile.css" media="screen" theme="Pelt"/>
done
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: extra-css in views (was Re: Views (v1) - a user attempt)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 13:28 +0200, Thorsten Scherler escribió:
> El mar, 18-10-2005 a las 10:06 +0100, Ross Gardler escribió:
> > Thorsten Scherler wrote:
> > > Kevin, very cool.
> >
> > ...
> >
> > > That leads to another contract that I want to create. genericCss.ft,
> > > which will bring back the extra-css from the skinconf.xml back. It would
> > > just take the css definition from the view and pass them into an inline
> > > css. More or less the same could be done with the colors from the old
> > > skinconf.
> >
> > Why a contract for this? Wouldn't it be better to define the extra-css
> > in the *.fv?
Yes, you are right. I thought about this and I remembered that when we
came up with
<forrest:css url="profile.css" media="screen" title="Pelt"/>
I original wanted to allow:
<forrest:css media="screen">
/* Extra css */
#header {
background: #ffffff;
border-bottom: thick solid #002b3d;
}
</forrest:css>
I will do that if no one speaks up.
BTW I propose to change @title to @theme, that reflects the function of
the attribute better.
<forrest:css url="profile.css" media="screen" theme="Pelt"/>
To the color profiling, I think that should be better done by a
contract.
<forrest:contract name="branding-theme-profiler">
<forrest:properties contract="branding-theme-profiler">
<forrest:property name="branding-theme-profiler">
<!--Copied from skinconf.xml-->
<color name="tab-selected" value="#4a6d8c" link="#0F3660"
vlink="#0F3660" hlink="#000066"/>
<color name="tab-unselected" value="#b5c7e7" link="#0F3660"
vlink="#0F3660" hlink="#000066"/>
<color name="subtab-selected" value="#4a6d8c" link="#0F3660"
vlink="#0F3660" hlink="#000066"/>
<color name="subtab-unselected" value="#4a6d8c" link="#0F3660"
vlink="#0F3660" hlink="#000066"/>
</forrest:property>
</forrest:properties>
</forrest:contract>
where we really have to change the naming to either contract or hook
names to easier understand which parts of the view this colors will
change.
In leather-dev or pelt old fashion skins the profile.css is generated
from profiling.css.xslt. This is and the forrest.css.xslt should be the
base for this contract.
<forrest:template
xmlns:forrest="http://apache.org/forrest/templates/1.0"
format="html" name="branding-theme-profiler" inputFormat="xsl"
body="false" head="true"/>
If somebody want to provide a patch that would be awesome. That would as
well be good as extension of the how-to about writing contracts. ;-)
As soon I finished the rewriting I can do it if nobody beats me to it.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: extra-css in views (was Re: Views (v1) - a user attempt)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 10:06 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > Kevin, very cool.
>
> ...
>
> > That leads to another contract that I want to create. genericCss.ft,
> > which will bring back the extra-css from the skinconf.xml back. It would
> > just take the css definition from the view and pass them into an inline
> > css. More or less the same could be done with the colors from the old
> > skinconf.
>
> Why a contract for this? Wouldn't it be better to define the extra-css
> in the *.fv?
I do not care how we implement it. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
extra-css in views (was Re: Views (v1) - a user attempt)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> Kevin, very cool.
...
> That leads to another contract that I want to create. genericCss.ft,
> which will bring back the extra-css from the skinconf.xml back. It would
> just take the css definition from the view and pass them into an inline
> css. More or less the same could be done with the colors from the old
> skinconf.
Why a contract for this? Wouldn't it be better to define the extra-css
in the *.fv?
Ross
Re: Views (v1) - a user attempt
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 10:07 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El mar, 18-10-2005 a las 10:27 +0200, Thorsten Scherler escribió:
> >
> >>Kevin, very cool.
> >>
> >>This contract is exactly what was missing to show the power of views. :)
> >>Would you like to commit it back to views.
> >>
> >>(more inline)
> >>
> >>El lun, 17-10-2005 a las 22:31 +0100, Kevin escribió:
> >>
> >>>Thought I'd post my work in progress in trying to do switchable
> >>>alternate css stylesheets. I call it theme switching though not
> >>>sure if that is the correct terminology.
> >>
> >>maybe: branding-theme-switcher.ft
> >
> >
> > Better: branding-theme-color-switcher.ft ;-)
>
> But it is more than a colour switcher. It is a CSS switcher, therefore
> it could change the whole layout of the page.
Yeah I just had a look a the source and it is the same that Cyriaque
want to do with the combo.
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Views (v1) - a user attempt
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 18-10-2005 a las 10:27 +0200, Thorsten Scherler escribió:
>
>>Kevin, very cool.
>>
>>This contract is exactly what was missing to show the power of views. :)
>>Would you like to commit it back to views.
>>
>>(more inline)
>>
>>El lun, 17-10-2005 a las 22:31 +0100, Kevin escribió:
>>
>>>Thought I'd post my work in progress in trying to do switchable
>>>alternate css stylesheets. I call it theme switching though not
>>>sure if that is the correct terminology.
>>
>>maybe: branding-theme-switcher.ft
>
>
> Better: branding-theme-color-switcher.ft ;-)
But it is more than a colour switcher. It is a CSS switcher, therefore
it could change the whole layout of the page.
Ross
Re: Views (v1) - a user attempt
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 10:27 +0200, Thorsten Scherler escribió:
> Kevin, very cool.
>
> This contract is exactly what was missing to show the power of views. :)
> Would you like to commit it back to views.
>
> (more inline)
>
> El lun, 17-10-2005 a las 22:31 +0100, Kevin escribió:
> > Thought I'd post my work in progress in trying to do switchable
> > alternate css stylesheets. I call it theme switching though not
> > sure if that is the correct terminology.
>
> maybe: branding-theme-switcher.ft
Better: branding-theme-color-switcher.ft ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Views (v1) - a user attempt
Posted by Thorsten Scherler <th...@apache.org>.
Kevin, very cool.
This contract is exactly what was missing to show the power of views. :)
Would you like to commit it back to views.
(more inline)
El lun, 17-10-2005 a las 22:31 +0100, Kevin escribió:
> Thought I'd post my work in progress in trying to do switchable
> alternate css stylesheets. I call it theme switching though not
> sure if that is the correct terminology.
maybe: branding-theme-switcher.ft
> I've put four theme links at the bottom of the left bar home tab,
> each setting an alternate stylesheet. In doing this I used a Perl
> template system to generate my alternate css files based on three
> colors and three contrasting text colors.
>
> While doing this it reminded me of the old skinconf with defined
> colors that were used as parameters to an xslt to create one
> css file. It got me thinking that Forrest could generate alternate
> css files then perhaps have a contract that would emulate the
> <forrest:css ...> tag in view files and insert all the required
> alternate css files. Perhaps even part of something like the
> publishedstrip contract to add the links to click to switch the
> themes rather than what I have done in site.xml at the moment.
NOTE: the structurer do not use the skinconf.xml anymore!
Actually the skinconf colors can be brought back quite easy. I never
forgot them, but on the archive you may find some mails from other devs
that do not wanted that anymore, so I did not prioritized them. Anyway,
it would be awesome to pass the colors into the contract from the view.
That leads to another contract that I want to create. genericCss.ft,
which will bring back the extra-css from the skinconf.xml back. It would
just take the css definition from the view and pass them into an inline
css. More or less the same could be done with the colors from the old
skinconf.
> Anyway I'm probably way off track about what the new theme
> plugin will allow users to do driven off config' parameters.
jeje, no. The v2 has to be configured totally by the view (no default
beside the fallback are given). You are right on track with the approach
I took in v2.
> Anyone with a slow dial up? Do you see an unacceptable problem
> if pages aren't cached after choosing another theme other than
> the default 'dull' theme?
> http://www.kegcl.demon.co.uk/forrest/index.html
>
Can you can up with a patch that I can use to integrate this really nice
feature into v2? Like I said above it is awesome to show off what you
can do with views.
Thanks
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> El mar, 18-10-2005 a las 13:10 +0100, Ross Gardler escribió:
>
>>Cyriaque Dupoirieux wrote:
>>
>>>Thorsten Scherler a écrit :
>>>
>>>
>>>>El mar, 18-10-2005 a las 10:03 +0100, Ross Gardler escribió:
>>>>
>>>>
>>>>
>>>>>Cyriaque Dupoirieux wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Ross Gardler a écrit :
>>>>>>
>>>>>
>>>>>...
>>>>>
>>>>>>to http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
>>
>>...
>>
>>
>>>>>I can't see how to switch styles here, I like the idea of a combo box.
>>>>>
>>>>
>>>>
>>>>Button left in some Mozilla. Otherwise something like "view - style" and
>>>>you can select the css.
>>
>>Not in my firefox 1.0.7 :-(
>
>
> Normally not possible, I am using the *same* version on linux and there
> is an option:
> Ver (view)
> Estilo de la página (style of the page) - sin estillo (without style)
> |...
DOH!!!
You are right, I am being exceptionally stupid this morning. There it
is, right in front of me. It must have been hiding earlier ;-)
Sorry.
>>That's my point, see my following comment (re Gavins worked in IE and
>>Firefox without a plugin) ...
And Opera too (I tested that now).
> BTW it is *kevin*.
Sorry Kevin.
Ross
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 13:10 +0100, Ross Gardler escribió:
> Cyriaque Dupoirieux wrote:
> > Thorsten Scherler a écrit :
> >
> >> El mar, 18-10-2005 a las 10:03 +0100, Ross Gardler escribió:
> >>
> >>
> >>> Cyriaque Dupoirieux wrote:
> >>>
> >>>
> >>>> Ross Gardler a écrit :
> >>>>
> >>>
> >>> ...
> >>>> to http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
>
> ...
>
> >>> I can't see how to switch styles here, I like the idea of a combo box.
> >>>
> >>
> >>
> >> Button left in some Mozilla. Otherwise something like "view - style" and
> >> you can select the css.
>
> Not in my firefox 1.0.7 :-(
Normally not possible, I am using the *same* version on linux and there
is an option:
Ver (view)
Estilo de la página (style of the page) - sin estillo (without style)
|...
>
> Are you sure you are not using a plugin for this?
Yes I am quite sure I have not installed a plugin for that.
> >>> Also why do you mention "in firefox"?
> >>
> >>
> >> It is a build in feature, I do not use win so no clue whether IE has
> >> this option but I think it has.
> >>
> >>
> > Excactly the same, I don't know how to do this with IE or Opera, but I
> > think it's possible,
>
> That's my point, see my following comment (re Gavins worked in IE and
> Firefox without a plugin) ...
BTW it is *kevin*. It is doing *exactly* the same like the what firefox
is doing out of the box via menu with javascript. There is no different
besides that you can do it from the page. Yes, we need such a
contract/jscript.
> >>> Does this imply it only works in Firefox? Gavins solution worked in
> >>> IE too (didn't test in Opera).
>
> ...
>
> >> Anyway I would like to see this code. ;-)
> >>
> >>
> > I will work on it as soon as I am able to generate my site again... :'(
>
> I would liase with Gavin on this. His solution appears to be browser and
> plugin independant.
See above it is a jscript that is coming with firefox out-of-the-box (no
plugin) and yes we need this as contract.
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:
> Thorsten Scherler a écrit :
>
>> El mar, 18-10-2005 a las 10:03 +0100, Ross Gardler escribió:
>>
>>
>>> Cyriaque Dupoirieux wrote:
>>>
>>>
>>>> Ross Gardler a écrit :
>>>>
>>>
>>> ...
>>>> to http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
...
>>> I can't see how to switch styles here, I like the idea of a combo box.
>>>
>>
>>
>> Button left in some Mozilla. Otherwise something like "view - style" and
>> you can select the css.
Not in my firefox 1.0.7 :-(
Are you sure you are not using a plugin for this?
>>> Also why do you mention "in firefox"?
>>
>>
>> It is a build in feature, I do not use win so no clue whether IE has
>> this option but I think it has.
>>
>>
> Excactly the same, I don't know how to do this with IE or Opera, but I
> think it's possible,
That's my point, see my following comment (re Gavins worked in IE and
Firefox without a plugin) ...
>>> Does this imply it only works in Firefox? Gavins solution worked in
>>> IE too (didn't test in Opera).
...
>> Anyway I would like to see this code. ;-)
>>
>>
> I will work on it as soon as I am able to generate my site again... :'(
I would liase with Gavin on this. His solution appears to be browser and
plugin independant.
Ross
Fixing problems with v2
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 13:46 +0200, Cyriaque Dupoirieux escribió:
> Thank You Thorsten to answer for me ;-) .
jeje. ;-)
...
> >Anyway I would like to see this code. ;-)
> >
> >
> I will work on it as soon as I am able to generate my site again... :'(
What is your error message?
What does "svn st" gives you?
In your testing project do you have custom contracts?
How does your forrest.properties look like?
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
Thank You Thorsten to answer for me ;-) .
Thorsten Scherler a écrit :
>El mar, 18-10-2005 a las 10:03 +0100, Ross Gardler escribió:
>
>
>>Cyriaque Dupoirieux wrote:
>>
>>
>>>Ross Gardler a écrit :
>>>
>>>
>>...
>>
>>
>>
>>>>Of course, you can do much more than just change the colours. It would
>>>>be cool to see a demo that did more drastic changes. Say move the
>>>>navigation to the right side. Remove the last published timestamps,
>>>>that kind of thing.
>>>>
>>>>
>>>If you want a test with "drastik changes" implemented with views, go to
>>>http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
>>>You can switch from pelt to leatherdev themes with - for instance in
>>>firefox - "Views/style of the page" or something like this...
>>>(I am thinking of a contract which will display a conbo-box to change
>>>the style...)
>>>
>>>
>>I can't see how to switch styles here, I like the idea of a combo box.
>>
>>
>
>Button left in some Mozilla. Otherwise something like "view - style" and
>you can select the css.
>
>
Yep,
>
>
>>Also why do you mention "in firefox"?
>>
>>
>
>It is a build in feature, I do not use win so no clue whether IE has
>this option but I think it has.
>
>
Excactly the same, I don't know how to do this with IE or Opera, but I
think it's possible,
>
>
>>Does this imply it only works in
>>Firefox? Gavins solution worked in IE too (didn't test in Opera).
>>
>>
>
>Actually IMO that is the "missing link" that Cyriaque want to do with a
>combo.
>
>
Exactly again, It is not a specificity of firefox, I just wanted to say
how to change the skin from the browser I use...
>Anyway I would like to see this code. ;-)
>
>
I will work on it as soon as I am able to generate my site again... :'(
Cyriaque,
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 10:03 +0100, Ross Gardler escribió:
> Cyriaque Dupoirieux wrote:
> > Ross Gardler a écrit :
>
> ...
>
> >> Of course, you can do much more than just change the colours. It would
> >> be cool to see a demo that did more drastic changes. Say move the
> >> navigation to the right side. Remove the last published timestamps,
> >> that kind of thing.
> >
> >
> > If you want a test with "drastik changes" implemented with views, go to
> > http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
> > You can switch from pelt to leatherdev themes with - for instance in
> > firefox - "Views/style of the page" or something like this...
> > (I am thinking of a contract which will display a conbo-box to change
> > the style...)
>
> I can't see how to switch styles here, I like the idea of a combo box.
Button left in some Mozilla. Otherwise something like "view - style" and
you can select the css.
> Also why do you mention "in firefox"?
It is a build in feature, I do not use win so no clue whether IE has
this option but I think it has.
> Does this imply it only works in
> Firefox? Gavins solution worked in IE too (didn't test in Opera).
Actually IMO that is the "missing link" that Cyriaque want to do with a
combo.
Anyway I would like to see this code. ;-)
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:
> Ross Gardler a écrit :
...
>> Of course, you can do much more than just change the colours. It would
>> be cool to see a demo that did more drastic changes. Say move the
>> navigation to the right side. Remove the last published timestamps,
>> that kind of thing.
>
>
> If you want a test with "drastik changes" implemented with views, go to
> http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
> You can switch from pelt to leatherdev themes with - for instance in
> firefox - "Views/style of the page" or something like this...
> (I am thinking of a contract which will display a conbo-box to change
> the style...)
I can't see how to switch styles here, I like the idea of a combo box.
Also why do you mention "in firefox"? Does this imply it only works in
Firefox? Gavins solution worked in IE too (didn't test in Opera).
Ross
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 18-10-2005 a las 10:20 +0200, Cyriaque Dupoirieux escribió:
> Ross Gardler a écrit :
>
> > Kevin wrote:
> >
> >> Thought I'd post my work in progress in trying to do switchable
> >> alternate css stylesheets. I call it theme switching though not
> >> sure if that is the correct terminology.
> >
> >
> > You got the correct terminology and your demo is cool (although I have
> > to say I don't like the choice of colours in the themes ;-)).
> >
> > Of course, you can do much more than just change the colours. It would
> > be cool to see a demo that did more drastic changes. Say move the
> > navigation to the right side. Remove the last published timestamps,
> > that kind of thing.
>
> If you want a test with "drastik changes" implemented with views, go to
> http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
> You can switch from pelt to leatherdev themes with - for instance in
> firefox - "Views/style of the page" or something like this...
> (I am thinking of a contract which will display a conbo-box to change
> the style...)
Yeah I see two new contracts here:
1) like you describe a theme switcher
2) a color switcher whithin a theme
Maybe we can make one that can do both. ;-)
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
Ross Gardler a écrit :
> Kevin wrote:
>
>> Thought I'd post my work in progress in trying to do switchable
>> alternate css stylesheets. I call it theme switching though not
>> sure if that is the correct terminology.
>
>
> You got the correct terminology and your demo is cool (although I have
> to say I don't like the choice of colours in the themes ;-)).
>
> Of course, you can do much more than just change the colours. It would
> be cool to see a demo that did more drastic changes. Say move the
> navigation to the right side. Remove the last published timestamps,
> that kind of thing.
If you want a test with "drastik changes" implemented with views, go to
http://cyriaque.dupoirieux.free.fr/testviews1/index.html.
You can switch from pelt to leatherdev themes with - for instance in
firefox - "Views/style of the page" or something like this...
(I am thinking of a contract which will display a conbo-box to change
the style...)
Cyriaque,
>
> As a dev though, I can see that what you have done will make this work.
>
> I think this should go into a seed site for views, this is an
> important improvement.
>
>> While doing this it reminded me of the old skinconf with defined
>> colors that were used as parameters to an xslt to create one
>> css file. It got me thinking that Forrest could generate alternate
>> css files then perhaps have a contract that would emulate the
>> <forrest:css ...> tag in view files and insert all the required
>> alternate css files. Perhaps even part of something like the
>> publishedstrip contract to add the links to click to switch the
>> themes rather than what I have done in site.xml at the moment.
>
>
> This sounds like a good idea, in theory. Lets see what Thorsten says
> regarding his plans for skin configuration (now themes). I know he has
> given this some thought, but not sure if there are any concrete plans
> yet.
>
>> Anyone with a slow dial up? Do you see an unacceptable problem
>> if pages aren't cached after choosing another theme other than
>> the default 'dull' theme?
>
>
> This doesn't affect me personally. However, I doubt it would be a
> problem since users will typically select a theme they like and stick
> with it.
>
>> http://www.kegcl.demon.co.uk/forrest/index.html
>
>
> [OT] are you based in the UK? If so where?
>
> Ross
>
>
Re: Switchable views
Posted by David Crossley <cr...@apache.org>.
Kevin wrote:
>
> > I think this should go into a seed site for views, this is an important
> > improvement.
>
> Yes I'd like to make it a contribution. The part about me using a Perl
> template system was snipped. This makes it easier to add more switchable
> parameters to a css template and generate many theme css files.
>
> If this went into a seed site for views as it stands and an IE or Mac
> css fix is needed it would have to be applied to five css files.
The main/forrest.build.xml build script could handle
this using Ant and XSLT. See some examples at
plugins/build.xml:145 etc. and main/targets/seed.xml
-David
Re: Switchable views (was Re: Views (v1) - a user attempt)
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Subject changed to Switchable Views? User chooses to add / delete
contracts: breadcrumbs, search box, published strip, branding etc in
their view file. Themes are added to that, which are switchable in
css, yes? More inline.
On Mon, 2005-10-17 at 23:51 +0100, Ross Gardler wrote:
> Kevin wrote:
> > Thought I'd post my work in progress in trying to do switchable
> > alternate css stylesheets. I call it theme switching though not
> > sure if that is the correct terminology.
>
> You got the correct terminology and your demo is cool (although I have
> to say I don't like the choice of colours in the themes ;-)).
Let me have your three color choices and I'll do a rosstheme :-P)
> Of course, you can do much more than just change the colours. It would
> be cool to see a demo that did more drastic changes. Say move the
> navigation to the right side. Remove the last published timestamps, that
> kind of thing.
Yep, everything is in each alternate css so can be changed. Thought of
merging pelt view css and have corner images automatically generated in
different colors and switchable! (I see later in the thread it may have
been done!)
Moving nav bar to the right was the first thing I tried. But
#leftbar { float: right; } :(
What about three column layout? No I'm working within what the system
gives me as a user and it's good.
Yes you could make the view switchable by removing an existing published
strip with DHTML and have the page re-flow. I was thinking more of
themes = fonts, colors, borders etc.
> As a dev though, I can see that what you have done will make this work.
>
> I think this should go into a seed site for views, this is an important
> improvement.
Yes I'd like to make it a contribution. The part about me using a Perl
template system was snipped. This makes it easier to add more switchable
parameters to a css template and generate many theme css files.
If this went into a seed site for views as it stands and an IE or Mac
css fix is needed it would have to be applied to five css files.
> > While doing this it reminded me of the old skinconf with defined
> > colors that were used as parameters to an xslt to create one
> > css file. It got me thinking that Forrest could generate alternate
> > css files then perhaps have a contract that would emulate the
> > <forrest:css ...> tag in view files and insert all the required
> > alternate css files. Perhaps even part of something like the
> > publishedstrip contract to add the links to click to switch the
> > themes rather than what I have done in site.xml at the moment.
>
> This sounds like a good idea, in theory. Lets see what Thorsten says
> regarding his plans for skin configuration (now themes). I know he has
> given this some thought, but not sure if there are any concrete plans yet.
>
> > Anyone with a slow dial up? Do you see an unacceptable problem
> > if pages aren't cached after choosing another theme other than
> > the default 'dull' theme?
>
> This doesn't affect me personally. However, I doubt it would be a
> problem since users will typically select a theme they like and stick
> with it.
Page flashes to the persistant css sometimes. I've made it look
like a blank page so less noticable.
> > http://www.kegcl.demon.co.uk/forrest/index.html
>
> [OT] are you based in the UK? If so where?
>
Yes Hertfordshire, you?
Kevin.
> Ross
Switchable views (was Re: Views (v1) - a user attempt)
Posted by Ross Gardler <rg...@apache.org>.
Kevin wrote:
> Thought I'd post my work in progress in trying to do switchable
> alternate css stylesheets. I call it theme switching though not
> sure if that is the correct terminology.
You got the correct terminology and your demo is cool (although I have
to say I don't like the choice of colours in the themes ;-)).
Of course, you can do much more than just change the colours. It would
be cool to see a demo that did more drastic changes. Say move the
navigation to the right side. Remove the last published timestamps, that
kind of thing.
As a dev though, I can see that what you have done will make this work.
I think this should go into a seed site for views, this is an important
improvement.
> While doing this it reminded me of the old skinconf with defined
> colors that were used as parameters to an xslt to create one
> css file. It got me thinking that Forrest could generate alternate
> css files then perhaps have a contract that would emulate the
> <forrest:css ...> tag in view files and insert all the required
> alternate css files. Perhaps even part of something like the
> publishedstrip contract to add the links to click to switch the
> themes rather than what I have done in site.xml at the moment.
This sounds like a good idea, in theory. Lets see what Thorsten says
regarding his plans for skin configuration (now themes). I know he has
given this some thought, but not sure if there are any concrete plans yet.
> Anyone with a slow dial up? Do you see an unacceptable problem
> if pages aren't cached after choosing another theme other than
> the default 'dull' theme?
This doesn't affect me personally. However, I doubt it would be a
problem since users will typically select a theme they like and stick
with it.
> http://www.kegcl.demon.co.uk/forrest/index.html
[OT] are you based in the UK? If so where?
Ross
Views (v1) - a user attempt
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Thought I'd post my work in progress in trying to do switchable
alternate css stylesheets. I call it theme switching though not
sure if that is the correct terminology.
I've put four theme links at the bottom of the left bar home tab,
each setting an alternate stylesheet. In doing this I used a Perl
template system to generate my alternate css files based on three
colors and three contrasting text colors.
While doing this it reminded me of the old skinconf with defined
colors that were used as parameters to an xslt to create one
css file. It got me thinking that Forrest could generate alternate
css files then perhaps have a contract that would emulate the
<forrest:css ...> tag in view files and insert all the required
alternate css files. Perhaps even part of something like the
publishedstrip contract to add the links to click to switch the
themes rather than what I have done in site.xml at the moment.
Anyway I'm probably way off track about what the new theme
plugin will allow users to do driven off config' parameters.
Anyone with a slow dial up? Do you see an unacceptable problem
if pages aren't cached after choosing another theme other than
the default 'dull' theme?
http://www.kegcl.demon.co.uk/forrest/index.html
Kevin
Re: Managing the Forrestbar (Re: [jira] Updated: (FOR-180) Update
forrestbar to be installablein Mozilla Firefox 0.9)
Posted by Addi <ad...@rocktreesky.com>.
Addi wrote:
> Ross Gardler wrote:
>
>> Addi wrote:
>>
>>> David Crossley wrote:
>>>
>>>> Addi wrote:
>>>
>>>
>>
>> ...
>>
>>>>> I am also looking at getting ForrestBar on the
>>>>> official Mozilla extensions site so that updates will be automatic
>>>>> for
>>>>> users. Is there any problem with this that I'm not aware of?
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I don't know anything about it so cannot say.
>>>> Is there a URL that explains what is involved?
>>>>
>>>>
>>> Well, I haven't found tons of detailed info. Here is the link from
>>> Mozilla Update - https://addons.mozilla.org/developers/
>>> The basic idea is that you can get an account and upload and
>>> maintain an extension at the Mozilla Update site.
>>
>>
>>
>> Can you release under the Apache license on the Mozilla update site?
>>
>> Ross
>
>
> As far as I can tell you can release under any license you want. When
> I was looking at various extensions to help me figure out what I
> needed to do, I saw a range of licenses in the code. I will double
> check with the site though.
>
> - Addi
Here is what I found on their wiki:
http://wiki.mozilla.org/Update:Requirements/LegalAndReview
Pertinent part:
1. All hosted software must be in an acceptable source format. It
does not have to be open source, but code must be licensed such
that it can be viewed and read by both mozilla.org staff and
potential end-users.
Re: Managing the Forrestbar (Re: [jira] Updated: (FOR-180) Update
forrestbar to be installablein Mozilla Firefox 0.9)
Posted by Addi <ad...@rocktreesky.com>.
Ross Gardler wrote:
> Addi wrote:
>
>> David Crossley wrote:
>>
>>> Addi wrote:
>>
>
> ...
>
>>>> I am also looking at getting ForrestBar on the
>>>> official Mozilla extensions site so that updates will be automatic for
>>>> users. Is there any problem with this that I'm not aware of?
>>>>
>>>
>>>
>>>
>>> I don't know anything about it so cannot say.
>>> Is there a URL that explains what is involved?
>>>
>>>
>> Well, I haven't found tons of detailed info. Here is the link from
>> Mozilla Update - https://addons.mozilla.org/developers/
>> The basic idea is that you can get an account and upload and maintain
>> an extension at the Mozilla Update site.
>
>
> Can you release under the Apache license on the Mozilla update site?
>
> Ross
As far as I can tell you can release under any license you want. When I
was looking at various extensions to help me figure out what I needed to
do, I saw a range of licenses in the code. I will double check with the
site though.
- Addi
Managing the Forrestbar (Re: [jira] Updated: (FOR-180) Update forrestbar
to be installablein Mozilla Firefox 0.9)
Posted by Ross Gardler <rg...@apache.org>.
Addi wrote:
> David Crossley wrote:
>
>> Addi wrote:
...
>>> I am also looking at getting ForrestBar on the
>>> official Mozilla extensions site so that updates will be automatic for
>>> users. Is there any problem with this that I'm not aware of?
>>>
>>
>>
>> I don't know anything about it so cannot say.
>> Is there a URL that explains what is involved?
>>
>>
> Well, I haven't found tons of detailed info. Here is the link from
> Mozilla Update - https://addons.mozilla.org/developers/
> The basic idea is that you can get an account and upload and maintain an
> extension at the Mozilla Update site.
Can you release under the Apache license on the Mozilla update site?
Ross
Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein
Mozilla Firefox 0.9
Posted by Addi <ad...@rocktreesky.com>.
David Crossley wrote:
>Addi wrote:
>
>
>>Also, in this patch I "versioned" the ForrestBar extension to version
>>0.7. I was thinking that we could match the ForrestBar version to the
>>current version of Forrest. I have two reasons for this thinking: 1) I
>>have a link in the toolbar that links to Current Docs so the ForrestBar
>>version number will tell you which version of the Docs it is pointing to
>>and this would lead to 2) every release of Forrest we should revisit
>>ForrestBar to update the Docs link but also to verify continuing
>>compatibility with browsers so we don't let it fall behind again. Does
>>this seem reasonable?
>>
>>
>
>Yes. We need to add a note to etc/RELEASE_PROCESS.txt
>The version number needs to be incremented as part of
>the lead-up to release.
>
>I don't know how to ensure that we update it for
>each release. Perhaps add an ongoing Jira issue for it.
>
>
I can do these later this weekend if noone else has by then.
>
>
>> I am also looking at getting ForrestBar on the
>>official Mozilla extensions site so that updates will be automatic for
>>users. Is there any problem with this that I'm not aware of?
>>
>>
>
>I don't know anything about it so cannot say.
>Is there a URL that explains what is involved?
>
>
Well, I haven't found tons of detailed info. Here is the link from
Mozilla Update - https://addons.mozilla.org/developers/
The basic idea is that you can get an account and upload and maintain an
extension at the Mozilla Update site. Firefox will look for updates to
extensions there, so if we make changes to our extension and then upload
it, users just need to let Firefox update it for them. One thing I am
not sure of, is that your account login is your email address (and this
is where the account confirmation email is sent) so I would need to know
what email we would use if we do it. I'll see if I can get more
substantive info on how it all really works.
>
>
>>I am also continuing to play with it to try and get it to work in
>>Netscape 8. I tried to put stuff that I thought would be most useful to
>>us but if something needs to be added, it is really simple to do by
>>looking at the chrome/content/forrestbarOverlay.xul file (or just ask on
>>the list and I'll add it).
>>
>>
>
>Thanks for giving it some attention.
>
>Our Zone could be added to the Forrest section.
>forrest.zones.apache.org
>
>The Forrest/JIRA link would be better to go via our
>http://forrest.apache.org/issues.html
>We will gradually enhance this page to lead
>them into JIRA and provide ready-to-go searches etc.
>
>The References section is a good idea for
>some high-level references. The Cocoon links will
>change soon as they re-arrange their documentation.
>
>At some stage the Projects/Browse All CVS
>will be removed. All projects will be
>migrated to SVN by 2006-01-01
>
>The Projects section could also link to
>http://www.apache.org/foundation/projects.html
>
>
Will tweak your suggestions this weekend. The projects all listed out
is pretty much the same as it was in the original, just with some
corrected links. If we just have a link to the apache projects page
rather than actually listing them in the bar (which I'm fine with) I
guess it would make sense to get rid of Projects from the bar and just
move that to be a link under Apache.
- Addi
>More below ...
>
>
>
>>Addison Berry (JIRA) wrote:
>>
>>
>>
>>> [ http://issues.apache.org/jira/browse/FOR-180?page=all ]
>>>
>>>Addison Berry updated FOR-180:
>>>------------------------------
>>>
>>> Attachment: forrestbar.diff
>>> forrestbar.xpi
>>> forrestbar.xml.diff
>>>
>>>This new extension will work with Mozilla 1.x and Firefox 0.9 - 1.5 versions. The .xpi file attached is the one built running the forrestbar target. I'm not sure how we get the .xpi file that is on the web site - if it is built or just put on the server in it's final form - so I included it here.
>>>
>>>
>
>It is manually generated after any occasional
>change.
>
>It gets added to our "site-author" tree.
>Everything that is generated from there gets
>onto the server, e.g. mirrors.cgi and .htaccess
>site-author/content/xdocs/tools/forrestbar.xpi
>
>I just updated the website for forrestbar.html
>and forrestbar.xpi
>
>-David
>
>
>
>
>
Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein Mozilla Firefox 0.9
Posted by David Crossley <cr...@apache.org>.
Addi wrote:
> Also, in this patch I "versioned" the ForrestBar extension to version
> 0.7. I was thinking that we could match the ForrestBar version to the
> current version of Forrest. I have two reasons for this thinking: 1) I
> have a link in the toolbar that links to Current Docs so the ForrestBar
> version number will tell you which version of the Docs it is pointing to
> and this would lead to 2) every release of Forrest we should revisit
> ForrestBar to update the Docs link but also to verify continuing
> compatibility with browsers so we don't let it fall behind again. Does
> this seem reasonable?
Yes. We need to add a note to etc/RELEASE_PROCESS.txt
The version number needs to be incremented as part of
the lead-up to release.
I don't know how to ensure that we update it for
each release. Perhaps add an ongoing Jira issue for it.
> I am also looking at getting ForrestBar on the
> official Mozilla extensions site so that updates will be automatic for
> users. Is there any problem with this that I'm not aware of?
I don't know anything about it so cannot say.
Is there a URL that explains what is involved?
> I am also continuing to play with it to try and get it to work in
> Netscape 8. I tried to put stuff that I thought would be most useful to
> us but if something needs to be added, it is really simple to do by
> looking at the chrome/content/forrestbarOverlay.xul file (or just ask on
> the list and I'll add it).
Thanks for giving it some attention.
Our Zone could be added to the Forrest section.
forrest.zones.apache.org
The Forrest/JIRA link would be better to go via our
http://forrest.apache.org/issues.html
We will gradually enhance this page to lead
them into JIRA and provide ready-to-go searches etc.
The References section is a good idea for
some high-level references. The Cocoon links will
change soon as they re-arrange their documentation.
At some stage the Projects/Browse All CVS
will be removed. All projects will be
migrated to SVN by 2006-01-01
The Projects section could also link to
http://www.apache.org/foundation/projects.html
More below ...
> Addison Berry (JIRA) wrote:
>
> > [ http://issues.apache.org/jira/browse/FOR-180?page=all ]
> >
> >Addison Berry updated FOR-180:
> >------------------------------
> >
> > Attachment: forrestbar.diff
> > forrestbar.xpi
> > forrestbar.xml.diff
> >
> >This new extension will work with Mozilla 1.x and Firefox 0.9 - 1.5 versions. The .xpi file attached is the one built running the forrestbar target. I'm not sure how we get the .xpi file that is on the web site - if it is built or just put on the server in it's final form - so I included it here.
It is manually generated after any occasional
change.
It gets added to our "site-author" tree.
Everything that is generated from there gets
onto the server, e.g. mirrors.cgi and .htaccess
site-author/content/xdocs/tools/forrestbar.xpi
I just updated the website for forrestbar.html
and forrestbar.xpi
-David
Re: [jira] Updated: (FOR-180) Update forrestbar to be installablein
Mozilla Firefox 0.9
Posted by Addi <ad...@rocktreesky.com>.
Also, in this patch I "versioned" the ForrestBar extension to version
0.7. I was thinking that we could match the ForrestBar version to the
current version of Forrest. I have two reasons for this thinking: 1) I
have a link in the toolbar that links to Current Docs so the ForrestBar
version number will tell you which version of the Docs it is pointing to
and this would lead to 2) every release of Forrest we should revisit
ForrestBar to update the Docs link but also to verify continuing
compatibility with browsers so we don't let it fall behind again. Does
this seem reasonable? I am also looking at getting ForrestBar on the
official Mozilla extensions site so that updates will be automatic for
users. Is there any problem with this that I'm not aware of?
I am also continuing to play with it to try and get it to work in
Netscape 8. I tried to put stuff that I thought would be most useful to
us but if something needs to be added, it is really simple to do by
looking at the chrome/content/forrestbarOverlay.xul file (or just ask on
the list and I'll add it).
- Addi
Addison Berry (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/FOR-180?page=all ]
>
>Addison Berry updated FOR-180:
>------------------------------
>
> Attachment: forrestbar.diff
> forrestbar.xpi
> forrestbar.xml.diff
>
>This new extension will work with Mozilla 1.x and Firefox 0.9 - 1.5 versions. The .xpi file attached is the one built running the forrestbar target. I'm not sure how we get the .xpi file that is on the web site - if it is built or just put on the server in it's final form - so I included it here.
>
>
>