reset Preferences CFG file

[Gale Andrews]

So where are we going with the single button in Prefs, as per Ed's patch? I've tested it on all three platforms.

Gale

[Edgar]

Leland has not found a way yet to make your Windows external reset app into a Mac app.

My external reset app should not be too difficult to compile on Mac and Linux. Can you compile any of the wxWidgets sample applications? I started with the controls sample. Start with Windows:
1) make a copy of that folder (%WXWIN%samplescontrols) within its parent folder (%WXWIN%samples)*
2) rename it "resetAudacity" or anything obvious and different from the name of the folder in which my current code resides
3) copy reset.cpp & reset.h from the folder in which my current code resides into this new "resetAudacity" folder
4) within "resetAudacity" delete both controls.cpp & controls.h (or rename them: "old controls.cpp" etc.)
5) within "resetAudacity" rename my files: reset.cpp becomes controls.cpp & reset.h becomes controls.h*
6) open folder "resetAudacity" up and start the included MS VS solution
7) compile and test this application which will be called controls.exe

On Mac & Linux follow the above instructions 1-5 then:
6) open a terminal and CD to this new "resetAudacity" folder
7) use "make" as you normally would (my understanding is that at the terminal prompt you just type:

Code: Select all

make

and press <ENTER> and everything should just proceed automatically from there resulting in a new application which will be called controls.exe.


*This just keeps the compiler and makefile happy about the location of wxWidgets include files and libraries.

[Edgar]

I am hoping we would distribute the external app with Audacity on Windows and Mac. So nothing to download that they did not already download.

If we distribute an external application it should come with all three platforms.

You've convinced me that instead of messing about with audacity.cfg and/or pluginregistry.cfg we should just create resetPrefs.txt in the appropriate location. Unfortunately, I see no easy method of locating that "appropriate location"; fortunately this is a Catch-21 (not as bad as a Catch-22 <grin>). Only Audacity knows where the "appropriate location" is and, currently, it only knows this when it is running. Our external application needs to know where this "appropriate location" is, Audacity is probably unable to run and thus is unable to tell us where said location is. It would be fairly trivial to have Audacity create a new file in the same folder as audacity.cfg and pluginregistry.cfg; this would be a simple text file (or maybe XML?) with a single line containing the fully qualified path to said "appropriate location".

Although there is no method for an external application to "calculate" Audacity's configuration folder, the external application can make the assumption that, if both Audacity and said external application are built at the same time and from within the same source tree, the external application can have all the information that Audacity uses to create its configuration folder. This means that the external application can look in Audacity's configuration folder for the above-mentioned text file, read that single line containing the fully qualified path to Audacity's containing folder and then create the new resetPrefs.txt file.

Non-coders can skip the rest of this…
Audacity's source code uses wxT("Audacity") as appName to build the fully qualified path defining the folder containing its configuration files.

Code: Select all

Find all "wxT("Audacity")", Match case, Whole word, Subfolders, Find Results 2, Entire Solution, "*.cpp;*.h;"
  D:AudacitySVNsrcAboutDialog.cpp(292):   S.StartNotebookPage( wxT("Audacity") );
  D:AudacitySVNsrcAudacityApp.cpp(1038):   wxString vendorName = wxT("Audacity");
  D:AudacitySVNsrcAudacityApp.cpp(1039):   wxString appName = wxT("Audacity");
  D:AudacitySVNsrcProject.cpp(736):   : wxFrame(parent, id, wxT("Audacity"), pos, size),
  D:AudacitySVNsrcProject.cpp(1177):      name = wxT("Audacity");
  D:AudacitySVNsrceffectsnyquistNyquist.cpp(165):      return wxT("Audacity");
  Matching lines: 6    Matching files: 4    Total files searched: 850

From the above we can see that wxT("Audacity") is redefined every time it is used (five times). This is very poor programming technique, it should be defined once in a header file (and if we do it as I suggest below the same header file can be #included in Audacity and the external application so that both applications are guaranteed to have identical information):

Code: Select all

/**********************************************************************

   Audacity: A Digital Audio Editor
   Audacity(R) is copyright (c) 1999-2011 Audacity Team.
   License: GPL v2.  See License.txt.

   AudacityName.h

********************************************************************//*!

file AudacityName.h

  This is just to specify the name Audacity.  All files which need
  to use wxT("Audacity") should include this.

*//********************************************************************/

#ifndef __AUDACITY_NAME_H__
#define __AUDACITY_NAME_H__
static wxString gAudacity_Name(wxT("Audacity"));
#endif // __AUDACITY_NAME_H__

and used like this:

Code: Select all

S.StartNotebookPage(gAudacity_Name);

Note though:

Code: Select all

// AUDACITY_NAME is legitimately used on some *nix configurations.

so

Code: Select all

// LL: Moved here from InitPreferences() to ensure VST effect
//     discovery writes configuration to the correct directory
//     on OSX with case-sensitive file systems.
#ifdef AUDACITY_NAME
   wxString appName = wxT(AUDACITY_NAME);
   wxString vendorName = wxT(AUDACITY_NAME);
#else
   wxString vendorName = wxT("Audacity");
   wxString appName = wxT("Audacity");
#endif

   wxTheApp->SetVendorName(vendorName);
   wxTheApp->SetAppName(appName);

our external application will need to take this into consideration also.

[steve]

From the above we can see that wxT("Audacity") is redefined every time it is used (five times). This is very poor programming technique, it should be defined once in a header file

The only one of those that I know about is:

Code: Select all

D:AudacitySVNsrceffectsnyquistNyquist.cpp(165):      return wxT("Audacity");

Looking at that in context, we see that it is just a string that is returned by the Nyquist Prompt:

Code: Select all

wxString EffectNyquist::GetVendor()
{
   if (GetID() == wxT("nyquist prompt"))
   {
      return wxT("Audacity");
   }

   return mAuthor;
}

That string is the "vendor" (aka "author" / "publisher") of the effect. In the future it could be decided to change that to "Dominic Mazzoni" (or whoever actually wrote that bit of code), or to "Built In effect", or to "", or to "N/A"....
If the name of the application were ever to change to "New Audacity", then that string should NOT be automatically changed.
In other words, it is just a "coincidence" (dreamt up in Leland's brain) that it happens to be the same string as #define __AUDACITY_NAME_H__

[steve]

If we distribute an external application it should come with all three platforms.

On Linux the convention is to package separate applications separately. Thus the "reset app" would be a separate package from the "audacity" application. The "reset app" could be listed as a "recommend" type dependency, but as it is not "required" for running Audacity, it is a combination of the package maintainer's decision and the user's package installation settings, whether to pull in the "reset app" when installing Audacity. I would guess that most package maintainers would not pull in the external "reset app".

Also, on Linux, it is no more difficult to reset Audacity preferences manually than would be to run an external "reset app".

[Edgar]

The only one of those that I know about is:

Code: Select all

D:AudacitySVNsrceffectsnyquistNyquist.cpp(165):      return wxT("Audacity");

Looking at that in context, we see that it is just a string that is returned by the Nyquist Prompt

I stand by my contention even in this case. The intention is clearly to return vendorName and if we ever change vendorName we would almost certainly want the change to proliferate into NyquistEffect.GetID. 15 years from now if we change the branding name we would almost certainly pick up the two instances of vendorName and appName but could easily miss the obscure Nyquist reference.

[Edgar]

If we distribute an external application it should come with all three platforms.

On Linux the convention is to package separate applications separately.

Even if the two apps are conjoined at the hip as it were? On Windows it is quite common to have helper applications in the same folder as the basic application. Generally the basic application would execute these helper applications conditionally - not all helper applications would be executed every time the basic application was executed. Occasionally there are helper applications which are designed to be launched by the user.

Also, on Linux, it is no more difficult to reset Audacity preferences manually than would be to run an external "reset app".

"no more difficult" - it's been so long since I played with Linux I don't remember the details. Generically, resetting manually requires:

• 1) locate Audacity's configuration folder
  2) open a CFG file with a text editor (how does one do that generically on Linux - on Windows we can right click and say "Open with")
  3) edit & save

