Bugzilla – Bug 550
Enh: Add Directories Preference to export to directory the file came from
Last modified: 2018-08-20 11:46:01 UTC
Suggested that default would be to export to the directory the file came from, and this would fall back to last used if there was no open or import e.g. a recording. This satisfies the principal demand. The other two choices would be: * "Last used" (current behaviour) * "User-specified" (Browse button and text box) Notes: 1) Export Multiple goes its own way with last used directory and a Browse button. I suggest this could be left "as is" because there is no demand to change it. 2) Export Labels and Export MIDI already default to the folder the label or MIDI file respectively comes from, so while it would be nice for the Pref to also apply to these, if necessary they can be left "as is". 3) Export Labels should be fixed to display the name of the last imported label file if there was one, not display "labels.txt". This would do as a P4 if not fixed now.
(In reply to comment #0) > Suggested that default would be to export to the directory the file came from, > and this would fall back to last used if there was no open or import e.g. a > recording. This satisfies the principal demand. This is a bit tricky. The intention in the code has been to remember im/export dirs separately, as "/DefaultOpenPath" and "/Export/Path". This fits the use case of, e.g., successively importing files from one directory, editing, then exporting to a different directory. Do we want to end the current ease of doing this? And by "no open or import" do you mean during the whole session, or since the previous export? There's currently no tracking of either. > > The other two choices would be: > * "Last used" (current behaviour) > * "User-specified" (Browse button and text box) Given the above, is this better than changing the way those prefs were intended to work? > Notes: >[...] > > 2) Export Labels and Export MIDI already default to the folder the label or > MIDI file respectively comes from, so while it would be nice for the Pref to > also apply to these, if necessary they can be left "as is". But this is the way you were suggesting Export be changed, right? Not sure which Pref you mean. To be consistent with Export, they would set and use "/Export/Path". > > 3) Export Labels should be fixed to display the name of the last imported label > file if there was one, not display "labels.txt". This would do as a P4 if not > fixed now. > Makes more sense to me to use the name of the last label track, rather than implement tracking of what was imported when. I did that, r11886.
(In reply to comment #1) >>[...] >> The other two choices would be: >> * "Last used" (current behaviour) >> * "User-specified" (Browse button and text box) > > Given the above, is this better than changing the way those prefs were intended > to work? On further thought, I don't really see how this is better than the "Save in:" hierarchical pull-down menu in the current dialog (at least on Windows). But I may have misunderstood, as both directory paths are already saved automatically via gPrefs, so I thought this was about modifying those. On further examination, by the title of this entry, did you mean add a checkbox to the prefs dialog as an option, rather than eliminate the current feature of tracking them separately? If so, I think it should default to the current behavior, as we don't have any feedback from the people who like it as is, only those who don't.
>> Suggested that default would be to export to the directory the file came >> from, and this would fall back to last used if there was no open or import >> e.g. a recording. This satisfies the principal demand. > This is a bit tricky. The intention in the code has been to remember im/export > dirs separately, as "/DefaultOpenPath" and "/Export/Path". This fits the use > case of, e.g., successively importing files from one directory, editing, then > exporting to a different directory. Do we want to end the current ease of > doing this? You mean "export to the last used directory" as now? We still want to cater for this but I feel it is a minority case, so the idea was to make it one of the non-default preference options. > And by "no open or import" do you mean during the whole session, or since the > previous export? There's currently no tracking of either. I was definitely assuming it was per project, so closing a project, then recording something, then exporting, would export to the last used export directory, whatever it was. The main use case for the proposed feature is quick import (or open) then overwrite of a single file. So those users don't care about "since the previous export". But if user imports, exports to the directory "A" the import came from, then without closing the project, imports another file from another directory "B" and exports again, then I assume we would export to directory "B". >> 2) Export Labels and Export MIDI already default to the folder the label or >> MIDI file respectively comes from, so while it would be nice for the Pref to >> also apply to these, if necessary they can be left "as is". > But this is the way you were suggesting Export be changed, right? Yes. > Not sure which Pref you mean. The Pref I meant was the one in the title (a new "Export Directory" preference in the Directories Preferences). If the new Preference also applied to Export Labels and Export MIDI, then users exporting labels and MIDI would be able to choose the last used folder or a default folder, rather than be forced to the folder the file came from as now. No-one is asking for such an option. What they do want is audio file import and project open to export to the folder the file came from. >> 3) Export Labels should be fixed to display the name of the last imported >> label file if there was one, not display "labels.txt". This would do as a P4 >> if not fixed now. > Makes more sense to me to use the name of the last label track, rather than > implement tracking of what was imported when. I did that, r11886. Users have asked for the same behaviour as appears to them with audio tracks - import a file, export/overwrite it then the name of the file to be exported is prefilled (yes, I know from the project name). So they ask to import a label file, export/overwrite it, where the name of the file to be exported to is prefilled. They have not asked for the label track name to be filled with the name of the imported text file, but if that were possible, then with your change to use the track name to prefill the export name, wouldn't that fix everything? Reading the imported text file name to the label track name could be P4, I guess. >> The other two choices would be: >> * "Last used" (current behaviour) >> * "User-specified" (Browse button and text box) > Given the above, is this better than changing the way those prefs were > intended to work? > > On further thought, I don't really see how this is better than the > "Save in:" hierarchical pull-down menu in the current dialog (at least > on Windows). > > But I may have misunderstood, as both directory paths are already saved > automatically via gPrefs, so I thought this was about modifying those. > On further examination, by the title of this entry, did you mean add a > checkbox to the prefs dialog as an option, rather than eliminate the current > feature of tracking them separately? Yes I meant a three-choice Preference. One of those choices relies on the existing tracking of the last used export path directory. There is no problem I can think of with "DefaultOpenPath", so neither that or last used export path should change. > If so, I think it should default to the current behavior, as we don't have any > feedback from the people who like it as is, only those who don't. Yes, I considered defaulting to last used export folder as now, but that behaviour is very unpopular, and I would worry people would find the Preference to change it if it defaulted to "last used". If you look at the case of opening a project then Save Project As, this defaults to saving to the folder the project opened from. There are no complaints about that, nor about Export Labels and Export MIDI saving to the folder the file came from.
(In reply to comment #3) > [...] >>> Suggested that default would be to export to the directory the file came >>> from, and this would fall back to last used if there was no open or import >>> e.g. a recording. This satisfies the principal demand. >> This is a bit tricky. The intention in the code has been to remember im/export >> dirs separately, as "/DefaultOpenPath" and "/Export/Path". This fits the use >> case of, e.g., successively importing files from one directory, editing, then >> exporting to a different directory. Do we want to end the current ease of >> doing this? > > You mean "export to the last used directory" as now? We still want to cater for > this but I feel it is a minority case, so the idea was to make it one of the > non-default preference options. I see. > >> And by "no open or import" do you mean during the whole session, or since the >> previous export? There's currently no tracking of either. > I was definitely assuming it was per project, so closing a project, then > recording something, then exporting, would export to the last used export > directory, whatever it was. "/DefaultOpenPath" and "/Export/Path" are per .cfg, and I think that's what you're actually saying. "...export to the last used export directory" means the one exported to by the previous project and stored in the .cfg when it's closed, right? >[...] > >>> 2) Export Labels and Export MIDI already default to the folder the label or >>> MIDI file respectively comes from, so while it would be nice for the Pref to >>> also apply to these, if necessary they can be left "as is". >> But this is the way you were suggesting Export be changed, right? > > Yes. >[...] > If the new Preference also applied to Export Labels and Export MIDI, then users > exporting labels and MIDI would be able to choose the last used folder or a > default folder, rather than be forced to the folder the file came from as now. > No-one is asking for such an option. What they do want is audio file import and > project open to export to the folder the file came from. > Okay, so there seems to be scant reason to add them to the pref. > >>> 3) Export Labels should be fixed to display the name of the last imported >>> label file if there was one, not display "labels.txt". This would do as a P4 >>> if not fixed now. >> Makes more sense to me to use the name of the last label track, rather than >> implement tracking of what was imported when. I did that, r11886. > Users have asked for the same behaviour as appears to them with audio tracks - > import a file, export/overwrite it then the name of the file to be exported is > prefilled (yes, I know from the project name). So they ask to import a label > file, export/overwrite it, where the name of the file to be exported to is > prefilled. > > They have not asked for the label track name to be filled with the name of the > imported text file, but if that were possible, then with your change to use the > track name to prefill the export name, wouldn't that fix everything? Reading > the imported text file name to the label track name could be P4, I guess. Done, r11890. > >>> The other two choices would be: >>> * "Last used" (current behaviour) >>> * "User-specified" (Browse button and text box) >> Given the above, is this better than changing the way those prefs were >> intended to work? >> >> On further thought, I don't really see how this is better than the >> "Save in:" hierarchical pull-down menu in the current dialog (at least >> on Windows). >> >> But I may have misunderstood, as both directory paths are already saved >> automatically via gPrefs, so I thought this was about modifying those. >> On further examination, by the title of this entry, did you mean add a >> checkbox to the prefs dialog as an option, rather than eliminate the current >> feature of tracking them separately? > Yes I meant a three-choice Preference. Three? I thought it was either "Export to previous export directory" or not (default not). >One of those choices relies on the > existing tracking of the last used export path directory. There is no problem I > can think of with "DefaultOpenPath", so neither that or last used export path > should change. > ? I don't see why you wrote that. Not in question. If the pref is off (default), use "/DefaultOpenPath" (if non-empty) and "/Export/Path" if empty. If pref is on, use "/Export/Path". Right?
>>> And by "no open or import" do you mean during the whole session, or since >>> the previous export? There's currently no tracking of either. >> I was definitely assuming it was per project, so closing a project, then >> recording something, then exporting, would export to the last used export >> directory, whatever it was. >"/DefaultOpenPath" and "/Export/Path" are per .cfg, and I think that's what > you're actually saying. "...export to the last used export directory" means > the one exported to by the previous project and stored in the .cfg when it's > closed, right? Audacity tracks multiple exports per session. Open Audacity, record, export. Let's say it opens at C:\ per .cfg, so export to there. Export again (opens at C:\ , change it to D:\). Export again (it opens at D:\, not C:\ per .cfg). Can the Pref open at D:\ in that case, without closing the project first? >> Yes I meant a three-choice Preference. > Three? I thought it was either "Export to previous export directory" or not > (default not). The suggestion in the description http://bugzilla.audacityteam.org/show_bug.cgi?id=550#c0 was for two choices (apart from export to the directory the file came) * "Last used" (current behaviour) * "User-specified" (Browse button and text box) "User-specified" is a "nice to have" supported by some votes, but not the main request. Personally I would set it to a user-specified dir if there was such a pref. > If the pref is off (default), use "/DefaultOpenPath" (if non-empty) and > "/Export/Path" if empty. If pref is on, use "/Export/Path". Right? No. If you import a file, we want by default to export to the folder the file came from. Importing a file does not change the DefaultOpenPath to the folder the file came from. If we don't have tracking for where the file came from I believe it is what is being asked for. We track where the MIDI and label file come from, right, as that works?
(In reply to comment #5) >>>> And by "no open or import" do you mean during the whole session, or since >>>> the previous export? There's currently no tracking of either. >>> I was definitely assuming it was per project, so closing a project, then >>> recording something, then exporting, would export to the last used export >>> directory, whatever it was. >> "/DefaultOpenPath" and "/Export/Path" are per .cfg, and I think that's what >> you're actually saying. "...export to the last used export directory" means >> the one exported to by the previous project and stored in the .cfg when it's >> closed, right? > Audacity tracks multiple exports per session. Open Audacity, record, export. > Let's say it opens at C:\ per .cfg, so export to there. Export again (opens at > C:\ , change it to D:\). Export again (it opens at D:\, not C:\ per .cfg). Can > the Pref open at D:\ in that case, without closing the project first? Each export causes "/Export/Path" to be set. The file is written only on close, but the value is updated with each Write(), as I understand it. The flush() calls are only in a few places, though (but including OK from the Prefs dialog), so that may be a wider-spanning bug. If not, does this relate to other bugs of prefs being ignored? You wrote "it opens at D:\" then ask whether the pref can open at it at "D:\". So I don't understand what you're asking about. > >>> Yes I meant a three-choice Preference. >> Three? I thought it was either "Export to previous export directory" or not >> (default not). > The suggestion in the description > http://bugzilla.audacityteam.org/show_bug.cgi?id=550#c0 was for two choices > (apart from export to the directory the file came) > * "Last used" (current behaviour) > * "User-specified" (Browse button and text box) Aah, I read that "other two choices would be" as mutually exclusive alternatives. Please be explicit about three-choice, as most prefs are binary (checkboxes). > > "User-specified" is a "nice to have" supported by some votes, but not the main > request. Personally I would set it to a user-specified dir if there was such a > pref. I veto the User-specified, because the dialog already has the pull-down, so it's just more clutter. > >> If the pref is off (default), use "/DefaultOpenPath" (if non-empty) and >> "/Export/Path" if empty. If pref is on, use "/Export/Path". Right? > No. If you import a file, we want by default to export to the folder the file > came from. LOL. It's just amazing how much of the effort on this is figuring out what you mean! I read that as a "Yes"! Pref I suggested is "Export to previous export directory". If it's off (default), do not export to "/Export/Path", use "/DefaultOpenPath", which was set "to the folder the file came from" when the file was imported. But if we need to add those flush() calls, that would explain it. >Importing a file does not change the DefaultOpenPath to the folder > the file came from. If we don't have tracking for where the file came from I > believe it is what is being asked for. We track where the MIDI and label file > come from, right, as that works? > Really? I was going from the code, AudacityProject::OnImport() in Menus.cpp, line 5100, which writes it to gPrefs.
(In reply to comment #6) >> Audacity tracks multiple exports per session. Open Audacity, record, >> export. Let's say it opens at C:\ per .cfg, so export to there. Export >> again (opens at C:\ , change it to D:\). Export again (it opens at D:\, >> not C:\ per .cfg). Can the Pref open at D:\ in that case, without closing >> the project first? > Each export causes "/Export/Path" to be set. The file is written only on > close,but the value is updated with each Write(), as I understand it. The > flush() calls are only in a few places, though (but including OK from the > Prefs dialog), so that may be a wider-spanning bug. If not, does this relate > to other bugs of prefs being ignored? The only possibly relevant bug I can think of is bug 535 "Native Audacity formats won't import via FFmpeg until click OK on Preferences". > You wrote "it opens at D:\" then ask whether the pref can open at it at "D:\". > So I don't understand what you're asking about. You were talking about using the .cfg value for the Pref, but at the point in the steps that you quote, the value (in the .cfg file) is still C:\. So I was just seeking clarification that if we have an off-by-default Pref to export to the last used directory, export will still (as now) open to D:\ if you have changed to D:\ in that session. >> The suggestion in the description >> http://bugzilla.audacityteam.org/show_bug.cgi?id=550#c0 was for two choices >> (apart from export to the directory the file came) >> * "Last used" (current behaviour) >> * "User-specified" (Browse button and text box) >Aah, I read that "other two choices would be" as mutually exclusive >alternatives. Please be explicit about three-choice, as most prefs are >binary (checkboxes). I'm sorry if it was too short-circuited, Vaughan. The three choices were indeed to be mutually exclusive. * Directory the file came from, otherwise last used * Always last used (current behaviour) * User-specified (Browse button and text box) I did not suggest it but I would have presumed three radio buttons (the third with associated text box and button). >> "User-specified" is a "nice to have" supported by some votes, but not the >> main request. Personally I would set it to a user-specified dir if there >> was such a pref. > I veto the User-specified, because the dialog already has the pull-down, > so it's just more clutter. I agree the case is weakest for that, but a user-specified directory is not uncommon in programs. Most of the time this use case is already satisfied in current behaviour, because the user who wants a default export directory will normally export to that directory each time, so the export dialogue will open there. The problem comes when you change the export folder to something else for some specific purpose. As it is now, the next export afterwards, you have to change back to the directory you mostly use. With the suggested third option, you don't need to. >>> If the pref is off (default), use "/DefaultOpenPath" (if non-empty) and >> "/Export/Path" if empty. If pref is on, use "/Export/Path". Right? >> No. If you import a file, we want by default to export to the folder the file >> came from. > I read that as a "Yes"! Pref I suggested is "Export to previous export > directory". If it's off (default), do not export to "/Export/Path", use > "/DefaultOpenPath", which was set "to the folder the file came from" when the > file was imported. But if we need to add those flush() calls, that would > explain it. > > I was going from the code, AudacityProject::OnImport() in Menus.cpp, > line 5100, which writes it to gPrefs. As I see it, the problem is that dragging files into the interface never changes the DefaultOpenPath (so I figure that is more than a flush problem). I agree that File > Open, File > Recent Files or File > Import > Audio normally does modify DefaultOpenPath, so if reliable, would do what we want.
(In reply to comment #6) I just made a commit, r11893, that changes a lot of files. Many calls to gPrefs->Write() were never flushed until project close, and there's no need for that. Commit 11893 does a lot of Flush() calls, so that on all platforms, the pref change will now be recognized. Please test.
(In reply to comment #8) Thanks for all those changes, Vaughan. At my first test using r11893 on Win7 x64, launch Audacity, File > Open... to check DefaultOpenPath. It's S:\. Cancel Open. Drag in a file from C:\. File > Open... again, it still opens at S:\. Cancel Open. File > Close Project, DefaultOpenPath written as S:\ in .cfg. File > Exit, DefaultOpenPath written as S:\ in .cfg.
(In reply to comment #8) > I just made a commit, r11893, that... does a lot of Flush() calls, so that > on all platforms, the pref change will now be recognized. > Please test. Working through the list of changes in r11893 on Windows hasn't shown any other problems. No Preferences issues I am aware of have been helped by this. though.
(In reply to comment #7) > [...] >>> Audacity tracks multiple exports per session. Open Audacity, record, >>> export. Let's say it opens at C:\ per .cfg, so export to there. Export >>> again (opens at C:\ , change it to D:\). Export again (it opens at D:\, >>> not C:\ per .cfg). Can the Pref open at D:\ in that case, without closing >>> the project first? >> Each export causes "/Export/Path" to be set. The file is written only on >> close,but the value is updated with each Write(), as I understand it. The >> flush() calls are only in a few places, though (but including OK from the >> Prefs dialog), so that may be a wider-spanning bug. If not, does this relate >> to other bugs of prefs being ignored? > The only possibly relevant bug I can think of is bug 535 "Native Audacity > formats won't import via FFmpeg until click OK on Preferences". I think there are probably others, unreported. > >> You wrote "it opens at D:\" then ask whether the pref can open at it at >>"D:\". >> So I don't understand what you're asking about. > You were talking about using the .cfg value for the Pref, but at the point in > the steps that you quote, the value (in the .cfg file) is still C:\. So I was > just seeking clarification that if we have an off-by-default Pref to export to > the last used directory, export will still (as now) open to D:\ if you have > changed to D:\ in that session. Is that now working, per my additions to Flush() the Write()'s? > > >>> The suggestion in the description >>> http://bugzilla.audacityteam.org/show_bug.cgi?id=550#c0 was for two choices >>> (apart from export to the directory the file came) >>> * "Last used" (current behaviour) >>> * "User-specified" (Browse button and text box) >> Aah, I read that "other two choices would be" as mutually exclusive >> alternatives. Please be explicit about three-choice, as most prefs are >> binary (checkboxes). > I'm sorry if it was too short-circuited, Vaughan. The three choices were >indeed > to be mutually exclusive. I meant mutually exclusive as to implementation, i.e., implement only the "last open"/"last export" distinction. >[...] >>>> If the pref is off (default), use "/DefaultOpenPath" (if non-empty) and >>> "/Export/Path" if empty. If pref is on, use "/Export/Path". Right? >>> No. If you import a file, we want by default to export to the folder the file >>> came from. >> I read that as a "Yes"! Pref I suggested is "Export to previous export >> directory". If it's off (default), do not export to "/Export/Path", use >> "/DefaultOpenPath", which was set "to the folder the file came from" when the >> file was imported. But if we need to add those flush() calls, that would >> explain it. >> >> I was going from the code, AudacityProject::OnImport() in Menus.cpp, >> line 5100, which writes it to gPrefs. > As I see it, the problem is that dragging files into the interface never > changes the DefaultOpenPath (so I figure that is more than a flush problem). I > agree that File > Open, File > Recent Files or File > Import > Audio normally > does modify DefaultOpenPath, so if reliable, would do what we want. > Is that still the case, after all the Flush() calls I added?
(In reply to comment #11) >>>> Let's say it opens at C:\ per .cfg, so export to there. Export >>>> again (opens at C:\ , change it to D:\). Export again (it opens at D:\, >>>> not C:\ per .cfg). >>> You wrote "it opens at D:\" then ask whether the pref can open at it at >>>"D:\". >>> So I don't understand what you're asking about. >> You were talking about using the .cfg value for the Pref, but at the point >> in the steps that you quote, the value (in the .cfg file) is still C:\. >> So I was just seeking clarification that if we have an off-by-default Pref >> to export to the last used directory, export will still (as now) open to D:\ >> if you have changed to D:\ in that session. > Is that now working, per my additions to Flush() the Write()'s? It's working as before in the app (1 Open export dialogue, 2 change the export directory to D:\, 3 export, 4 open export dialogue again and it now opens at D:\). And yes that change to D:\ writes D:\\ to [Export/Path] in .cfg as soon as the Export File dialogue closes ( tested that with a very long export ). > I meant mutually exclusive as to implementation, i.e., implement only the > "last open"/"last export" distinction. Yes, I know you don't want to implement a default directory choice at the moment. >> As I see it, the problem is that dragging files into the interface never >> changes the DefaultOpenPath (so I figure that is more than a flush problem). >> I agree that File > Open, File > Recent Files or File > Import > Audio >> normally does modify DefaultOpenPath, so if reliable, would do what we want. > Is that still the case, after all the Flush() calls I added? I'm afraid so, as per http://bugzilla.audacityteam.org/show_bug.cgi?id=550#c9. If DefaultOpenPath is at C:\, dragging in audio files of any format from paths other than C:\ does not rewrite .cfg, nor does it change the directory that File > Open or File > Import > Audio opens to. File > Open..., File > Recent and File > Import > Audio... continue to reopen to the directory last opened to (as before), and now those actions always write to .cfg too.
(In reply to comment #12) Vaughan, from re-reading #550 I thought you agreed that dragging in files should change DefaultOpenPath in order to address the enhancement?
This bug 550 is strongly related to bug 1305 because it affects the export path that will be offered to the user. So as with 1305 (currently P2), this is promoted to P2 with the likelihood that it will be promoted to P1 after release of 2.1.3. The core request in the enh title has 36 votes on Feature Requests. There are 17 votes for "Just overwrite the imported file without any questions asked about name, format or options" which fixing bug 550 would help a little with.
My understanding is that what we have now a) on Windows defaulting to <username>\Documents\Audacity b) on Mac defaulting to <username>/Documents with Audacity subsequently remembering as and when appropriate - and using the defaults when appropriate. I recall no stream of ueser complaints since we made the changes to ensure that a writeable location was offered (previously the user was prompted to stare back in the directory folder where the app was installed). Accordingly I propose to close off the bug as WONTFIX or may be even INVALID not a bug.
Archived on https://wiki.audacityteam.org/wiki/Gale%27s_wish_list
