This idea has come up before, but its got a bit of a new slant this time.

The idea is that a WPS/SBS (skin) could define some config settings
which are not part of the core menu settings, to allow the user to
easily tweak a skin.
A simple example would be if a user never wants to see AA and we dont
want to add a setting to disable it, the themer could add something
like %?z|AlbumArt|<%C>.
Another obvious usage is similar to above, where the themer sets up a
bunch of conditional viewports and has the enable line at the top in
such a way that the user could then go and change it to off, or change
the viewport.

There are more uses but I think those are the main ones (but I'm sure
themers will come up with more).

So how it would work is there would be 3 parts to each setting:
1) setup - somewhere in a skin there would be a line like
%z|<name>|<type/values>|<default>| so the skin engine knows how the
setting works.
<name> is obviously the name, <type/value> would be "bool", "code",
"int", or a list of comma seperated values to show the order i.e
"|one,two,three|", <default> would be the value which is used if none
is set
2) usage - the tag would then be used like any other skin tag.
%z|<name>| would just dump the text value, %?z|<name>|<.....> would be
how it looks in a conditional.
3) setting the value - there would be a file <some filename>.tcfg
which would look like an ordinary .cfg (so a listing of name: value)
which would have the settings from all the loaded skins in it. A menu
item would be added to generate this file, but otherwise the user
would have to edit it in a text editor.

One of the types I mentioned is "code", I think this is where we will
see the most use... My plan for this is to literally allow the user to
dump some skin code into the setting and have the %z|<name> tag be
completely replaced with the code from the setting.
Off the top of my head this would be really useful for translations
(does the user want "%pn of %pc" even if its non english language?)
and the time/date string.

Points to think about:
* There is almost certainly going to be name collisions with the
settings between themes. I think a parse error should happen in that
case.
* What should happen if a setting is used in a skin file but the
definition is in another skin? (i.e used in the sbs but defined in the
wps?) disallow that completely?
* Maybe we want the definitions to come from a <themename>.settings
file instead of the skin file directly?
* is %z|| a good tag for this?
* filename extensions? do we allow the user to have multiple .tcfg's?
or hardcode a filename which is always used?
* How do we get themers to work together to come up with commonly used
settings? <- integrate with the theme site for this I think

Questions? Comments? Suggestions? (Is this big enough for a GSoC project?)

Jonathan
Received on 2010-03-28