Page 14 of 15

Re: reset Preferences CFG file

Posted: Wed Dec 10, 2014 10:24 pm
by Edgar
Gale Andrews wrote:
Edgar wrote: That is the reason why you should start with building/testing the Windows solution - just as a sanity check.
Well, you can do that, Ed, if you haven't already ;)

I doubt there is an error in my build of wxMac as I build Audacity regularly on Mac.

I can't find anything useful by Googling, but might this be a missing include? Try asking Leland if you're not sure where to go from here.
Failure to communicate - start by building the Windows solution of the wxWidgets Controls application/sample just as is, this is just to ensure that you can compile and run the wxWidgets sample applications; if you are a "belts & suspenders" kinda guy also build and run the Controls sample application under Mac and Linux. So far you have not told me whether you could build and run the wxWidgets sample applications.

Assuming that you had no trouble running the Mac version of Controls, the next thing you need to do is replace both controls.cpp & controls.h with reset.cpp & reset.h renaming everything as appropriate ("controls.cpp" becomes "old controls.cpp" then "reset.cpp" becomes "controls.cpp"; "controls.h" becomes "old controls.h" then "reset.h" becomes "controls.h").

Next, edit the reset version of controls.cpp so that the line which reads:

Code: Select all

#include “reset.h”
is changed to:

Code: Select all

#include “controls.h”
and it looks like this line might have a typo as a result of a bad download (the trailing F should not be there, delete it):

Code: Select all

#include <wx/fileconf.h>F
Now you should be able to compile it again just as you did to make the original Controls example compile/run.

Re: reset Preferences CFG file

Posted: Sun Dec 28, 2014 11:47 pm
by Gale Andrews
Gale Andrews wrote:
Gale Andrews wrote:So where are we going with the single button in Prefs, as per Ed's patch? I've tested it on all three platforms.
Given this would probably be too much of a feature change for 2.1.0, should I just post the patch with whatever text changes I see fit in http://bugzilla.audacityteam.org/show_bug.cgi?id=363 and update http://wiki.audacityteam.org/wiki/Propo ... _cfg_Reset?
Done.

Gale

Re: reset Preferences CFG file

Posted: Mon Dec 29, 2014 12:06 am
by Gale Andrews
Edgar wrote:
Gale Andrews wrote:
Edgar wrote: That is the reason why you should start with building/testing the Windows solution - just as a sanity check.
Well, you can do that, Ed, if you haven't already ;)

I doubt there is an error in my build of wxMac as I build Audacity regularly on Mac.

I can't find anything useful by Googling, but might this be a missing include? Try asking Leland if you're not sure where to go from here.
Failure to communicate - start by building the Windows solution of the wxWidgets Controls application/sample just as is, this is just to ensure that you can compile and run the wxWidgets sample applications; if you are a "belts & suspenders" kinda guy also build and run the Controls sample application under Mac and Linux. So far you have not told me whether you could build and run the wxWidgets sample applications.
OK I tried on Windows 8 using VS2008 and I got a build error about not finding wxsetup.h. I tried adding C:wxWidgets-2.8.12includemsvcwxsetup.h to the folder containing controls.cpp. This solved the build error but after adding wxbase28u_vc_custom.dll and wxmsw28u_core_vc_custom.dll to the build folder, the app would not appear.

On Windows 7 using VS2013, everything worked OK. I could build the real controls.exe and built and ran your controls.exe (the reset app).

On Mac I ran into errors like this saying that libs can't be found:

Code: Select all

Mac-mini:audacity gale$ cd /Users/gale/Downloads/wxMac-2.8.12/samples/calendar
Mac-mini:calendar gale$ make
/Users/gale/Downloads/wxMac-2.8.12/bk-deps g++ -c -o calendar_calendar.o -D__WXMAC__     -I. -DWXUSINGDLL -I./../../samples -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/Users/gale/Downloads/wxMac-2.8.12/lib/wx/include/mac-ansi-release-2.8 -I../../include -fpascal-strings -I../../src/mac/carbon/morefilex -I/Developer/Headers/FlatCarbon -DWX_PRECOMP -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -fno-common ./calendar.cpp
./calendar.cpp:48:9: warning: 'wxUSE_DATEPICKCTRL_GENERIC' is not defined, evaluates to 0 [-Wundef]
    #if wxUSE_DATEPICKCTRL_GENERIC
        ^
