reset Preferences CFG file

[Gale Andrews]

I am not sure of the best way to build it on Mac, so I asked Leland.

Of course we can still post unofficial external reset apps for Mac and Linux on the Forum if developers don't want to officially distribute an external app. For my primitive effort on Mac, I used bash rm to delete audacity.cfg and sed for the version that only initialised cfg, but perhaps it should be done with Apple Script in case older Macs don't have support for rm and sed?

IMHO, I would feel uncomfortable if the Audacity Team Developers did not want it distributed. I do not believe that it needs to be shipped with Audacity as part of the "normal" distribution.

I would think for discoverability, it should be shipped with the distribution.

In your bash script were you able to use code to determine the location of the configuration file?

It was just a proof of concept, and I did no more than remove or edit the obvious location of ~/Library/Application Support/audacity/audacity.cfg. So I did not figure out anything about where the audacity installation was in the case that a Portable Settings folder was in use.

But now I tested your external app for that case on Windows 7.

If audacity.cfg and pluginregistry.cfg are in a Portable Settings folder in an Audacity folder that is not the installed location, and the reset executable is in that custom location, the .cfg files in "Portable Settings" are not deleted by your app. Also the presence of those .cfg files in that "Portable Settings" folder prevents deletion of the .cfg files in %APPDATA%Audacity.

The presence of .cfg files in a "Portable Settings" folder in a location where Audacity is installed does not prevent your app deleting the .cfg files in %APPDATA%Audacity - but does so if the reset app is in the installed location of Audacity.

