Re: [Audacity-quality] Delete Undo History

[Peter S. <pet...@gm...>]

On Tue, Dec 1, 2020 at 5:43 PM James Crook <jam...@gm...> wrote:

> The version of 'Compact' I disabled had two problems.
> As an experienced user, I found those two problems no issue at all.
> An inexperienced user, I could see, could find them problems.
>
> Problem 1: The history said 'compact' whereas the reality was that undoing
> the compact step undid multiple steps.
> Problem 2: 'Compact' on its own didn't actually free up as much memory as
> would 'save and close/exit'.  A user looking to free up unneeded memory
> could/would reasonably expect that compact would be more aggressive.  It
> though can't be that aggressive, because one can exit audacity without
> saving, and in such cases one must be back to the last saved state.  We
> have to keep info for the last saved state around to allow a future exit
> without saving.
>
> Paul's right that Problem 1 on its own could be easily solved, provided we
> all agree on what the terminology should be.  As RM I could then live with
> some users being surprised that they had lost fine details of their undo
> history.  They wouldn't have lost the current state and they wouldn't have
> lost the last saved state.  The wording in history/menu would at least
> suggest what would happen, so it wouldn't be such a surprise.
>

But the problem here is that the user who just uses Ctrl+Z shortcut or the
Undo command in the Edit toolbar
would not get the benefit of the revised terminology .

Personally I could live with this - but I'm aware enough to make sure I
have sufficient disk space/

But I worry for:
a)  the users who get confused
b) the Forum elves who have to deal with and assist such users.

We do not need to be making any more bear-traps in Audacity - we have
plenty enough already.  ;-)

Peter.



