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 <[EMAIL PROTECTED]>: > > > > > 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 > [EMAIL PROTECTED] PGP key available > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel