Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category User Interface → Themes
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by dionoea - 2008-09-05
Last edited by dionoea - 2008-12-07

FS#9368 - Add settings tag to WPS

wps_settings.patch adds a %St|<some setting name>| tag that can be used to display the value of any rockbox setting in the WPS.

cfg_to_string.patch adds a new function called cfg_to_string and exports it.

Closed by  dionoea
2008-12-07 16:21
Reason for closing:  Accepted

Can this tag be used as a conditional?

I don’t have a clue. This is the first time I’ve looked at the WPS code. Is there some specific code to add to be conditional compliant?

fml2 commented on 2008-09-05 17:44

I think, as it is now, it can’t be used as a conditional switcher. In order to do this, you also have to write the value of the setting to the address pointed to by intval. Compare e.g. WPS_TOKEN_REPEAT_MODE. The value written to the string buffer is used when the tag is used ‘standalone,’ and the int value written to (*intval) is used as the branch number of the conditional.

CFP commented on 2008-09-05 17:48

Great job !

So, basically I should put “setting value as an int” + 1 in the *initval variable? (which would be equivalent to setting value position in the settings menu)

I also had a question about the WPS_REFRESH_ setting. I’m currently using WPS_REFRESH_STATIC. When is that refreshed? on track change only? Should I switch to WPS_REFRESH_DYNAMIC? or something else?

Updated WPS patch enables use as a conditional, prevents matching on partial setting names and adds documentation to the manual.

Changed to WPS_REFRESH_DYNAMIC. This fixes updating the value of some settings which can be changed without quiting the WPS screen. (For example %St|volume|)

fml2 commented on 2008-09-08 19:10

While this tag looks nice and useful at a first glance, it also has a drawback IMO: it exposes the internal setting names to the user. So they need to be documented. Also, if a setting’s name is changed (unlikely but possible), WPS’s using it must be changed.

I also have an idea: in the WPS debug mode (or always?), if an unknown name is used as the parameter in the tag, we could display e.g. ??<bad_name>?? (<bad_name> is the value specified) instead of returning INVALID_PARAM.

Setting names are documented (in an appendix in the documentation). They’re also pretty stable as any changes to a setting name would break the config loading. (well it would disregard the old value).

I’ll try to implement the debug mode idea.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing