Export of File and Export folder.

[Edgar]

My apologies to the original poster Gale and I have hijacked your thread.

an enhancement option for it - don't make it per project, so that if importing from folder A into Project A then from folder B into Project B, exporting from Project A opens the export dialogue at folder B.

what happens if you Import from folder A into Project A then import from folder B into Project B and then import from folder C into Project C

If there is an option then I guess there could be as many choices for the option as you want, but a choice of "use folder for last import in the session" or "last import in the project" seems useful to me. It could be extended to "use folder for first import in the session" or "first import in the project".

Agreed, if I do create a preference switch it will be either First Imported or Last Imported.

I understand that we stopped using the new dialogue for file saving from 1.3.3 onwards because we added the "Options..." button into the dialogue.

Audacity continued to use the new dialogue for import/open until 1.3.6, so did we go back to the old dialogue there just for "consistency" of the dialogues?

This is way before my time, the first Audacity I saw was 1.3.8. The dialog that I use can have the "Options…" button – I chose to change the button name:

options.png (61.4 KiB) Viewed 2734 times

And so I'm clear, we could use the old dialogues for the "Smart Folders" feature?

On Windows there are at least three types of dialogs which can be used starting with Vista service pack 2: generic wxWidgets (cross-platform compatible); original pre-Vista service pack two (currently in use); new style (the one I use). I have no idea situation is on Mac & Linux. I can't imagine that anyone would write operating system or widgets code which did not allow you to seed the dialog with a specific folder – given that I cannot imagine that it would be hard to add the Smart Folders feature to any Save/Export dialog.

[Edgar]

You may download a Windows 7/8-only version of a customized Audacity 2.0.3 here:
http://www.hometownband.org/members/efm ... er2013.zip

File is corrupt cannot open with Winzip nor command line unzip nor any other unzip utility.

George, again I want to apologize that Gale and I are discussing the implementation of this feature request within the body of this thread! Gale also had problems unzipping the file but eventually succeeded. I do not know what the problem is; I have not had any other complaints and the file has been downloaded and unzipped successfully by the client and others.

It has the "Smart Folders" feature you describe. There are a number of good reasons why the Audacity Development Team has not implemented this feature.

I am not sure the reasons behind this

The reasoning behind this is quite complicated and has to do with cross-platform compatibility (Audacity runs on Mac, Linux & Windows XP and newer) as well as Audacity's need to support older operating systems. Getting this right on all three platforms would be a huge development project and would require significant modifications to the current code – not just adding new code. This modification of existing code could easily introduce subtle new bugs and would require extensive beta testing.

[Gale Andrews]

I've moved this to "Adding Features", probably where it should have gone in the first place.

I understand that we stopped using the new dialogue for file saving from 1.3.3 onwards because we added the "Options..." button into the dialogue.

Audacity continued to use the new dialogue for import/open until 1.3.6, so did we go back to the old dialogue there just for "consistency" of the dialogues?

This is way before my time, the first Audacity I saw was 1.3.8. The dialog that I use can have the "Options…" button – I chose to change the button name

OK, but does this require lots of extra code, as you said? The reason given for losing the Vista SP2 file dialogue was adding the Options... button.

http://www.hometownband.org/members/efm ... er2013.zip

Gale also had problems unzipping the file but eventually succeeded.

No, I gave up and got http://www.hometownband.org/members/efm ... oPlus2.zip instead.

Getting this right on all three platforms would be a huge development project and would require significant modifications to the current code

OK - I have not seen a patch associated with "Smart Folders" - but you're saying that if there was such, even it was got to compile on Mac and Linux, it might not work correctly?

If it could be proved to work cross-platform, that provides some impetus to perform the code refactoring deemed required by the developers before we can achieve AUP drag in and "export to the folder the file comes from". Both of those are perhaps not "glamourous" features but IMO are a big usability improvement.


Gale

[Edgar]

I understand that we stopped using the new dialogue for file saving from 1.3.3 onwards because we added the "Options..." button into the dialogue.

The dialog that I use can have the "Options…" button – I chose to change the button name

OK, but does this require lots of extra code, as you said? The reason given for losing the Vista SP2 file dialogue was adding the Options... button.

There is a lot of code to add the dialog but after you have the dialog there is only a few lines of code to add the button.

http://www.hometownband.org/members/efm ... oPlus2.zip

That link is correct.

OK - I have not seen a patch associated with "Smart Folders" - but you're saying that if there was such, even it was got to compile on Mac and Linux, it might not work correctly?

I think that Smart Folders should work on all three platforms but it is my understanding that Audacity uses custom file dialogs on each platform with OS-specific code so would require someone familiar with each platform's file dialog code to do the actual coding. Obviously, it would require testing under all the possible OSes.

[Gale Andrews]

OK - I have not seen a patch associated with "Smart Folders" - but you're saying that if there was such, even it was got to compile on Mac and Linux, it might not work correctly?

I think that Smart Folders should work on all three platforms but it is my understanding that Audacity uses custom file dialogs on each platform with OS-specific code so would require someone familiar with each platform's file dialog code to do the actual coding.

On Mac, the Audacity Open and Save dialogues seem identical to those for other apps.

On Ubuntu, the Audacity Open and Save dialogues seem to be customised for no obvious functional reason.

But if the code that detects where the file comes from is agnostic of the export dialogue, shouldn't it work with the existing dialogues on any platform?

All this said, the only thing (big as it is) that prevents us fixing this today is that dragging in files fails to modify DefaultOpenPath. File > Open, File > Recent Files and File > Import > Audio all do modify DefaultOpenPath (on my testing on all three platforms, anyway).


Gale

[Edgar]

But if the code that detects where the file comes from is agnostic of the export dialogue, shouldn't it work with the existing dialogues on any platform?

If you look at lib-src/FileDialog/ you will see that each of the three platforms has an entirely different source code directory; a Developer familiar with each OS's file dialog would need to modify that specific code branch. I am sure that it is fairly easy to do so but it would require familiarity with that OS.

All this said, the only thing (big as it is) that prevents us fixing this today is that dragging in files fails to modify DefaultOpenPath. File > Open, File > Recent Files and File > Import > Audio all do modify DefaultOpenPath (on my testing on all three platforms, anyway).

I think that opening the file via the CLI sets the DefaultOpenPath to the CWD (folder in which Audacity resides). Windows also does this weird thing with file shortcuts where it abbreviates the actual full path which causes DefaultOpenPath to be corrupt; the way to decode this differs between XP and newer Windows.

Once again, I do not believe that this would be hard to accomplish but I do believe that it will require someone familiar with the file dialog code in each of the OSes and careful beta testing on all OSes.

[Gale Andrews]

But if the code that detects where the file comes from is agnostic of the export dialogue, shouldn't it work with the existing dialogues on any platform?

If you look at lib-src/FileDialog/ you will see that each of the three platforms has an entirely different source code directory; a Developer familiar with each OS's file dialog would need to modify that specific code branch. I am sure that it is fairly easy to do so but it would require familiarity with that OS.

Thanks for pointing out where those source files are.

I assume the "additional button on Save dialogs" mentioned in the cpp files is the "Options..." button.

I'm not really clear why the functionality we want impacts on the specific file dialog used.

Or are you saying it affects the FileDialog*.cpp files, irrespective of the specific dialog used?

All this said, the only thing (big as it is) that prevents us fixing this today is that dragging in files fails to modify DefaultOpenPath. File > Open, File > Recent Files and File > Import > Audio all do modify DefaultOpenPath (on my testing on all three platforms, anyway).

I think that opening the file via the CLI sets the DefaultOpenPath to the CWD (folder in which Audacity resides).

I think so few people open files at the command-line, it could almost be disregarded for the sake of a provisional fix.

But I tested it on Windows 7 x64 and for me, opening an audio file from the Windows command prompt doesn't change the already set DefaultOpenPath. For example, an already set (listed in .cfg) DefaultOpenPath of D: doesn't change in response to launching Audacity with:

