Bugzilla – Bug 1368
Enh: "Warning - Empty Project" would benefit from a "Don't show this warning again" checkbox
Last modified: 2018-08-20 11:51:43 UTC
The dialogue "Warning - Empty Project" would benefit from a "Don't show this warning again" checkbox. This is basically controlled by Preferences>Warnings - but many unskilled users don't venture into Preferences so this would aid them to easily turn it off. This would be especially useful now, as for 2.1.3 this flag also implicity controls behaviors in Timer Record where the default "on" setting causes odd-looking, not easily understood, behavior. We have one of these for "Save Project is for an Audacity Project not an audio file" to make it easy for unskilled non-Preferences users to easily reject future occurrences. Alternative solution would be to make the default for this flag to be "off".
I am strongly opposed to this "enhancement". As it says on http://manual.audacityteam.org/o/man/warnings_preferences.html "This warning can only be turned off in Preferences (not by a checkbox in the warning) because of the risk of accidental data loss if the warning is disabled." The reason that data loss is a danger is because users press [X] on tracks believing this "saves" the tracks. I believe there is actually a case to have a prompt if the user changed "Saving empty project" from checked to unchecked in Warnings Preferences. Peter, can you give your use case for closing tracks and saving as an empty project an "awful lot" and say why "its good practice to do so". I regard File > Save Project As... on a clean, never changed project as good practice, but there is no warning for doing that even if the warning for "Saving empty project" is enabled. If I wanted to create tracks before saving a project, then discard the tracks, save an empty project then work in it, I would do it by File > Close (no need to remove the tracks), no to "Save changes?" , then Save As. This way, there is no redundant data relating to the removed tracks in the project.
(In reply to Gale Andrews from comment #1) >Peter, can you give your use case for closing tracks and saving as an >empty project an "awful lot" and say why "its good practice to do so". No I never do that - it's always new project, Dave Project As - and that's to avoid Audacity using the Temp files. >The reason that data loss is a danger is because users press [X] on >tracks believing this "saves" the tracks. Whoa ... if they're thinking that maybe we need to do something to disabuse them of that misbegotten notion. Maybe a hovertext tool-tip on the X in the TCP woul help. Or maybe we need a "Confirm" dialogue (which can be dismiised from appearing in future) which asks if they're sure the y want to remove the track. But I'm surprised thay any Windows users think an X does anything except Close or Delete - certainly not effect a Save. Mac users could be forgiven as they are used to the red blob top-right.
(In reply to Peter Sampson from comment #2) > it's always new project, Dave Project As - and that's to avoid Audacity using > the Temp files. That is good, but as I said, there is never any warning for that, so does not require turning the empty project warning off. So can we close this issue now? We have not had any problems with users losing data in closed tracks after we added the save empty project warning, so perhaps leaving things as they are is the best solution.
(In reply to Gale Andrews from comment #1) > The reason that data loss is a danger is because users press [X] on tracks > believing this "saves" the tracks. Really? I find that hard to believe, but if that is the case then we must be doing something very wrong for users to get that impression.
(In reply to Gale Andrews from comment #3) >So can we close this issue now? We have not had any problems with users >losing data in closed tracks after we added the save empty project warning, >so perhaps leaving things as they are is the best solution. No, I do not want us to close this issue and leave things as they are. This issue surfaced recently because if an issue that you, Gale, raised when testing Mark Young's Timer Record enhancements. With default settings for this preference the user gets the odd behaver of 1) Timer Record 2) don't like that ... 3) Delette the track 4) restart Timer Record 5) User gets the error message telling they must "save or close the project and try again" Which you thought was nonsensical ad I agree - but it is technically "correct" Audacity behavior as te project is dirty at that stage. Setting the empty project warning to "off" allows step 5 above to restart, as most users would tgink it should do. The underlying issues are a) it's not obvious that this flag alos controls behavior in Timer Record b) the user has to go to Preferences to do that - and many of them don't venture there. So rather than having a "Don't show this warning again" for the empty project warning, as originally suggested, why don't we just reverse the deafault setting for the flag and have it "off" by default. Then hyper-cautious users can go to Prefs and turn it on if thay are worried at all about saving an empty project. Pesonally I don't see what the fuss is about saving an empty project and why we ever thought to warn the user of this. Remembe too there are good use cases for wanting/needing to save an empty project.
(In reply to Peter Sampson from comment #5) As you know, IMHO Timer Record should not have a requirement that the project be clean before starting a new Timer Record. The suggestion in this issue "don't warn again" was decided against at the time we added the warning. I don't see what has changed that makes it safer now to have "don't warn again". There are two different warning dialogues (when saving and when closing) that are covered by this warning preference. Those dialogues are already wordy, and the user may not have seen the other dialogue. I think "don't warn again" is too messy and too dangerous. We would be getting the old complaints occurring again if the save empty project warning defaulted off. I am not confident your suggestion of a warning when closing a track would make defaulting the warning off fully safe. Warnings always default on. That is the point of the warning, surely.
(In reply to Steve Daulton from comment #4) Please look in the -devel archives as to why this preference was brought in.
(In reply to Gale Andrews from comment #7) It seems to lead back to this post: http://audacity.238276.n2.nabble.com/exiting-empty-Project-dialogue-td255323.html
(In reply to Steve Daulton from comment #8) There is at least one thread earlier than that which is archived. See Markus Meyer here: http://audacity.238276.n2.nabble.com/Batch-preferences-options-td251797.html. Markus thought we could warn more directly when closing the track, and Richard suggested a Trash can icon instead of the [X}. Even then, you can "close" a track by Undo, so the empty project warning is still needed.
(In reply to Gale Andrews from comment #9) > See Markus Meyer here: > http://audacity.238276.n2.nabble.com/Batch-preferences-options-td251797.html. Thanks, that makes sense. Marcus wrote: > 1. User imports MP3 (or something). MP3 appears as track. > 2. User edits project and saves it. > 3. User "closes project" by clicking the [X] on the track button. > 4. User quits Audacity and is asked whether he wants to save changes. > 5. User is a bit confused (because he already saved the project) but > thinks "yes, why not?" and clicks "yes" > 6. Later on, user starts Audacity loads the project and finds that it is empty. I agree that is a genuine problem, but it seems to me that the issue is step 4. As Marcus describes the case, step 5 (user trashes his project) is a direct response to step 4 (Audacity prompts user to trash his project). Surely the prompt in step 4 is the culprit - we should not prompt a user to overwrite an existing project with an empty project. I agree that we should warn a user if they attempt to overwrite an existing project with an empty project, but: a) We should not have prompted them to re-save their project when it is empty. b) The risk that Marcus describes does not exist except where a project is being overwritten.
(In reply to Steve Daulton from comment #10) >> 1. User imports MP3 (or something). MP3 appears as track. >> 2. User edits project and saves it. >> 3. User "closes project" by clicking the [X] on the track button. >> 4. User quits Audacity and is asked whether he wants to save changes. >> 5. User is a bit confused (because he already saved the project) but >> thinks "yes, why not?" and clicks "yes" >> 6. Later on, user starts Audacity loads the project and finds that it is >> empty. > > I agree that is a genuine problem, but it seems to me that the issue is > step 4. As Marcus describes the case, step 5 (user trashes his project) > is a direct response to step 4 (Audacity prompts user to trash his project). > > Surely the prompt in step 4 is the culprit - we should not prompt a user to > overwrite an existing project with an empty project. > > I agree that we should warn a user if they attempt to overwrite an existing > project with an empty project, but: > a) We should not have prompted them to re-save their project when it is empty. So what should we have done? If they quit at step 4 and we don't prompt (as in the past), their project is still trashed. Nor can we assume they wanted the project to contain the track and silently undo Remove Track. Even if the [X} on the track was a Trash can and/or we warned about deleting the track when doing that left the project empty, the problem occurs at decision time when closing the project, so I think that is when the user should be warned. Unless someone has a new suggestion to make I think this enhancement should be regarded as unsafe and closed WONTFIX.
(In reply to Gale Andrews from comment #11) > If they quit at step 4 and we don't prompt (as in the past), their project is still trashed. No it isn't. Here's the steps again: 1. User imports MP3 (or something). MP3 appears as track. 2. User edits project and saves it. *** AND SAVES IT *** 3. User "closes project" by clicking the [X] on the track button. 4. User quits Audacity
(In reply to Steve Daulton from comment #12) (In reply to Gale Andrews from comment #11) >> If they quit at step 4 and we don't prompt (as in the past), their project >> is still trashed. > No it isn't. > Here's the steps again: > > 1. User imports MP3 (or something). MP3 appears as track. > 2. User edits project and saves it. > *** AND SAVES IT *** > > 3. User "closes project" by clicking the [X] on the track button. > 4. User quits Audacity I believe so few naive users would save at step 2 that I sailed right past that. So yes that user would be protected in the old case by no prompt. But now, everyone gets the chance to decide including those who do want to "clear the decks" to a fresh user space in a named project. As discussed with reference to disabling "Save Changes?" more generally, do we really want multiple different rules as to what constitutes a clean or dirty project, and to have to document those rules?
No steps to reproduce. An Enhancement request. Long comment trail. No consensus about 'correct behaviour'. CLOSED NOT-A-BUG.
