forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [RT] Accepting and managing Skin Packages
Date Thu, 02 Jun 2005 08:31:05 GMT
On Thu, 2005-06-02 at 15:49 +1000, David Crossley wrote:
> Ross Gardler wrote:
> > 
> > 1. Forrest accepts the skin and keeps it in SVN
> > 
> > I am -0 on this. We need to would then be forced to maintain the skin 
> > and ensure that it is "correct" in the sense of everything is done the 
> > right way. I would prefer we only maintain the one skin in our core and 
> > utilise the skin packaging system in order to add more skins.
> Actually there is another option that comes before
> all of these. We enhance Pelt skin to be able to address
> these needs, hopefully with patches from the community.
> We have tried to encourage this option, but few people
> are interested.
> I think it is the best option (apart from the views plugin).
> We work as a community to develop one really good skin that
> can address most needs and enables people to configure it.

IMO the only thing that we can and should accept is the CSS of Claudia.
Skins ("old fashion" - the ones we have right now) are horror for
maintainment (and there are only few that really maintain them). More so
if they change common skin stylesheets.

Per definition the result of a skin is a html skeleton that contains css
markup and features. Features of skins are contracts. A skin provider
can decide which contracts to offer (Claudia stated that they riped
parts out of the skin). Now using this beautiful skin of her would mean
we have to add this parts again and create a new "old fashion" skin.
That leads to an endless circle of work on "old fashion" skins.

IMO we should focus to implement views and not adding more (endless)
work with "old fashion" skins. In views Claudia would provide a
default.fv, the default.css and a couple of new contracts (if needed,
which can either override the common ones by providing new
implementations of them or providing new contracts), which all are
easily maintainable. I am -1 for dedicating any energy on "old fashion"
skins that are in my eyes a dead end. 

It makes more sense to finish views and address the skin package
facility for views.

> > 
> > 4. The skin author donates the skin to an external Open Source project 
> > and uses that projects CVS/SVN etc.
> > 
> > This is kind of a half way house between option 2 and option 3. In the 
> > past we tried to set-up a Sourceforge project for this, but it was 
> > rejected as the project would not generate program code. I will offer 
> > the Burrokeet project on SF since this uses Forrest at its core so the 
> > housing of Forrest skins is appropriate within that project. I do not 
> > have any problems adding skin contributors to that project to ensure 
> > they have commit access. Of course, there may be other projects that are 
> > appropriate.
> > 
> > 
> > ---
> > 
> > Whatever we do, we should encourage the use of skin packages and we 
> > should extend the system to list "official" skins in the same way the 
> > plugin system does, see 
> >
> > 
> > Comments, ideas?
> I am very concerned that we told Thorsten that we had no time
> to review the "views" plugin proposal, which i gather will
> address many "skin" needs, yet we are finding time to revisit
> the skins situation.

Yeah, you hit the nail on the head. 

IMO we should *not* encourage the use of skin packages but rather the
development and usage of views. I started views firstly only to address
"skin" needs. That means we are splitting our resources apart where we
should bundle them by talking about and encouraging the outdated "old
fashion" skins. 

...and sure you only can encourage something that you have reviewed.

Just my 2 cents.

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

View raw message