A user-named shortcut to a setting chooser will change that chooser's list title

[iPodVT]

ipod6g
Rockbox dev build 1d7e9d4910-250509

Example:  If you create a shortcut to the Brightness setting chooser and enter a name in the shortcut's optional "name:" field, when you subsequently access that chooser via your shortcut the chooser's list title will be the same as your shortcut's name.  But if you then re-access that same chooser via the Settings menu (Settings->General Settings->Display->LCD Settings->Brightness), the chooser's list title will be the original "Brightness".  The Shortcut spec in the Rockbox User Manual states "name: <what the shortcut should be displayed as>", which I incorrectly assumed meant only how the shortcut would be named in the user's Shortcuts menu, not what the chooser's list title would also become.

This allows for a potential condition that would break a theme's ability to reliably identify which setting chooser is the current screen if the test is based on the chooser's list title. In the example above, if you use %if(%Lt, =, %Sx(Brightness)) to test the chooser's list title it will return TRUE when you access the chooser via the Settings menu and it will return FALSE if you access the chooser via the named shortcut.

There is another more obscure way in which this varying chooser list title scenario creates a condition that causes a failure with %if(%Lt, =, %Sx(Brightness)).  Here's how I discovered it:

For some reason that I can't recall, when I created my shortcut to the Brightness chooser I (ignorantly, unnecessarily and redundantly) set the shortcut's "name:" field to "Brightness".  The lucky/coincidental result was that regardless of whether I accessed that chooser via my shortcut or via the Settings menu, the title of that chooser's list was still "Brightness" and %if(%Lt, =, %Sx(Brightness)) correctly identified the current screen as being the Brightness chooser.  But then for further testing I changed the language to French, and when I accessed the chooser via the Settings menu the chooser's list title correctly appeared as "Luminosité" and the title test succeeded (thanks to the %Sx tag) but when I accessed it via my shortcut the list's title was "Brightness" and the title test failed.

So if you have a shortcut to a Setting chooser and if you don't give that shortcut a name, everything is fine.  But when you do give it a name - even the same name as the chooser's default name - things can break.  The obvious question is:  [Edit] Is there an intentional reason and need/benefit for Rockbox to change a setting chooser's list title to be the same as the shortcut's user-supplied name?

[iPodVT]

I edited the question at the end of my above post to make the main point of the post be more clear.  The question is:

Is there an intentional reason and need/benefit for Rockbox to change a setting chooser's list title to be the same as the shortcut's user-supplied name?

Thanks.

[Bilgus]

What you ran into there was the conversion from french to english happening correctly but in your renamed one it not doing the conversion

No I don't think we want anything to do with users renaming their settings, if anything it probably need a field to store the 'real' (translatable) name

[iPodVT]

What you ran into there was the conversion from french to english happening correctly but in your renamed one it not doing the conversion

No I don't think we want anything to do with users renaming their settings, if anything it probably need a field to store the 'real' (translatable) name

Thanks very much for your reply, Bilgus.

I'm pretty sure I fully understood what was happening but not why it needs to happen.

The purpose of my post was to point out some potential pitfalls of customizing a shortcut's 'name' field given the current Rockbox implementation of that feature, and also to inquire as to whether or not a user-supplied name getting applied to a setting chooser's list title was intentional and in any way necessary or useful.  I believe that eliminating that application would solve the problems I was illustrating, though perhaps that application is serving some functional purpose that I'm currently not aware of and/or don't understand.

I like being able to customize the names of some of my shortcuts because some of the default names in the context of a shortcuts menu seem a bit ambiguous to me and don't clearly express what the shortcut is connected to.

Again, thanks.