I came to this thread after reporting a “bug” that turns out to be a design decision. This one, about unmodified tracks.
I’m a user, not a developer. I’m multi OS aware using Linux, OS X, Windows, etc.
When it comes to user interface decisions, there’s a strong argument that the least confusing thing is to keep common operations the same across applications.
Microsoft word for example:
If you load a document from storage, then don’t modify it, it does not ask on close.
If you create a new document, then take another action like pasting data, it asks.
For Audacity the similar operation would be:
File->New then File->Import is dirty (set so by the Import).
File->Open (even if it first creates a “new” project), is clean.
File->New is clean.
The scenario where a beginner loads a file into audacity, deletes the original, then forgets to save their work, seems fanciful. Maybe it’s happened, but it’s not typical even for klutzes.
The current setup where Audacity asks on exit has an underappreciated failure mode. The knee jerk reaction (if it’s not confusion) could well be to accidentally hit yes, and THIS can destroy file dates and metadada, or at least get other people mad or confused if master audio files change.
Yes, we saw you already on feedback@. We already counted your “vote”.
What exactly are you looking at when you import a file? Is Audacity the only application you can use for that? Perhaps we can find another application you can use.
You are not an experienced Audacity support person as far as I know, so I assume you are not aware of users who have lost data or who regularly delete audio files as part of their stated workflow.
Some Team members here opposed one of the patches because it involved a hidden setting that you had to enable in audacity.cfg. If there had not been opposition, that patch would already have been implemented.
I have already said that I am prepared to open an enhancement issue on our bug tracker that includes Ed’s patch with the GUI options to hide save changes commented out. There is a problem with the GUI change implemented there that you can’t cancel the settings change in the main body of Preferences. Whatever the merits of the patch, the developers are then more aware of the “issue”.
It could be very confusing for Import and Open/New to behave differently in respect of making the project dirty. Open and Import are both imports, the only distinction is that Open opens a new window if the project already has content.
Clicking “Yes” to save changes does not change any data in the imported files whatsoever. As already stated, you are are NOT opening the files. You are making the project dirty by importing files into it, including changing the metadata stored by the project, if the imported file contains metadata.
The only way to change the imported file is to export over it.
There is a danger you did not point out, which is to say “No” to save changes, because you normally say it many times a day, when on that occasion you actually meant “Yes”.
The Gimp project recently went through a similar issue, dealing with saving of projects vs. content.
A Gimp session often starts by importing a JPG format image, as from a camera. But Gimp’s native project format is XCF.
The solution has some parallels to Audacity. In the Gimp case the program will harass you to either convert the file
to Gimp format, or to “export” it back to the original format. ( If nothing is modified it just silently exits quietly ).
Gimp also gives you a clue as to what happened, for example saying how many minutes since the JPG was imported,
and if the image was exported, where it was exported to. You get a good sense what you’re about to lose by not saving in XCF format.
\
Setting a preference is a form of admitting failure on a UI decision. They create a new class of error where a user
is at a studio or new place, and thinks they know what to expect from Audacity, but suddenly it’s different. That can lead to mistakes.
I use audacity for a variety of tasks, for which it is well suited. In particular I might load a master clip, and apply a series of test transformations, or maybe just enhance and listen to the audio. In those cases I never want to save over the original: if I decide to make a change I’ll first copy the master clip, then start working on the copy. Perhaps I should make the master clip read only right away, before loading it into audacity… but as a human I might forget.
A strength of audacity is suitability for multiple workflows. I feel no need to “find another application”.
Again, your imported files will not be affected by Audacity if you merely save a project.
Steve renamed the message from “Save changes before closing?” to “Save project before closing?”. Hopefully this will make it clearer that it is the project that is being changed, not the files.
It sounds to me as if you do, given the “Save changes” prompt is a major problem for you.
If we had a setting, but the user has newly installed Audacity on a different machine, then they go back to being prompted for unsaved changes after importing a file and doing nothing except playing it.
Steve wanted to turn Save Changes into a more advanced dialogue where if you had not done “editing” of some defined type, you would be offered the choice not to be prompted next time you imported without editing. Even that would be a setting. The problem is that many of our users on Windows can barely take in more than a few words of text in a message that pops up. The risk would be too great.
And if Audacity just quit silently when you had not edited in some sense, as you seem to want, the risk would be even greater.
Of course you can compile Audacity yourself and apply any patch you want, before we get to deciding what is the best approach for all our users.
That’s what makes this debate so strange. Why is is losing a project with no active edits considered a risk?
In the scenario under discussion, the binary audio clip is still on disk, and the project may have as few as zero history entries. All you’ve lost if listening is, perhaps, the position of the listen cursor.
The recent patch to change the dialog is an improvement. When it said “Save changes before closing?” that hardly communicated “Save the project not the clip”.
Still it’s a pain to keep clicking “no”, and that will lead to reflexively clicking “no” even when actual work has been done, and the proper answer is “yes”.
If you open a “project”, and then close that project without making any changes to the project, you are not prompted to save.
If you import a file into a project, then the import will be listed in the history and you will be prompted to save.
I think that at least some of the confusion is due to the warning message:
“Save changes before closing?”
and some of the confusion because Audacity can apparently “open” audio files.
Despite the fact that “File menu > Open” allows you to select an audio file (such as WAV, MP3, etc), Audacity does not “open” audio files. What happens is that a “project” is opened and the selected audio file is imported into the project. Personally I think it would be much clearer if “File > Open” was exclusively for opening projects, because projects are actually the only thing that Audacity can “open”. Any other file types are “imported” into a project.
So users mistakenly think that they have opened an audio file, and then see a warning “Save changes before closing”, which is (not surprisingly) surprising for the user because they “have made no changes to the file”. But the message is not warning about changes to the file - it should be asking if they want to save the “project”. It is the project that has changed, not the file.
Do you want to save the project? Perhaps you do, perhaps you don’t. It is standard practice that when an application has imported a file, it prompts the user to save, and it is standard practice that if an application opens a file and is then closed before any changes are made, then the application closes without nagging the user to save. Audacity follows this accepted standard. I think that if it were clear that’s what Audacity is doing, then there would be less complaints about the behaviour.
I think it would help if Ed would provide his patch with the GUI options removed, so that it is a hidden option that can be enabled in audacity.cfg. I know that is not what some of us want, but we have to start somewhere by creating a Bugzilla enhancement issue out of this, and a demo patch that someone may be encouraged to work on will help.
The commit on tcbrack’s fork seems not to be retrievable any more.
It REALLY goes against the grain for me to do something like this when I strongly disapprove! Nevertheless, I’ll revisit the code today; I have neither the time nor the desire to figure out how to Git so someone else will need to do that part of it.
I understand that, Ed. I would not have asked if I could have linked to tcbrack’s commit, but I’m guessing it would take me more time to figure how to comment out the GUI parts properly than it would take you.
Given the opposition expressed here, there won’t be any strong recommendation from me to commit the patch as is, but some developer could think “as is” is better than nothing. I still think that, but committing “as is” wouldn’t close the enhancement issue.
I’ve got working code of the “hidden preference” variety. Ignoring about 20 lines which need to be indented an extra tab, it boils down to about nine lines of code.
Unfortunately, this thread has gotten so long and ancient that I no longer really know exactly what Gale wants. My current code does this:
examine audacity.CFG for the entry:
[Warnings]
SaveProjectNag=XXX
if the value represented above as XXX is 1* then NEVER display the nag dialog; if it is 0 or not present then ALWAYS display the nag dialog.
No matter what, if XXX is 0 or not present the nag dialog will always display.
Potential options for if XXX resolves to TRUE (i.e. NEVER display) and the Project is NOT empty:
if the only user action has been to Import Audio then do NOT display the dialog
1a) if Preference setting Normalize on Import is YES then do NOT display the dialog
or
1b) if Preference setting Normalize on Import is YES then DISPLAY the dialog
* wxWidgets as a strange concept of what a Boolean Preference value is:
if XXX is 1 then the Boolean is “true”
if XXX is 0 then the Boolean is “false”
if XXX is 2 then the Boolean is “true”
if XXX is test then the Boolean is “false” if XXX is true then the Boolean is “false”
I pulled Head off of GitHub this morning (8 November 2016). @Gale – Ignoring about 20 lines of re-indentation this is about nine lines of code in two files. https://www.dropbox.com/s/tmnxbymqadgbw4o/nagGale.zip?dl=0
This is the very bare minimum – no GUI, uses a hidden preference and ubiquitously defeats the nagging dialog.
@Steve – 3 files; two of which have only one statement added to each. https://www.dropbox.com/s/alyi9r7bxgfoc7e/nagging.zip?dl=0
This one adds a GUI checkbox to Preferences and has some code for exploring the History/Undo buffer. This one ONLY defeats the nagging dialog if the user exercises the checkbox in Preferences AND if Import (and potentially the Automatic Normalization thereof) is the only item(s) on the buffer.
There’s one additional Preference setting which I have not explored – the nag about saving empty Projects. I suspect that it will interact with Steve’s logic but not Gale’s.
For Steve’s eyes only :
To make it easier to find where I made changes I did one of two things:
if it was only a single line of code it has a comment added that looks like this:
bool CleanEnough ();//don't nag to save empty project
if there are multiple lines affected code it looks like this:
if (!CleanEnough()) {//start don't nag to save empty project
[…]
}//end don't nag to save empty project
if the code (all of it multiple lines) pertains only to Steve’s request it looks like this:
//start for Steve don't nag to save empty project
S.TieCheckBox(_("nagging to save empty project"),
wxT("/Warnings/SaveProjectNag"),
false);
//end for Steve don't nag to save empty project
except the code at the very bottom of Project.cpp which looks like this:
//start don't nag to save empty project
bool AudacityProject::CleanEnough() {
[…]
//For Steve
[…]
//End for Steve
[…]
//end don't nag to save empty project
Thanks for the code hints Edgar. That’s saved me a lot of searching.
I’m not keen on using the “short description” to identify the undo event, because it could be a translated string (and for “Import” I think it is). Even if we use translated strings where necessary, it still makes the code fragile as we have no guarantee that descriptions won’t be updated (and who would think of looking here before updating a command’s description?).
Nevertheless, it seems easy enough to implement either “Never prompt to save project”, or “Don’t prompt to save unmodified import”. Making the option more selective (allow some commands and not others) looks a lot messier as we need to uniquely identify each white-listed command in a robust way, then check that all commands in the undo stack are white-listed.
I don’t know why this happens, I guess it’s a race condition and ‘not stopping to nag’ is tipping the balance. I don’t think we can proceed with this until bug 1545 is fixed.
Thanks, Ed and Steve. My only problems with the Preferences checkboxes were that I thought it dangerous to just put the control(s) directly in Warnings Preferences or in a new “Advanced” node in the Preferences tree. I think you said that trying to hide the controls behind an “Advanced…” button inside a Preferences pane meant that cancelling Preferences would not throw out the changes made in the “Advanced” dialogue.
“Never prompt to save project”, or “Don’t prompt to save unmodified import” seem to be good choices. Ideally I think the user should be able to choose between those two or always prompting. If we can only implement one choice I think it would have to be “never prompt” because otherwise it won’t fully stop the “complaints”.
If I get this bug 1545 crash on Windows or Mac I will comment in the bug report.
Conversely, “never prompt” is far more likely to lead to complaints about lost data. Personally I’d rather have people complain about the massive inconvenience and RSI of having to click the “No” button than complaints about lost data.
Sorry, I completely forgot about translating the strings – I’ve been working on a few large projects which do not do language localization. If we stick with the Short Description we need to use:
wxT(“Import”) and wxT(“Normalize”)
For a more robust solution we need to add a Boolean to the Effect class, along the lines of:
in Effect.h:
bool mAssumeClean
in Effect.cpp initialize it:
mAssumeClean = false
That way its classification is easily controlled and identified.
