[Inquiry]GNUCash SoC - Implementing Undo

[Peter Selinger]

I fully agree with Derek. The main reason someone would want to undo
an Import is that the Import was messed-up somehow - wrong account
created; wrong currency; wrong file imported, etc.

It does not make sense to undo the steps of an import one by one,
because those steps were not performed in any well-defined order. 
There is no meaning from a user's point of view to undo "half" an
import or the "last" transaction of an import. 

Moreover, there is no need to cherry-pick and undo individual
transactions of an import, because an import only creates
transactions, it does not modify them. So to revert some particular
transaction, the user can simply delete it. 

Also keep in mind that the main reason for any "undo" feature is to be
able to drop all the "are you sure you want to do this" dialogs. The
philosophy is: let the user perform any operation they want, without
asking for confirmation, and if it isn't what they wanted, then they
can undo it easily. For this reason, it is customary and sufficient
that "undo" always undoes the *last* action performed, or perhaps the
last few. 

The cherry-picking feature suggested by Ariel is an entirely different
feature that is in some sense orthogonal to "undo". While it might be
nice to be able to view the edit history of particular transactions,
and to "revert" a chosen transaction to an earlier state, I do not see
this as part of "undo"; actually, it is just another user action that
should itself be undoable.

"Redo" is not quite the same as "Undo twice", because by default,
doing "undo" twice should undo the last two actions, not undo and redo
the last action. 

See the excellent discussion of an Undo design by Karl Chen on Feb 22
on this mailing list, and the ensuing thread until Feb 28. 

-- Peter

Derek Atkins wrote:
> 
> Quoting Jeff Carneal <jeff-ml at carneal.com>:
> 
> >
> > On Mar 28, 2007, at 6:05 AM, Derek Atkins wrote:
> >
> >>
> >> And a "File -> Import" would be an "easily identifiable atomic  operation".
> >> You did "File -> Import -> xxx" and followed a series of steps and  then
> >> clicked "Done" or "Finish" or "Import" and gnucash did some magic.
> >
> > Except that the "magic" is what must be undone, not what you clicked, 
> >  and it is decidedly less atomic.
> 
> Not from most user's perspective.  Even I, who knows quite clearly
> what's going on under the covers, want an "import" level atomic undo,
> to undo the whole import at once.   Other applications do this, too.
> For example, take the "undo" in emacs....  If you're typing along emacs
> does a pretty good job of quantizing your inputs for its undo list.  But
> if you import a large document into your current buffer, that import
> is a single quantum, regardless of how many characters/lines it is.
> 
> >> I don't know how much more atomic you can get from a user's  perspective!
> >
> > The user's perspective is that a number of things happen on import.   
> > Presumably, lots of transactions, new accounts created, new  
> > commodities, etc.  Which one would you like for them to single out  
> > for the purposes of atomizing it in their minds?
> 
> I agree that from a DEVELOPER'S perspective a number of things happen
> on import.  From a user's perspective it was just an import operation.
> Go ask your mom what she thinks about it; I can tell you how MINE would
> answer.  The "import operation" is the appropriate quantum for importing.
> The "transaction" is the appropriate quantum when editing a transaction.
> Maybe even Splits are appropriate when editing a multi-split transaction.
> 
> The point I'm trying (and clearly failing) to make is that the quanta should
> be tied to the actual user operation, be it creating a new account, editing
> a Customer, modifying a transaction, clicking "get quotes", or running
> a QIF Import.  The Undo quanta should change based on the operation.
> 
> > My point isn't that it absolutely shouldn't be done, but rather that  
> > I doubt most users have the expectation of being able to undo a full  
> > import.
> 
> I've been involved here for a long time; I think you're wrong, but I'm
> willing to be convinced otherwise.
> 
> I think the undo quanta needs both size and locality to the user operations.
> Knowing what happens under the covers muddies the waters, so look at it
> from "what did the user do", not "what happened when user did it".  Maybe
> that will frame it for you?
> 
> Thanks,
> 
> > Jeff
> 
> -derek
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>