Rename "Configuration files"

[davidhedlund]

Is there an existing issue for this?

• This is a bug in RetroArch frontend
• I have searched the existing issues

Description

Currently, the directory setting located at Settings → Directory

Configuration files
Default configuration file is stored in this directory.

is causing significant confusion among users. Many mistakenly interpret this setting as the location for the primary retroarch.cfg file:

• "Configuration file" path override in "Settings → Directory" fails to save and load retroarch.cfg #19196
• "Save Current Configuration" ignores "Configuration files" directory setting #16490

"Configuration files" behavior

As clarified in previous discussions, this directory is specifically intended for per-core, per-directory, and per-content override .cfg files.

Examples of "Configuration files" directory generated content:

• Without content loaded:
  • Main Menu → Configuration File → Save New Configuration saves a timestamped retroarch-[YYMMDD-HHMMSS].cfg file.
    • Not automatically loaded the when RetroArch starts again.
• With loaded content (Main menu → Load Content):
  • Main Menu → Configuration File → Save New Configuration saves a [corename].cfg file.
    • Not automatically loaded when content is loaded.
  • When RetroArch is closed (or Close Content) [corename]/[corename].opt is saved.
    • Automatically loaded the content is loaded next time.
  • Any changed setting in RetroArch (eg Settings → User Interface → Apperance → Color Theme) followed by Quick Menu → Overrides → Save Core Overrides creates directory and saves file [corename]/[corename].cfg
    • Not automatically loaded when content is loaded.

Todo

Update Settings → Directory → Configuration files

Update:

Configuration files
Default configuration file is stored in this directory.

To:

Overrides & Configuration Saves
Directory for saving 'Overrides', and the 'Main Menu → Configuration File' items (Note: 'Save Main Configuration' is not saved here).

Note: "Overrides" refers to the settings found in Quick Menu → Overrides. The term "Quick Menu" is omitted from the label for simplicity, per hizzlekizzle’s recommendation.

Steps to reproduce the bug

1. Navigate to Settings > Directory.
2. Observe the entry labeled "Configuration files".
3. The lack of specificity leads to the assumption that this manages global configurations, rather than the intended override files.

Version/Commit

1.22.2

Bisect Results

No response

Present in the nightly version

Yes, this is reproduced in the nightly build

Platform & operating system

GNU/Linux

Affected Cores

No response

Environment information

No response

Relevant log output

References

1: Press the 'Select' button on this item for further guidance. This follows the existing help pattern used in areas like 'Main Menu → Quit' and 'Settings → User Interface → Language'.

[davidhedlund]

@Ryunam Thanks again for this suggestion. Would you like to take the lead and submit a PR for it?

[Ryunam]

Thank you for opening this. Yes, I'm in the middle of some directory and menu-related work, so I will take care of this.

As for the naming, I'd rather go for "Configuration Overrides", for the following reasons:

• It is best to omit "Directory" from this type of name, as all the other custom path options never mention "directory" by design (should be pretty self-explanatory anyway, since we are in the Directory sub-menu)
• Overrides are still .cfg files, since they are intended to selectively replace parts of the main configuration files, so it's best to label them accordingly.

[hizzlekizzle]

Remaps go in there, too, right? If so, neither "overrides" nor "configuration overrides" is quite precise, IMO. Since it's all core-specific, what about something like "Core configuration(s)"?

[hizzlekizzle]

Hmm, it looks like remaps go into config/remaps, and overrides go into config/[corename]. Those could be consolidated, and I think that would be sensible, since remaps are necessarily core-specific. There is other stuff that lives in 'config' that's not core-specific, though, that I had forgotten about, such recording configs.

We currently have a separate configuration entry for remaps, but I'm not sure how much utility we get out being able to set that somewhere else than where the overrides and core options go.

[Ryunam]

For completeness sake, and to avoid disrupting any existing configuration which might already make use of the two path redirections (mine included, since I do redirect overrides and remaps to two different cloud-sync folders, respectively) for now I would rather go for a simple name change of the override-related path setting.

There's also another point in favor of keeping the two settings separate: you could have multiple sets of remaps lying around that are dependent on several factors (different controllers, for example, or different test cases, etc). Having a remap-specific path configuration allows one to quickly switch between one set of remaps and another, without messing with the overrides at all.

[davidhedlund]

@Ryunam The sub-label should be updated too:

Default configuration file is stored in this directory.

[hizzlekizzle]