If I move the reset app outside a location where Audacity is (adding the required DLL's to its new location) then the .cfg files in %APPDATA%Audacity are deleted.

Your "single button" modification to Preferences initialises audacity.cfg if it is in a "Portable Settings" folder in the location Audacity was run from, but does not initialize audacity.cfg in %APPDATA%Audacity. Still, that is reasonable I think. The "Reset Preference" box in the Windows installer behaves likewise, affecting only the .cfg in Portable Settings if that folder exists when running Audacity.

Does that point to another solution - writing resetPrefs.txt to the location the reset app is run from?

Testing your external app on Windows, would it be better to use the official Audacity icon with some kind of overlay suggesting reset?

The Help dialogue has a typo "About Reset Audacity's References". I don't know why we need the possessive "Audacity's" anywhere.

Since the buttons actually do delete files, perhaps they should say "Delete" and not "Reset", and only the Help dialogue gives explanation. If we want the external app to to delete audacity.cfg as opposed to reset it, then the "single button" patch to Preferences should also delete audacity.cfg, shouldn't it?

When I only reset pluginregistry.cfg in your external app, the same dialogue is given about resetting Audacity's preferences as with the other buttons, despite I am not resetting Preferences.

If I say "No" in the dialogue to confirm I want to reset Preferences, should the app quit? Perhaps the user wants to explore the other options in the app or look at the help?

In re. the icon: that is a QA/design decision for someone with more artistic skills than I. As long as it has some icon at this stage (alpha) that's all that is important as changing the artwork is simple.

In re. the typo: references versus preferences - sorry, my dictation software has a hard time with those.

In re. grammar: correct grammar usage suggests either "Audacity's preference file" or "the Audacity preference file"; I know that Connie has been convinced that the inconsequential "the" is not desirable but I have a very hard time being convinced <grin>.

The title of an interface dialogue should not have "the". The help text might have "the".

In re. Delete versus Reset: the original design was to "reset" Audacity's configuration file to be completely empty with the exception of the "initialized" line. The design is in flux! If the application eventually has a single button which does nothing but emptying the configuration file (leaving a blank file or one with the initialize line) then Reset is correct.

The button deletes audacity.cfg. Audacity recreates it when it launches. Perhaps the "Reset" word on the buttons is OK as it is now, given the Help says that the files are "completely removed". But the Help should say that the deletion does the reset.

In re. different warning dialogs: until the design is finalized fine tuning the wording is not productive.

OK, but if we keep the "plugins reset only" button, we must not forget that it has a misleading dialogue.

In re. clicking "No" - should close the app: IMHO no; after reading the warning, there is a good chance that the user will want to make a copy of the configuration file before deleting it. Keeping the App open might be convenient.

Maybe the app should have a button which opens the location of the configuration files in Windows Explorer/the equivalent Mac/Linux folder/directory Explorer. Maybe this application should be a Locator not a Deleter nor a Reseter.

I'm glad you agree that "No" should not close the app.

The audacity.cfg default location is hidden by default on most modern systems, so we'd have to be sure if we opened the file manager that we actually displayed the location. Typing %APPDATA% in the Explorer address bar always shows that location.

Still, the whole point of this is to ease the burden on the user. So its main purpose should I think be to act on audacity.cfg directly. Could there be an option to either copy the audacity.cfg contents to the clipboard, or to make a copy of the file in its current location to audacity.cfg.bak?


Gale

[Gale Andrews]

Rescan without selecting a plugin does not remove that plugin from pluginregistry.cfg. Can you see any reason it should not do so?

Is it supposed to be removed from the plugin registry, or just marked as "don't use"? I'm not sure what the intention is.

I can see a good reason for keeping a record of plugins that crash on load - then we don't need to keep trying to load them on every launch.

Yes, I think that idea has been mentioned before. I quite like it, as long as the user can over-ride it e.g. if (s)he obtains a "fixed" version of the plug-in later on.

But as things are now, surely we should not still be caching old plug-ins on rescan?


Gale

[Gale Andrews]

@Ed, I have not seen a new "single button" patch that deletes audacity.cfg, so I propose to try your patch "as is" on Mac later on today.


Gale

[Edgar]

In re. external sledgehammer:

I do not believe that it needs to be shipped with Audacity as part of the "normal" distribution.

I would think for discoverability, it should be shipped with the distribution.

My only concern is that, even with its built-in warnings, given the current design specification that it does not create an automatic backup, a user might be tempted to use it without QA supervision - probably not what we are currently envisioning.

My personal belief is that, given that these files are tiny, the application should create a date-named (audacity26November2014.cfg) backup by renaming the current file instead of deleting it.

[steve]

My personal belief is that, given that these files are tiny, the application should create a date-named (audacity26November2014.cfg) backup by renaming the current file instead of deleting it

That's a neat idea - I like it

[Edgar]

In re. Portable Settings:

…I did not figure out anything about where the audacity installation was in the case that a Portable Settings folder was in use.

But now I tested your external app for that case on Windows 7.

If audacity.cfg and pluginregistry.cfg are in a Portable Settings folder in an Audacity folder that is not the installed location

I had not given any consideration to any of the permutations related to Portable Settings nor had I given any consideration to the concept of an Audacity "install" folder. The only consideration I designed for was the default behavior of having the configuration files in the default location. Obviously, all these other permutations will need to be identified and the ultimate design of the application fine-tuned to take them into consideration.

[Edgar]

@Ed, I have not seen a new "single button" patch that deletes audacity.cfg, so I propose to try your patch "as is" on Mac later on today.

+1 RSVP

[Gale Andrews]

My personal belief is that, given that these files are tiny, the application should create a date-named (audacity26November2014.cfg) backup by renaming the current file instead of deleting it

That's a neat idea - I like it

Or perhaps it should be a full date and time stamp.

That said, I don't see a burning need for it, and it should probably be an option even if on by default.

We aren't proposing to backup audacity.cfg in the version that operates from Audacity Preferences.

The whole point is a reset. If a user runs an explicit external reset app and says yes, reset, I think they had fair warning.


Gale

[Gale Andrews]

In re. Portable Settings:

…I did not figure out anything about where the audacity installation was in the case that a Portable Settings folder was in use.

But now I tested your external app for that case on Windows 7.

If audacity.cfg and pluginregistry.cfg are in a Portable Settings folder in an Audacity folder that is not the installed location

I had not given any consideration to any of the permutations related to Portable Settings nor had I given any consideration to the concept of an Audacity "install" folder. The only consideration I designed for was the default behavior of having the configuration files in the default location. Obviously, all these other permutations will need to be identified and the ultimate design of the application fine-tuned to take them into consideration.

Feel free to test, but it looks like the folder being the install folder or not is irrelevant. The reset app seems to have no effect if there is a "Portable Settings" folder in the folder it's run from. We could simply say in the help for the external app that it only deletes .cfg files in the Application Data folder, and that if you have a Portable Settings folder, rename it.

That said, leveraging the existing feature to reset Audacity by writing "resetPrefs.txt" to the folder the external app runs from seems quite attractive for Windows. If on Mac we can write inside the folder the app runs from, it will work there too.

• We can run the appropriate reset for the version of Audacity, so if run in 2.0.6 or earlier the replaced audacity.cfg will have "NewPrefsInitialized=1", otherwise not.
• If there is a "Portable Settings folder", the audacity.cfg in that (which is the one that matters) gets reset, though not the one in the application data folder.
• We get a ready-made prompt dialogue (Yes or No to reset Prefs when restarting Audacity) that should work cross-platform. I just tested it on Mac by adding resetPrefs.txt to the "Resources" folder in the Audacity.app bundle, and it seems to work fine.
• We can change the current code in Prefs.cpp to do what we like if Audacity finds resetPrefs.txt, then the Windows installer would do the same as the external app (assuming we want consistency between the two.

Gale

[Gale Andrews]

Ed. Leland tried this with your reset.cpp on Mac:

Code: Select all

#!/bin/sh

g++ -o Reset.app/Contents/MacOS/Reset 
    -DMAC_OS_X_VERSION_MAX_ALLOWED=1040 
    -mmacosx-version-min=10.4 
    `wx-config --cxxflags --libs --universal=no` 
    reset.cpp

but it makes no interface and does nothing when run. He says he will try to see whether this can be built with XCode.


Gale