Code: Select all

C:>"C:Program Files (x86)Audacityaudacity.exe" "S:lisp1Electric Chapel Dance (submix).mp3"

or

Code: Select all

S:>"C:Program Files (x86)Audacityaudacity.exe" "S:Electric Chapel Dance (submix).mp3"

If I initialise audacity.cfg then launch Audacity with one of the above commands, then DefaultOpenPath is not listed in .cfg as expected, but File > Open seems to be what I last used before initialising .cfg (I tested twice with different last directories). So there must be a registry setting that Windows saved?

Do you concur with those findings using released 2.0.5? Your custom builds look as if they do something different.

I notice there are three "Feature Request" votes that command-line file opening should change the export path to the current directory, so those users want another behaviour again.

Windows also does this weird thing with file shortcuts where it abbreviates the actual full path which causes DefaultOpenPath to be corrupt; the way to decode this differs between XP and newer Windows.

Thanks for the reminder.

Once again, I do not believe that this would be hard to accomplish but I do believe that it will require someone familiar with the file dialog code in each of the OSes and careful beta testing on all OSes.

Perhaps you would not want to, but do you think you could make a patch that only fixed bug 550 for Windows (perhaps that did not even add a preference, but just forced DefaultOpenPath to change after importing a file by any method)?

Or don't you know yourself how force DefaultOpenPath, given your builds don't do that either?

I am just wondering that if there was a proof of concept patch for Windows that it may get Mac and Linux developers most of the way too, and give some motivation to do the code refactoring that is deemed important.


Gale

[Gale Andrews]

@ Ed - your post I was replying to seems to have gone, sorry, but much of it is in the quotes.

On Windows pre-Vista SP 2 there is only one OS function for creating the save dialog, thereafter there are two; Vista SP 2 and newer has the older XP-style save dialog function and an entirely new function. The method for seeding the working folder is quite different for these two dialogues.

I am still a little confused as to which dialogs we are using now for releases on Windows. Is it the standard wx Open and Save dialogues, where the Save dialogue is modified by addition of the "Options..." button?

Do your Smart Folders builds work on Windows XP, and the dialogue there is the pre-Vista SP2?

There is a bug in the mod-script-pipe enabling code which improperly sets CWD, this may have been removed when mod-script-pipe was removed).

In fact 2.0.1 which bundled modules doesn't have DefaultOpenPath reset to CWD by launching it from the command-line. So I guess you actually have to be running a script to trigger the bug?

Given the feature requests to use CWD from the command-line, should that bug be left unreported for now?

The reason I did not use DefaultOpenPath from the configuration file in the first place was because it was not properly flushed; Vaughan committed some changes recently which causes preferences to be flushed more often – not just when the program exits; this might help that situation. Still, we may not want to be changing the default open path, I think we want to be creating a new Save/Export seed folder (DefaultSavePath).

As I understand Vaughan's position, the solution of providing a preference to use DefaultOpenPath for ExportPath is "simpler" (or it would be, if all the import methods actually set DefaultOpenPath).

I think it is desirable that any import (including using File > Open...) sets DefaultOpenPath. As it is now, your special builds have the "inconsistency" that an import other than from the FileOpen dialogue sets ExportPath but not DefaultOpenPath, but an import using FileOpen sets both paths.

I cannot imagine how a proof of concept patch would help. If there was a Developer on Windows who wanted to experience this behavior they could try out my current application and just ignore all the other changes.

I think they could imagine the behaviour from a one line description, but will be more fired by a patch.

I'm guessing that a patch that for any import method, sets DefaultOpenPath to the folder the file came from would be preferred to your solution of a global variable. It not only fixes an inconsistent behaviour but lets us provide a preference to "Export to last opened folder" for any import method.

Given the "Preferences creep" fear, that Preferences option may be all that we'll get to start with, despite other options such as a default folder and first opened folder may be useful.

I agree the developers would still want to refactor first, but are they ever going to do it in isolation without knowing for sure that DefaultOpenPath can be set for any import method? I'm not sure I would want to test a refactoring patch without knowing that bug 550 is fixable by Vaughan's preferred method.

