= Theme Plugins =
This proposal describes a way trac could get a working theme support. The main idea is that every project which uses trac should have it's own theme. Or at least each major trac installation.
The current way is overriding `htdocs_location` in the trac config to bypass the shipped css and js files and inject new ones. Using the `site.html` file (talking of trac 0.11) you can then override the way the template is rendered. Because of the great Genshi API with XPATH support nearly everything is overrideable. But trac upgrades are a pain in the ass and distributing themes does not work.
== Generic CSS Classes ==
One of the first things which should be done is cleaning up the shipped css files. They should use more generic classes and documented classes. Each plugin developer should be able to use them too in his plugins.
Also the trac core would only ship layout css files without color definitions. The default theme would then add the color definitions for the elements (links, browser etc). Currently the only way to change the trac colors is copying the default css files and replace all the color hex values with own ones.
To create a list of generic classes an analysis of the current css files and genshi templates would be required.
== A CSS Preprocessor ==
CSS does not allow variables and constants unfortunately. Because of that a CSS preprocessor is the only way to use a value twice in a file. If a request in a chrome folder goes to `foo.css` and the `foo.css` file does not exist the chrome system would look for a `foo.css.tmpl`. If that file exists trac loads it as python text template (`string.Template`) and executes it.
Such a template would have access to the current theme provider described below.
> cmlenz is not happy with this solution because it breaks static file serving over apache. Maybe there are better ways.
Implementing this is probably not needed if the CSS classes are generic enough and plugins/the trac core just uses them. The actual themes then style those classes.
== A Theme Provider ==
The most important part of a theme would be the theme provider. Because trac supports plugins which can add their own css files it's pretty hard to keep a global style without overriding the css files of the plugins too.
{{{
#!python
class IThemeProvider(Interface):
def get_theme_color(name):
"""
Return the hexadecimal value for a given name. The actual color
names should be specified on a wiki page in the trac.edgewall.org
wiki so that plugin developers could get informations about the
allowed colors.
If a name is not overriden by the theme it has to return a
default color. (for example ``#000000``)
"""
}}}
== site.html ==
At the moment trac instances have a `htdocs/` and a `template/` folder. Both will stay, but the `site.html` in the template folder goes.
The `site.html` file will be part of a theme. If a theme implements not only the `IThemeProvider` but also the `ITemplateProvider` it can add a `htdocs` and `template` folder to the searchpath. In the latter would now be the `site.html` file.
As long as the `layout.html` file does not change you can override nearly everything in the `site.html` file by using XPATH:
{{{
#!text/html
${select('*')}