Preference File Editor

[steve]

Quite frequently we get requests for additional user preferences, but the development team are reluctant to "bloat" the Preferences dialogue (which is already quite large with 17 sections). Often these requested preferences are "advanced" preferences, or preferences that are of minority interest, so rather than bloating the Preferences dialogue, how about having a general purpose, built-in, XML editor that can write arbitrary preferences to (one or more) preference file(s)?

As a rough idea, it could perhaps be something like:

rough mock-up

Configuration_file_editor.png (33.14 KiB) Viewed 2774 times

[Gale Andrews]

Yes I am in favour; I suggested using a GUI editor and .cfg settings a while ago on -devel for advanced options for libsoxr quality.

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?

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)?

Another way of reducing the bloat would be to have an "Advanced" button in any of the Preferences sections affected that leads to the same core dialogue but prefilled just with choices for that Preferences section. This may be less intimidating if there are a lot of choices.

Do we really need this for other than the .cfg file?


Gale

[steve]

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.

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?).

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.

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.

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

[Gale Andrews]

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.

I can see that as not being very maintainable though. And to the extent that hidden gems are missed out, the value of this is diminished.

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.

My point was that if the user is free to enter "WindowSize", "Window_Size", "WindowsSize" or any other typo, the parameter will be ignored.

As we currently only have one configuration file we could certainly start with an editor that only deals with audacity.cfg.

How "built in" is it - is it launched from any Preferences pane?

Should it do the ultimate edit of replacing all content with "NewPrefsInitialized=1" or are we still planning to have a button in Preferences to do that?



Gale

[steve]

I can see that as not being very maintainable though. And to the extent that hidden gems are missed out, the value of this is diminished.

That did occur to me, but it also occurred to me that if we have an audacity.cfg editor then it will be essential that we document (even if very briefly) each "key", so it will be obvious if any keys are missing. An auto-generated list would be better - I'll think about that.

How "built in" is it - is it launched from any Preferences pane?

I was thinking of it being launched from a menu option "Advanced Options" or suchlike.

Should it do the ultimate edit of replacing all content with "NewPrefsInitialized=1"

It could do. Would you want that?
If it is using a list, it could also restore actual default values rather than just deleting them.
If wanted, it could also back-up settings to another file.
It could have some "presets", such as "Reset Interface", "Reset all effects", "Delete Recently Opened List", "High Quality Export Formats"....

This feature request is just for the idea of a "Preference File Editor". I'm not too concerned at this stage about implementation details.

[Gale Andrews]

How "built in" is it - is it launched from any Preferences pane?

I was thinking of it being launched from a menu option "Advanced Options" or suchlike.

You mean a new node in the Preferences tree? I think that would arouse interest and it would look very "built-in" without too many people experimenting with it by accident.

Should it do the ultimate edit of replacing all content with "NewPrefsInitialized=1"

It could do. Would you want that?

No harm in it having that option, but I think a Reset button where the OK and Cancel buttons are would be better.


Gale

[waxcylinder]

Steve: are you planning to write a proposal for this - oy maybe planning to implement it?

I'm assuming it doesn't need transferring to the Wiki - do you need it archiving here?

Peter