The image is just a quick "sketch" of one possible option.
Most operating systems already include an editor that will do the task perfectly well (in Windows it is called NotePad
) but we perhaps want a method that is less open to user error (but also less versatile). The code that reads audacity.cfg should (and in most cases does) do a sanity check on the data, so entering invalid data is unlikely to be catastrophic.
Gale Andrews wrote:I suggested using a GUI editor and .cfg settings a while ago on -devel for advanced options for libsoxr quality.
I think that is a good example.
There's also several interface options that Edgar has come up with that are unlikely to get in the main "Preferences" dialogue, but could easily be made available through something like this (for example, what colour do you want the on-track track name, or how big do you want the various fonts?).
Gale Andrews wrote:Do I assume your combo boxes are pre-filled (uneditable)? If so, where are they getting their input from? I am guessing they have to scour the Audacity code for gPrefs so they expose all the items that could be added?
It depends how foolproof we want to make it.
In programs such as SciTE, the configuration files are installed with default values, often with options commented out. The user then edits that file (SciTE is a text editor) as they wish. This is NOT foolproof, but it is extremely flexible.
Audacity resets preferences to their defaults by simply deleting the settings. When a feature (such as an effect) is run for the first time, it uses its hard coded default values and writes that to audacity.cfg unless changed by the user.
I don't know if it is possible to automatically "scour the Audacity code for gPrefs" (short of a recursive text search) because any variable
'could' be written to preferences - the only difference between a variable that is written to prefs and one that isn't is whether or not it is included in a "gPrefs->Write" statement.
The simplest (and I think "foolproof") method of listing sections and keys would be to hard code them into the editor (or a read-only file that is accessed by the editor). This list would only need updating if new options are created.
Gale Andrews wrote:And your final box is a text edit box? Would it not be less error prone if the parameter was pre-filled and the only user input was the value (1024 in this case)?
I would envisage the "value" (the last box) to be an edit box. Some keys can have a very wide range of values (such as "
[Window] Width=" can be any integer from 250 up to several thousand). If a nonsense (invalid) value is edited, Audacity should be able to restore a sensible default value. For example, if Audacity is being used on a USB memory stick with audacity.cfg in "Portable Settings" on the USB stick, and it is used full screen on a large monitor before being used on a small monitor, the (previously valid) Window Width setting will no longer be valid and will be overwritten automatically. Thus there is (or at least "should" be) built-in protection against invalid values.
In the case of: "
[Effects/Change Pitch] Window Size=", there could be some fringe user case where some other fixed value would be useful other than 1024. The Change Pitch code would be responsible for checking that the value is valid.
Gale Andrews wrote:Do we really need this for other than the .cfg file?
I don't know. Do we, or will we want/need more than one options/preference file?
We have previously spoken of saving Nyquist plug-in settings - would we want these in the audacity.cfg file or another file? Personally I think it would be better to save these elsewhere.
Making it specific to audacity.cfg is a lot simpler than a more general editor. As we currently only have one configuration file we could certainly start with an editor that only deals with audacity.cfg. Reading and writing to audacity.cfg seems to be pretty straightforward as it is a simple format (loosely based on the Windows INI file format) and is natively supported by wxWidgets. It also has built-in mechanisms that help to prevent corruption