resetting via external application:

• 1) launch application (What is the method of launching Audacity given: a) Audacity came prepackaged with the distribution; b) Audacity was installed by the package manager; c) other? Would launching a required helper application be any different?)
  2) click the button

but as it is not "required" for running Audacity, it is a combination of the package maintainer's decision and the user's package installation settings, whether to pull in the "reset app" when installing Audacity. I would guess that most package maintainers would not pull in the external "reset app".

In this case the Audacity Development Team would have determined that it is "required", it would be part of the Audacity source code and would be created along with Audacity.exe when one issues the "make" command.

[steve]

The intention is clearly to return vendorName and if we ever change vendorName we would almost certainly want the change to proliferate into NyquistEffect.GetID. 15 years from now if we change the branding name we would almost certainly pick up the two instances of vendorName and appName but could easily miss the obscure Nyquist reference.

Isn't the "vendor" (aka "author" / "publisher") the person/company/organisation that originated the plugin?
David R Sky is no longer with us, but we still (rightly imo) list him as the "author" (aka "vendor" / "publisher") of the plugins that he created. As his only known plugins are published on the Audacity wiki, it could be argued that the "publisher" is Audacity, but Leland decided to pull the name from the ";author" header in the plugin code. If I change my name in the future, that does not alter the fact that plugins that I have created were originated by who I am now (which is who I was then).

If Leland was intending to use the "#define __AUDACITY_NAME_H__" string, then I'm certain that he is capable of doing so, but he chose not to.

IF Audacity changes its name in 15 years time, and you want to argue that the author/publisher/vendor of the Nyquist Prompt should be updated, then you can argue the point in 15 years time should you wish to. I don't see much point about complaining about it now, especially as it is not certain that you would win the argument.

[steve]

Even if the two apps are conjoined at the hip as it were?

No Linux distributions that I know of include the manual in the Audacity package. In fact, I don't know of any distribution that even packages the manual.

[steve]

"no more difficult" - it's been so long since I played with Linux I don't remember the details. Generically, resetting manually requires:

There are several ways that work for Audacity 2.1 on Linux. Here are two methods:

Method 1.
With Audacity closed, enter in a terminal:

Code: Select all

rm ~/.audacity-data/audacity.cfg

Method 2:
With Audacity closed:

• Open the file browser.
• Press Ctrl+H (or select "View > Show Hidden Files")
• Open .audacity-data
• Delete audacity.cfg

resetting via external application:

There are several methods that work on Linux. Here are 3:

Method 1:
Assuming that the reset application is "installed" and not just downloaded.
enter in a terminal:

Code: Select all

name-of-reset-application

If the application is downloaded and is executable but not installed.
enter in a terminal:

Code: Select all

"fully qualified path to name-of-reset-application"

If the application is downloaded but does not have "execute" permissions (default), then it is necessary to first change the file permissions to make it executable.

Method 2:
(works with most Desktop environments, including Gnome, KDE, Unity, Cinnamon and Mate.)
if the reset application is installed and has an icon in the Applications menu:
Find the reset application icon in the Applications menu and click on it (do we have an appropriate and unambiguous icon for the reset application?)

Method 3:
(Specific to Ubuntu and derivatives)
if the reset application is installed:
Open the Applications menu
Type the first few characters of the reset application name, then
select the icon for the reset application.