./calendar.cpp:191:5: warning: 'wxUSE_DATEPICKCTRL_GENERIC' is not defined, evaluates to 0 [-Wundef]
#if wxUSE_DATEPICKCTRL_GENERIC
    ^
./calendar.cpp:343:5: warning: 'wxUSE_DATEPICKCTRL_GENERIC' is not defined, evaluates to 0 [-Wundef]
#if wxUSE_DATEPICKCTRL_GENERIC
    ^
./calendar.cpp:677:5: warning: 'wxUSE_DATEPICKCTRL_GENERIC' is not defined, evaluates to 0 [-Wundef]
#if wxUSE_DATEPICKCTRL_GENERIC
    ^
4 warnings generated.
g++ -o calendar  calendar_calendar.o     -L/Users/gale/Downloads/wxMac-2.8.12/lib   -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL   -lwx_mac_adv-2.8  -lwx_mac_html-2.8  -lwx_base_carbon_xml-2.8 -lexpat -lwx_mac_core-2.8  -lwx_base_carbon-2.8   -lwxtiff-2.8 -lwxjpeg-2.8 -lwxpng-2.8      -framework IOKit -framework Carbon -framework Cocoa -framework System -framework QuickTime -framework OpenGL -framework AGL  -lz -lpthread -liconv  -lz -lpthread -liconv
ld: library not found for -lwx_mac_adv-2.8
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [calendar] Error 1
Google has not provided much elucidation.

I made public in the Proposal that current QA consensus favours a shipped external reset app for Windows and Mac that writes "resetPrefs.txt" to the directory the app is in. Do you (Ed) plan to code that for Windows and take it from there, assuming we don't hear feedback that approach is unwelcome?


Gale

Re: reset Preferences CFG file

Posted: Mon Dec 29, 2014 12:41 am
by Edgar
Gale Andrews wrote: I made public in the Proposal that current QA consensus favours a shipped external reset app for Windows and Mac that writes "resetPrefs.txt" to the directory the app is in. Do you (Ed) plan to code that for Windows and take it from there, assuming we don't hear feedback that approach is unwelcome?
Since I cannot do anything on Mac and what I have already provided gives anyone a solid starting off point, it makes no sense for me to keep writing provisional demos for this currently-moving-target.

Re: reset Preferences CFG file

Posted: Mon Dec 29, 2014 11:04 am
by waxcylinder
My simple workaround now is to place a shortcut on my desktops (main user and Audacity test user) for the folder where the .cfg files are located for that user.

Simple then to get there and delete whichever .cfg (file(s) I need to delete :geek:

Peter.

Re: reset Preferences CFG file

Posted: Mon Dec 29, 2014 1:13 pm
by Gale Andrews
Edgar wrote:
Gale Andrews wrote:I made public in the Proposal that current QA consensus favours a shipped external reset app for Windows and Mac that writes "resetPrefs.txt" to the directory the app is in. Do you (Ed) plan to code that for Windows and take it from there, assuming we don't hear feedback that approach is unwelcome?
Since I cannot do anything on Mac and what I have already provided gives anyone a solid starting off point, it makes no sense for me to keep writing provisional demos for this currently-moving-target.
I understood (believe it or not) that there was QA consensus about writing an external app for Windows and Mac for distribution in Audacity that wrote resetPrefs.txt.

If so, there is no moving target unless the developers move it and your starting point app does not do what we want (and it's not posted anywhere a developer will find it).

As I see it, if you (Ed) were to write an app that writes resetPrefs.txt that compiles on Windows, then it's a step forward and a "real developer" should be able to make it compile on Mac.

The alternative which is much easier is to make a native EXE and Mac app that does what we want (basically an executable that runs a script). However I would imagine since that would not be part of the Audacity code base that it might be seen as unofficial or undesirable. Such an app would be of assistance on the Forum even if totally unofficial.


Gale

Re: reset Preferences CFG file

Posted: Mon Dec 29, 2014 6:13 pm
by Edgar
Gale Andrews wrote:an app that writes resetPrefs.txt
AFAICT, from an external application, there is currently no way to determine the folder in which the Audacity executable resides on Windows (although, after writing that, I suspect that the external application might be able to determine this information from the Registry - how to do that, I have not a clue). I suspect this is the same on Mac. This is the reason why we can have the dual preferences/configuration locations (one which is in the same folder in which the Audacity executable resides and one which is in a folder whose path can be calculated from never-changing values).

Here is what I propose for a preliminary design specification, the external app should:

Code: Select all

1) search in ITS containing folder for Audacity.exe
   A) if Audacity.exe is found write resetPrefs.txt in said containing folder and exit happily