[Aside: what does the NewImportingSession parameter in .cfg do? It seems to appear the first time you use File > Import > Audio... .]


Gale

[Edgar]

@ Ed - your post I was replying to seems to have gone, sorry, but much of it is in the quotes.

Very weird – I did not delete it; as you say the important stuff is in your quotes…

Do your Smart Folders builds work on Windows XP, and the dialogue there is the pre-Vista SP2?

The Smart Folder part would work on Windows XP and its old style dialog. The build for my client will not work on Windows XP due to other features.

There is a bug in the mod-script-pipe enabling code which improperly sets CWD, this may have been removed when mod-script-pipe was removed).

In fact 2.0.1 which bundled modules doesn't have DefaultOpenPath reset to CWD by launching it from the command-line. So I guess you actually have to be running a script to trigger the bug?

Given the feature requests to use CWD from the command-line, should that bug be left unreported for now?

The bug is not that DefaultOpenPath gets reset but that CWD gets reset to:
…winReleasemodules
when it should be:
…winRelease

As I understand Vaughan's position, the solution of providing a preference to use DefaultOpenPath for ExportPath is "simpler" (or it would be, if all the import methods actually set DefaultOpenPath).
I think it is desirable that any import (including using File > Open...) sets DefaultOpenPath. As it is now, your special builds have the "inconsistency" that an import other than from the FileOpen dialogue sets ExportPath but not DefaultOpenPath, but an import using FileOpen sets both paths.

After giving it some thought, I agree on this.

I'm guessing that a patch that for any import method, sets DefaultOpenPath to the folder the file came from would be preferred to your solution of a global variable. It not only fixes an inconsistent behaviour but lets us provide a preference to "Export to last opened folder" for any import method.

Given the "Preferences creep" fear, that Preferences option may be all that we'll get to start with, despite other options such as a default folder and first opened folder may be useful.

I agree the developers would still want to refactor first, but are they ever going to do it in isolation without knowing for sure that DefaultOpenPath can be set for any import method? I'm not sure I would want to test a refactoring patch without knowing that bug 550 is fixable by Vaughan's preferred method.

I think that a Smart Folder patch without the re-factoring and with no new preference switch does make a lot of sense. I have a broken collarbone and I'm not doing much coding right now. I might give it a try – no promises.

[Aside: what does the NewImportingSession parameter in .cfg do? It seems to appear the first time you use File > Import > Audio... .]

This is a new one on me; searching…

Code: Select all

Find all "NewImportingSession", Match case, Whole word, Subfolders, Find Results 2, "Entire Solution", "*.cpp"
 srcMenus.cpp(4627):   gPrefs->Write(wxT("/NewImportingSession"), true);
 srcimportImportFFmpeg.cpp(307):      gPrefs->Read(wxT("/NewImportingSession"), &newsession);
 srcimportImportFFmpeg.cpp(315):            gPrefs->Write(wxT("/NewImportingSession"), false);
  Matching lines: 3    Matching files: 2    Total files searched: 343

I have no idea what it's doing. It is set to TRUE only on any File/Import/Audio… menu driven Import attempt - successful or not. (This is poorly coded, it should only set to TRUE on a successful import and I assumed should work in all Import gestures). It is set to FALSE only during an attempted FFmpeg Import (I suspect this is poorly coded, also for a similar reason, though I may be wrong here as I have not carefully analyze the code). It is certainly not robust as there are a few other methods of getting into the FFmpeg Import code other than File/Import/Audio…

[mdubin]

I had started a thread on this topic in another forum just a few days ago and was advised to post here.

Audacity is the GREATEST and I really hate to have a complaint. But when I click on "Export", the folder is not the same as the one I imported from. Countless times I have forgotten to look at the export folder and as a result could not find the file where I expected it to be. Gale Andrews advised me that this is a very tough thing to be fixed for all circumstances and am glad that the Audacity team is aware of this and is working on it.

Thanks.

mdubin