Sorry in advance for the wall of text:

I wouldn't include any paths, e.g. 'Quick Menu → Overrides' in menu text, since things can move around--or change names, as we're discussing here--and we would need to update all text strings (and resulting translations) accordingly.

I think the current wording of the sublabels is mostly clear, but some could use an additional sentence for clarity, IMO. They're also written in caveman-speak, which makes them unnecessarily confusing. For example, the sublabel for 'Load Configuration' is "Load existing configuration and replace current values," which can be ambiguous. I think it would be better to say "Choose and load [AN] existing configuration [FILE], replacing the current values." I know it's technical mumbo jumbo for some, but I personally think it would be even clearer to say "... replacing the current values [IN MEMORY]."

Likewise, 'Save New Configuration's sublabel, "Save [THE] current configuration to [A] separate file in the [WHATEVER WE NAME IT] directory" and 'Save Main Configuration's sublabel, "Save the current [IN-MEMORY] configuration values as the main configuration[, OVERWRITING WHAT IS CURRENTLY IN THE FILE]" would be more precise than the current ones, but arguably more confusing for non-technical users. Would it make sense to include a warning that these options will commit any overridden values, as well? E.g., "If any overrides are currently active, their values will be be saved to the configuration file, as well."

I think 'Save Configuration As' and 'Save New Configuration' need some disambiguation, and the difference between them is whether it's named automatically or manually, right? If so, 'Save [THE] current [IN-MEMORY(?)] configuration [VALUES] to an automatically named file in the [WHATEVER WE NAME IT] directory' vs 'Save [THE] current [IN-MEMORY(?)] configuration [VALUES] to a new file in the [WHATEVER WE NAME IT] directory with a custom file name' or something like that seems the most clear/accurate to me.

Finally, I think 'Save Main Configuration' should be either first or second place on this screen, since I think it's either the most or second-most common thing a person needs to do. Saving secondary configuration files is not something I do often at all, and I suspect I'm not alone there.

[davidhedlund]

Sorry in advance for the wall of text:

I wouldn't include any paths, e.g. 'Quick Menu → Overrides' in menu text, since things can move around--or change names, as we're discussing here--and we would need to update all text strings (and resulting translations) accordingly.

I removed Quick Menu to be included in the sub-label from the main post. Thank you.

I think the current wording of the sublabels is mostly clear

To keep the main discussion focused, I’ve moved all sub-label proposals—with the exception of 'Configuration files'—to a dedicated issue:

• Update "Save Main Configuration" sub-label (bypasses custom save directory) #19211

[davidhedlund]

I think the current wording of the sublabels is mostly clear, but some could use an additional sentence for clarity, IMO. They're also written in caveman-speak, which makes them unnecessarily confusing. For example, the sublabel for 'Load Configuration' is "Load existing configuration and replace current values," which can be ambiguous. I think it would be better to say "Choose and load [AN] existing configuration [FILE], replacing the current values." I know it's technical mumbo jumbo for some, but I personally think it would be even clearer to say "... replacing the current values [IN MEMORY]."

Likewise, 'Save New Configuration's sublabel, "Save [THE] current configuration to [A] separate file in the [WHATEVER WE NAME IT] directory" and 'Save Main Configuration's sublabel, "Save the current [IN-MEMORY] configuration values as the main configuration[, OVERWRITING WHAT IS CURRENTLY IN THE FILE]" would be more precise than the current ones, but arguably more confusing for non-technical users. Would it make sense to include a warning that these options will commit any overridden values, as well? E.g., "If any overrides are currently active, their values will be be saved to the configuration file, as well."

I think 'Save Configuration As' and 'Save New Configuration' need some disambiguation, and the difference between them is whether it's named automatically or manually, right? If so, 'Save [THE] current [IN-MEMORY(?)] configuration [VALUES] to an automatically named file in the [WHATEVER WE NAME IT] directory' vs 'Save [THE] current [IN-MEMORY(?)] configuration [VALUES] to a new file in the [WHATEVER WE NAME IT] directory with a custom file name' or something like that seems the most clear/accurate to me.

Finally, I think 'Save Main Configuration' should be either first or second place on this screen, since I think it's either the most or second-most common thing a person needs to do. Saving secondary configuration files is not something I do often at all, and I suspect I'm not alone there.

I appreciate these suggestions. I've noted them in the relevant issue tracker where they can be better addressed:

• [Menu] Menu sub label finetunes #18802 (comment)