Audacity Forum

Edgar wrote:

Gale Andrews wrote:@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 wrote:I assume Steve tested it on Linux?

$ 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

steve wrote:

Gale Andrews wrote: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

Edgar wrote:

steve wrote:

Gale Andrews wrote: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 wrote:Current HEAD still patches for me (with offset messages). I am building HEAD patched on Ubuntu 13.10 now.

Gale Andrews wrote:@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.

Edgar wrote: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.

touch resetPrefs.txt

Edgar wrote: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 wrote: 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?

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!"));
      }
   }

Edgar wrote:

Gale Andrews wrote: 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.

Edgar wrote: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?

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

Edgar wrote: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.

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

Edgar wrote: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).

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

Edgar wrote:what is the default install location

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