> Problem 2 isn't so easily solved.  My view is if people are that tight for
> memory, save and close/exit is better than what compact offered.  Removing
> compact 'solves' problem 2 more easily than new user interface that makes
> sure (somehow) that users know what to do to free up more memory.
>
>
> Steve is concerned that both compact and the ability to discard history
> are gone.
> The mechanism for discarding history was fine grained, and
> overcomplicated.  As RM, I'm OK with it having gone.  Users can save and
> exit/close and that will discard history, and will compact.  Its absence,
> in my view, is arguably P4, or maybe not a bug at all.
>
>
> At the moment (as RM) I'm not seeing a reason to bring back compact, or to
> bring back discard-history.
>
> I am open to suggestions for cleaner behaviour.  I'd like to steer users
> towards saving, dicarding history and compacting, as 'one step' as that
> gives the biggest saving in space.  In my view it is what people who have
> run out of space most need.
>
> --James.
>
>
>
>
>
>
>
> On Tue, 1 Dec 2020 at 16:25, Paul Licameli <pau...@gm...>
> wrote:
>
>>
>>
>> On Tue, Dec 1, 2020 at 7:42 AM Peter Sampson <
>> pet...@gm...> wrote:
>>
>>>
>>>
>>> On Mon, Nov 30, 2020 at 10:38 PM Paul Licameli <pau...@gm...>
>>> wrote:
>>>
>>>> I still think it best and easiest to declare 2600 not-a-bug and put
>>>> Compact back.
>>>>
>>>> I still insist that the complaint in 2600 does not make sense.  I do
>>>> not understand why it is wrong behavior, much less "data loss" when nothing
>>>> is lost if you undo but can still redo.  I think Peter alone considers it
>>>> data loss.
>>>>
>>>
>>> Then let me explain again why 2600 can represent potential "data loss" -
>>> and thus why James'
>>> resolution (as RM) was to disable Compact Project - at least for 3.0.0
>>>
>>
>> I think James did this only because you, Peter, remained so
>> irreconcilable and we need to move on with the P1 list.  Not because we all
>> agree with you.  I don't, and I don't think Steve or James really do.
>>
>>
>>>
>>> 1)  In the Steps to reproduce I have a simple chirp project and each
>>> applied effect makes a clearly
>>> visible change to the waveform - thus it is easy to spot the state being
>>> reverted to, and as was QA
>>> testing I was looking extremely carefully.
>>>
>>> In real life use editing changes to that waveform and difficult (or
>>> almost impossible to spot) and thus Ed
>>> the user who used Unbo after compaction could unknowingly lose data by
>>> reverting to a state they did
>>> not intend (and note carefully: it's not just Undo immediately after
>>> Compaction, it can be Undos
>>> long after compaction as mu testing showed).
>>>
>>>
>>> 2) If the user uses Edit>Undo then they might get some clue as to what
>>> might happen (depending on
>>> the wordoing of what is on the History stack).
>>>
>>> 3) However if the uses used the Undo tool in the Edit toolbar, or the
>>> shortcut Ctrl+Z, then they are offered
>>> no textual clue as to what is to be actually Undone - and thus what
>>> state the project might be in afterwards.
>>>
>>
>> Yes, and the fix we were talking about was simply to amend that text to
>> give the user a better clue.  I would have done that very soon but for
>> James' intervention.  Really, do that, and it defeats all the objections.
>>
>> I don't find the argument about user confusion to be strong at all.  You
>> know what you are doing when you use undo and redo commands.  You are
>> changing the current state of the project.  We just need to amend the
>> associated names shown in the dialog and menu.
>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> Let us remember the history of this development.
>>>
>>> A) In Leland's original implementation of Compact Project up to and
>>> including Audacity 3.0.0 d49a888
>>> i) the entire History was discarded - this done to facilitate maximum
>>> compaction
>>> ii) the user was clearly told in the dialog that they would lose their
>>> entire Undo History
>>> iii) Undo was inaccessible and grayed out
>>> i) The Manual tells (told) the user that they would lose their entire
>>> Undo History
>>> This was a nice clean, simple to understand, action
>>>
>>
>> What Leland may have done is not sacred and immutable.  It is an
>> irrelevant objection if you say we depart from that initial design, when
>> initial design was discovered to be incomplete with Bill's testing.
>>
>>
>>>
>>> B) Then Bill discovered the edge case of P1 Bug 2579
>>> *Bug 2579* <https://bugzilla.audacityteam.org/show_bug.cgi?id=2579> - Exiting
>>> Audacity after edits and compaction results in a corrupted previously saved
>>> project
>>> This was obviously NOT a good thing and needed to be addressed.
>>>
>>> C) You, Paul, then decided to fix 2579, but in a way that totally
>>> changed Leland's original implementation
>>> leading to the "weird" behaviors reported in Bug 2600 (and discussed
>>> above).
>>>
>>
>> Yes, it's not the original behavior any more.  SO.  WHAT.
>>
>>
>>>
>>> I would fully support the reintroduction of Compact project *provided*
>>> that it adhered to the original implementation
>>> that Leland discussed and agreed with us
>>>
>>
>> No. Originalism is an irrelevant criterion.  Defend the design on its
>> actual merits and lack of defects, not merely because it was the original.
>>
>> But the original design did have a serious defect and so needed change.
>>
>>
>>>
>>> and provided that we could find a way to solve Bug 2579 without
>>> changing Lelan's original implementation.  If however this is a circle
>>> that cannot be squared (as you seemed to
>>> suggest, Paul ,when making your changed implementation) then I would not
>>> support its reinstatement.
>>>
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> OK so let's go back to basics and consider if we really need a Compact
>>> Project command at all
>>>
>>> 1) Audacity project with the old AUP/Pile-of-Files structure aso grew
>>> the size of the project's _data
>>> folder as Undos were added to the History stack - and no IRL user has
>>> ever noticed or complained
>>> about this.  And this gets vacuumed on Exit from the project.
>>>
>>> 2) OK so we know from Stev's tests that AUP3 can take up even more room
>>> - up to 50% more.
>>> But set against that is the fact that large disks are much more common
>>> and much cheaper these days.
>>>
>>> 3) We also have a set of good safety mechanisms for users who do manage
>>> to fill the drive their
>>> active project is on.  You did most of that work and we in QA did a LOT
>>> of testing - we are very confident
>>> that in those situations most sensible users should be able to salvage
>>> their projects.
>>>
>>> 4) I find myself doubting of most users would bother to use it (I never
>>> did when I was using 3.0.0 alphas for
>>> my production work - I knew I had a big enough disk)
>>> i) many users wouldn't realize it was there or what it was for
>>> ii) expert users might shy away as it is fairly time consuming to run a
>>> compaction on a large project,
>>> So after a couple of tries they may neve bother again.
>>>
>>> 5) The project is properly compacted on Exit from Audacity.
>>>
>>
>> Actually no, there is code that proceeds with compaction on exit only
>> when a prior estimate of space savings is at least 20%.
>>
>>
>>>
>>> 6) There is a simple workaround based on 5)
>>> Exit Audacity > relaunch Audacity > reopen your project
>>> And I documented this in several places in the Manual.
>>>
>>
>> Why impose this inconvenient roundabout to recover saved state when we
>> might make it much easier to do just with undo/redo?  Defending this
>> inconvenient path to the same result as adequate is also not understandable
>> to me.
>>
>>
>>>
>>> So my assessment of this is that Compact Project command is a
>>> nice-to-have and not a must-have.
>>> It is something that we can happily live without gor 3.0.0 (as we have
>>> lived without it for all previous
>>> versions of Audacity).
>>>
>>
>> Your objections are still very weak in my opinion, and I don't think they
>> convince us all either.
>>
>> Steve's question again, if Compact Project is not there, should the
>> retracted feature for purging of undo history with the Undo History dialog
>> instead be put bac?
>>
>> PRL
>>
>>
>>
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>
>>>
>>>> PRL
>>>>
>>>>
>>>> On Mon, Nov 30, 2020 at 8:00 AM Peter Sampson <
>>>> pet...@gm...> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 30, 2020 at 12:54 PM Steve Fiddle <
>>>>> ste...@gm...> wrote:
>>>>>
>>>>>> Up to and including Audacity 2.4.2 we had the ability to delete Undo
>>>>>> History. This had more bells and whistles in later versions, but the basic
>>>>>> ability has been available for a very long time.
>>>>>>
>>>>>> It was removed in 3.0.0 and replaced with "Compact", but now
>>>>>> "Compact" has been removed.
>>>>>>
>>>>>> Can we have at least a basic "Delete Undo History" restored?
>>>>>> If not, then I think this has to be logged as a regression.
>>>>>>
>>>>>
>>>>> And if we did, we'd have to make pretty darn sure that it didn't
>>>>> re-introduce the nasty fringe bugs/conflict
>>>>> issues from Compact. which led to its withdrawal.
>>>>>
>>>>> The workaround is dead simple:
>>>>> 1) close Audacity
>>>>> 2) Re-launch
>>>>> 3) Re-open
>>>>>
>>>>> Peter.
>>>>>
>>>>>
>>>>>
>>>>>> Steve
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> Aud...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> Aud...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>