Rockbox

  • Status New
  • Percent Complete
    0%
  • Task Type Patches
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.6
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by jdgordon - 2010-10-19

FS#11689 - Theme settings

This adds a very simple way for themers to add some customisability to their themes without requiring the user to actually edit the skin files.

2 new tags are added:
%Sl(name, default, …) to configure a setting named "name" with the default value "default", the … is any amount (up to 32) of strings which are accepted values. The order here is the order to be used with the next tag.

%Sv(name) to get the value. If the users value isnt in the above list, or the setting file is missing the default value will be used… can be used with normal ?<> conditionals or %if() (both number and name should work)

For the user to actually use this he needs to create /.rockbox/wps/skinsettings.txt which has the same syntax as .cfg files. i.e "name: value" and #comment.

This first version is very stupid and loads the .txt file into every skin which has a least one %Sl(), but the final version will do this much smarterer. (Also these settings are static so the values should be loaded at parser time instead of runtime.)

Also a plugin could be made to dump the allowed values for the used theme (or all skins) to disk to make it easier.

Because there is no limit to what the settings could be, I'm hoping that defacto setting names will just happen, the theme site could help with this also. It isnt a big deal if theme A accepts different values for a setting than theme B though.

Lastly, I need to also add a simple way for yes/no type settings %?Sv(show aa)<%Cd> should be able to work… Actually, brain fart time… because the settings are loaded at parse time we could probably use the feature handling code to always only parse the correct branch which would save a bunch of skin buffer and render time.

   themesettings.0.diff (8.5 KiB)
St. commented on 2010-10-19 17:22

I had an idea,

As the settings are likely to be designed for a particular skin, and theme authors will likely have different conventions (we've seen many, many times how "creative" theme authors can be with skin syntax) perhaps the settings configuration file should be tied to a specific skin also?

Example: 

 themename.fms
 themename.sbs
 themename.wps
 themename.txt    <--- settings/configuration file gets the same naming convention as the rest of the theme files.

This would also mean that each setting file stayed in the vicinity of the skin it is "tied" to, when sorted alphabetically…making it easy to determine which setting file was for which theme, and manage that, instead of having to edit a "global" settings file each time a new theme supporting this is added to the users theme library.
I imagine a global type configuration file could eventually end up having several differently named, or misspelled setting variables that were essentially exactly the same, and you'd be all but guessing which was which, and which setting was relevant to which theme in those cases.

I see this being a rather sensible solution for managing each themes settings.

Just a thought,

[St.]

jdgordon commented on 2010-10-19 22:07

Ignoring that themename.txt should be reserved for the themes readme… I'm not sure about this.

If every themes settings are in the one file it would force themers to work together on nameing schemes, and we have options to make it easier (i.e at the very least we could add a wiki page which people can keep updated, or generated from the theme site). Whoever it makes it harder to test a theme without any custom settings to see how it looks (although, if I already have "no aa" set in my theme file it is a good chance I never want to, no matter what theme I'm loading.)

Also, loading a single file makes it a bit less complicated and keeps ram usage down.

I don't know which is better, more opinions neededed

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing