reset Preferences CFG file

[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.

+1 RSVP

Got round to that now. I built the patch on Mavericks and made the same tests that I did on Windows. It works as you intend.

I assume Steve tested it on Linux?


Gale

[steve]

I assume Steve tested it on Linux?

No, I've not tested it.

Code: Select all

$ patch -p 0 < resetPrefs2.patch
(Stripping trailing CRs from patch.)
patching file src/AudacityApp.cpp
Hunk #1 succeeded at 299 with fuzz 2 (offset -4 lines).
Hunk #2 FAILED at 1435.
Hunk #3 succeeded at 1860 (offset 10 lines).
1 out of 3 hunks FAILED -- saving rejects to file src/AudacityApp.cpp.rej
(Stripping trailing CRs from patch.)
patching file src/AudacityApp.h
Hunk #1 succeeded at 192 with fuzz 2 (offset 3 lines).
Hunk #2 succeeded at 226 with fuzz 2 (offset -15 lines).
(Stripping trailing CRs from patch.)
patching file src/Menus.cpp
Hunk #1 succeeded at 3588 (offset 536 lines).
Hunk #2 succeeded at 3618 with fuzz 2 (offset 546 lines).
(Stripping trailing CRs from patch.)
patching file src/prefs/PrefsDialog.cpp
Hunk #1 succeeded at 69 (offset 4 lines).
Hunk #2 succeeded at 165 (offset 9 lines).
Hunk #3 FAILED at 306.
1 out of 3 hunks FAILED -- saving rejects to file src/prefs/PrefsDialog.cpp.rej
(Stripping trailing CRs from patch.)
patching file src/prefs/PrefsDialog.h

[Edgar]

I assume Steve tested it on Linux?

No, I've not tested it.

Code: Select all

$ patch -p 0 < resetPrefs2.patch
[…]
1 out of 3 hunks FAILED -- saving rejects to file src/AudacityApp.cpp.rej

I suspect this is a stale patch; I see three potential solutions:
1) patch by hand - shouldn't be TOO difficult
2) check out the proper SVN revision
3) I could create a new patch

I think that #1 is the best solution for Steve and #2 is the easiest solution unless Linux makes it hard to check out a revision other than HEAD. #3 does not make a lot of sense to me, we are in what looks to be at least a two-month feature freeze so any related patch I create now will almost certainly be stale before it could be applied.

[Gale Andrews]

I assume Steve tested it on Linux?

No, I've not tested it.

Code: Select all

$ patch -p 0 < resetPrefs2.patch
[…]
1 out of 3 hunks FAILED -- saving rejects to file src/AudacityApp.cpp.rej

I suspect this is a stale patch; I see three potential solutions:
1) patch by hand - shouldn't be TOO difficult
2) check out the proper SVN revision
3) I could create a new patch

I think that #1 is the best solution for Steve and #2 is the easiest solution unless Linux makes it hard to check out a revision other than HEAD. #3 does not make a lot of sense to me, we are in what looks to be at least a two-month feature freeze so any related patch I create now will almost certainly be stale before it could be applied.

I built the patch OK on Ubuntu 13.10 from code sometime on Nov.29th. Everything tested OK.

Current HEAD still patches for me (with offset messages). I am building HEAD patched on Ubuntu 13.10 now.


Gale

[Gale Andrews]

@Ed, do you think it easy to create the resetPrefs file in the current location of the external app in Windows, and within the app's bundle on Mac? If so, this seems the most viable working solution to me.

Gale

[Gale Andrews]

Current HEAD still patches for me (with offset messages). I am building HEAD patched on Ubuntu 13.10 now.

Builds OK for me with the patch (Unicode Release). Perhaps the version of patch on Debian is more finnicky, I don't know.

Just to be clear, I am building the attached. I may have renamed it for my own purposes.

ResetCFG.patch

Adds single "Reset" button to Prefs that sets audacity.cfg to "NewPrefsInitialized=1"

(5.3 KiB) Downloaded 56 times

Gale

[Edgar]

@Ed, do you think it easy to create the resetPrefs file in the current location of the external app in Windows, and within the app's bundle on Mac? If so, this seems the most viable working solution to me.

I'm not really sure what you're asking for here. Conditional code can be written so that when the application is compiled for Windows it does one thing (creating the file in its (the App's) directory) but when compiled for Mac (and/or Linux) it does a different thing (creating the identical file in a different location).

However, I have absolutely no knowledge of what "App's bundle" means (is it a folder/directory?); I also have no information on whether there is a piece of Mac-specific code (either in wxWidgets or as part of the Mac API) which can determine this (if it is a folder) if it is not the folder in which the application actually resides. If it is a folder in which the application resides the exact same code would work on Windows, Mac & Linux.

On the gripping hand, If you are trying to write resetPrefs.txt into the folder in which Audacity.exe resides from an external application (e.g. ResetAudacity.exe) without the user somehow telling the external application the fully qualified path to Audacity.exe, I don't think this is possible.

[Gale Andrews]

I have absolutely no knowledge of what "App's bundle" means (is it a folder/directory?); I also have no information on whether there is a piece of Mac-specific code (either in wxWidgets or as part of the Mac API) which can determine this (if it is a folder) if it is not the folder in which the application actually resides. If it is a folder in which the application resides the exact same code would work on Windows, Mac & Linux.

On Mac, what looks to the user like an application is actually a folder with the actual app buried in the folder structure.

Relative to the location of the Audacity installation folder, the path to the actual Audacity application is "Audacity.app/Contents/MacOS/Audacity". So, if the Audacity installation folder is /Applications/Audacity, then the "Audacity" application is at "/Applications/Audacity/Audacity.app/Contents/MacOS/Audacity".

To initiate reset of Preferences, "resetPrefs.txt" needs to be placed in the "Contents/Resources" folder. If we know the absolute path it is a real folder path. So for example if the path was "/Applications/Audacity/Audacity.app/Contents/Resources/" changing directory to that path and executing

Code: Select all

touch resetPrefs.txt

creates the file with no content, which is all that's required.

On the gripping hand, If you are trying to write resetPrefs.txt into the folder in which Audacity.exe resides from an external application (e.g. ResetAudacity.exe) without the user somehow telling the external application the fully qualified path to Audacity.exe, I don't think this is possible.

In src/Prefs.cpp there is a wx function for Audacity to get the "ResourcesDir" which is where we're trying to write resetPrefs.txt.

Let's take the easier Windows case first. If our instructions said to run the external app in the folder where audacity.exe was, can the external app not write resetPrefs.txt to the folder that the external app is in?


Gale

[Edgar]

Let's take the easier Windows case first. If our instructions said to run the external app in the folder where audacity.exe was, can the external app not write resetPrefs.txt to the folder that the external app is in?

I think I got lost somewhere along the line. Are you changing the design specifications again?

My understanding is that, on Windows, there is a "magic, secret handshake file" (resetPrefs.txt) whose content is immaterial but whose absence or presence is a switch which causes Audacity to make a decision whether are not to reset preferences upon launch. Are you suggesting that we need to write an external Windows app which the user must place within Audacity's folder and, when run, creates this magic file? If so, I do not see the point, my understanding is that we already have this application (the installer). Also, if we are assuming that the user is sophisticated enough to download an application, find Audacity's folder then copy said application into said folder, I believe that we can also assume they could download the text file and do the same.

Maybe, that is the solution. I have examined the code which plays with resetPrefs.txt*; it is not exclusive to Windows. Since all three platforms look for that file in the application executable's wxStandardPaths::Get().GetResourcesDir() folder why not perform the switching action ubiquitously? We could have instructions which allows the sophisticated user to create/destroy resetPrefs.txt as appropriate without downloading or offer the file as a trivial download for the user who needs more handholding. There could also be some extended instructions on how to find the Audacity executable's folder (on Windows the Task Manager is the easiest solution). The only potential pitfall I can see is if the user does not have Write permissions in that folder (which would be the case if the user installed in - e.g. on Windows - C:Program Files (x86)Audacity the Microsoft-right thing to do). I have never run the Audacity installer (do not want to mess up my development environment), what is the default install location and can the non-administrator user create a new text file in the location?

*For the inquisitive…

Code: Select all

static wxString resourcesDir;
   resourcesDir = wxStandardPaths::Get().GetResourcesDir();
   wxFileName fn;
   fn = wxFileName( resourcesDir, wxT("resetPrefs.txt") );
   if( fn.FileExists() )   // it will exist if the (win) installer put it there on request
   {
      // pop up a dialogue
      wxString prompt = _("Reset Preferences?nnThis is a one-time question, after an 'install' where you asked to have the Preferences reset.");
      int action = wxMessageBox(prompt, _("Reset Audacity Preferences"),
                                wxYES_NO, NULL);
      if(action == wxYES)   // reset
      {
         gPrefs->DeleteAll();
      }
      bool gone = wxRemoveFile(fn.GetFullPath());  // remove resetPrefs.txt
      if(!gone)
      {
         wxString fileName = fn.GetFullPath();
         wxMessageBox(wxString::Format( _("Failed to remove %s"), fileName.c_str()), _("Failed!"));
      }
   }

[Gale Andrews]

Let's take the easier Windows case first. If our instructions said to run the external app in the folder where audacity.exe was, can the external app not write resetPrefs.txt to the folder that the external app is in?

I think I got lost somewhere along the line. Are you changing the design specifications again?

My understanding is that, on Windows, there is a "magic, secret handshake file" (resetPrefs.txt) whose content is immaterial but whose absence or presence is a switch which causes Audacity to make a decision whether are not to reset preferences upon launch.

Yes, but that "magic file" works on Mac and Linux too.

Linux users probably don't need an external app, though, once 2.0.7 trickles through to them. They should be capable of finding and deleting audacity.cfg.

Are you suggesting that we need to write an external Windows app which the user must place within Audacity's folder and, when run, creates this magic file?

Yes, but the main driver for that suggestion is that this "magic file" mechanism works for Mac too, so may make it simpler to produce a native external app for them. Leland has not found a way yet to make your Windows external reset app into a Mac app.

And that Windows app is arguably overkill, assuming we fix the bugs with pluginregistry.cfg.

If so, I do not see the point, my understanding is that we already have this application (the installer).

We do, but (a) not everyone installs Audacity (users in corporate settings may not be allowed to install apps so must use the zip).

And (b) users may not have kept the installer. If they have not, then they have to download the installer again (all 20+ MB of it). As opposed to which, they could just click the reset app in their existing Audacity folder.

Also, if we are assuming that the user is sophisticated enough to download an application, find Audacity's folder then copy said application into said folder, I believe that we can also assume they could download the text file and do the same.

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.

Maybe, that is the solution. I have examined the code which plays with resetPrefs.txt*; it is not exclusive to Windows.

Indeed, I've been saying that for several posts now.

Since all three platforms look for that file in the application executable's wxStandardPaths::Get().GetResourcesDir() folder why not perform the switching action ubiquitously? We could have instructions which allows the sophisticated user to create/destroy resetPrefs.txt as appropriate without downloading or offer the file as a trivial download for the user who needs more handholding. There could also be some extended instructions on how to find the Audacity executable's folder (on Windows the Task Manager is the easiest solution). The only potential pitfall I can see is if the user does not have Write permissions in that folder (which would be the case if the user installed in - e.g. on Windows - C:Program Files (x86)Audacity the Microsoft-right thing to do).

Yes obviously the astute user could create a file called "resetPrefs.txt", even while Audacity was open.

It not only requires the user to have write permissions (or to be able to elevate permissions). They must also be able to create a new text file outside a text editor. This is not trivial to a naive user, and is hard on Mac because Finder gives you no obvious way to do it.

Given those obstacles I think it would be as easy to give instructions to find and delete audacity.cfg. Which brings us full circle as users find that hard and we are trying to make this easier.

I have never run the Audacity installer (do not want to mess up my development environment)

You can run the Audacity installer without upsetting Visual Studio. If not, my VS is extremely upset.

what is the default install location

http://manual.audacityteam.org/o/man/fa ... s.html#exe.

can the non-administrator user create a new text file in the location?

No, see above.

Gale