2) search for the Audacity configuration file using the existing logic which allows Audacity to be created using those never-changing values
   A) if said configuration file is found open it and search for a path value ("PathToExecutable=…")
      i) if said path is found to be valid and contain Audacity.exe write resetPrefs.txt in said containing folder and exit happily
3) exit unhappily giving the user some error handling suggestions
   A) install a newer version of Audacity*
   B) move this external app into the folder containing Audacity.exe
*This presupposes that the currently available Audacity installation actually writes that path value to audacity.cfg. This would require adding one line of code to the Audacity source.

Before we go any further we need a Developer on board who can & will compile on Mac.

Re: reset Preferences CFG file

Posted: Wed Dec 31, 2014 12:52 am
by Gale Andrews
Thanks, Ed.
Edgar wrote:Here is what I propose for a preliminary design specification, the external app should:

Code: Select all

1) search in ITS containing folder for Audacity.exe
   A) if Audacity.exe is found write resetPrefs.txt in said containing folder and exit happily
2) search for the Audacity configuration file using the existing logic which allows Audacity to be created using those never-changing values
   A) if said configuration file is found open it and search for a path value ("PathToExecutable=…")
      i) if said path is found to be valid and contain Audacity.exe write resetPrefs.txt in said containing folder and exit happily
3) exit unhappily giving the user some error handling suggestions
   A) install a newer version of Audacity*
   B) move this external app into the folder containing Audacity.exe
*This presupposes that the currently available Audacity installation actually writes that path value to audacity.cfg. This would require adding one line of code to the Audacity source.
Or it could be simpler. The app dialogue says at the outset that this app must be run from the folder containing the Audacity version you want to reset.

If it can't find audacity.exe in the folder it's in, it just exits telling user to move this external app into the folder containing the Audacity executable. That should be a fairly rare occurrence given the idea is to ship the reset app with the executable.

If it encounters a write error it will have to suggest running the app as administrator.

I don't think it's a bad idea to write the path to Audacity to audacity.cfg but I wonder how much trouble it will save the user in practice. If user renames or moves Audacity after quitting does the wrong path to Audacity in .cfg cause any problems for normal Audacity operation?

Probably our app should search for audacity* in case user renames the app.

For Mac, there will have to be conditional code (that still compiles on Windows) that tells the app to write resetPrefs.txt to the known relative path "/Audacity.app/Contents/Resources/"
Edgar wrote:Before we go any further we need a Developer on board who can & will compile on Mac.
Leland was interested enough to suggest your internal app should instead write "resetPrefs.txt" in the current directory and not make user quit. I have slight reservations but if it helps acceptance I think it's OK http://bugzilla.audacityteam.org/show_bug.cgi?id=363#c9.

When you have digested / argued with my comments about the external app, you could expand http://wiki.audacityteam.org/wiki/Propo ... rnal_reset with your suggestions and I could update bug 363 linking to the concrete proposal.

Frankly I expect people already assume the patch for the internal reset is your work. Alternatively you could work with Steve on the external app and and say that's his patch.


Gale

Re: reset Preferences CFG file

Posted: Wed Dec 31, 2014 5:12 pm
by Edgar
Gale Andrews wrote: When you have digested / argued
No arguments, digesting now…

Re: reset Preferences CFG file

Posted: Wed Dec 31, 2014 9:46 pm
by Edgar
Patch attached…
This patch does not actually cause anything to happen it just puts up a dialog displaying the full path to the Audacity application.
@Gale - could you try this patch on Mac & Linux and verify that the resulting fully qualified path (ignoring the trailing Audacity.exe) is the exact path in which the Audacity.exe executable resides? If the Mac version is not quite right can the correct folder path the calculated using this information?
@Steve - could you try it on Linux?