MoinMoin: FeatureRequests/ThemeApi

Making the theme API more powerful (and suck less)

The current theme configuration is not very flexible:

• the themes are just plugin themes + builtin themes
• themes have no private configuration parameters
• there are some parameters in cfg used by all themes, though
• there is this "d" parameter given to themes, ugly code

Let's collect some ideas here about how it could be changed.

Configuration

auth configuration in 1.7 uses a list of auth objects and each object is made by calling some FooAuth(param1=foo, param2=bar, ...) constructor.

Theme configuration could be done in a similar way:

themes = {
    'themefoo': ThemeFoo(param1=foo, param2=bar, ...),
    'themebar': ThemeBar(param3=baz),
}

• -- Are you suggesting themes cascade like the auth objects? themefoo could pass a failed return code and then themebar is called? No.

Default of themes would be {} and if a theme requested is not found in themes, it would fall back to old behaviour and just try to import the theme like 1.6 did. If importing a theme fails, fall back to theme_default and if even that fails, fall back to modern.

There could be a themes_default_params dict like this:

themes_default_params = {
    'param1': ...,
    'param2': ...,
}

This dict could be given to themes that are not configured by themes, like Theme(**theme_params).

• Check compatibility

This dict could be populated with some theme oriented values from cfg (e.g. "show_interwiki"), so that a theme gets all what it needs as a param and does not need to access cfg. For compatibility we can deprecate those cfg vars, but keep them for a while.

The list of available themes would be set(themes.keys()) + set(thememodules).

The example themes above would create the theme set (themefoo, themebar, classic, rightsidebar, modern) (assuming that the last 3 are builtin plugin themes).

Getting rid of "d" param

Currently the themes get this "d" param and access it like d['key'].

If we reserve some names, we could also give it as **d to the theme, so access is directly to key param.

For compatibility, the "d" param could be deprecated, but kept for one release.

Related stuff?

No idea whether this fits here well. From an usability/accessibility point of view, it is sometimes desired to easily customize the editbar. Unexperienced users are often overburdend by the vast amount of available actions. Thererfore it makes sense to remove some actions. The drop-down list box is also not wanted by some accessibility aficionados (I don't care about it). Also the standard-action-names in the editbar could be more comprehensible for inexperienced users sometimes (remember the people claiming that "info" should be rather called "history"?). To put it short: it would be nice to have an easy way to customize the editbar (maybe depending on some wiki dict defining special editbars for special user groups?). I have tried to implement this in ThemeMarket/SimpleMente (without the user group), see especially section "Easy customization of the editbar" for some highlevel explanations. In SimpleMente you can use the wikiconfig.py to set the editbar as you want. If you are interested I can give more information on the implementation here. -- OliverSiemoneit 2008-06-04 19:30:19

In 1.7 an excluded action is removed from the more actions menu, too.

Passing a Theme in URL

I would like to see part of Nir Soffer's ThemesMacro functionality added so a wiki link could display a page using a special theme. I use these as help popup windows, but I could see other uses - a special theme to display a form, slide show, calendar, etc. In these cases the theme may need to remove/add some/all of the usual wiki navigation links with special links related to the functionality of the page.

Subclassing Another Theme Rather Than ThemeBase

The current method of building a new contributed theme frequently starts with finding an existing theme similar to what is wanted, copying over the theme's htdocs/css and htdocs/img files, and then making the desired changes. This results in a lot of duplicate css code and files that need to be maintained by each theme author as new moin versions are released.

A better method may be to subclass one of the builtin themes, classic, modern, or rightsidebar and make minor overrides to the methods, css, img, and javascript files as required.

An unscientific observation is that contributed themes make the largest changes to the wiki navigation, but tend to break most often on page content. The breakage generally involves improperly formatting some obscure markup like crossed out text, the output of an infrequently used macro, etc. The wiki navigation is fairly easy to test because it is (almost) the same on every page. The content is harder to test, because there are a lot of possibilities.

Subclassing existing themes can be done now. Adding css and javascript is easily accomplished by overriding the html_head method and adding a few links or scripts to the base theme. But there is no elegant way of adding a few new image files -- dumping the new files into the base theme's img directory risks the files being discarded with the next release upgrade.

CategoryFeatureRequest