On Tue, Mar 27, 2007 at 10:52:14AM -0700, Beth Leonard wrote: > On Tue, Mar 27, 2007 at 02:07:03PM -0300, Peter Selinger wrote: > > > > I agree with Derek that operations should be undone in the order in > > which they were performed, i.e., at the book level, not the account > > level. > > I'll add my "me too" here. With splits it gets particularly > complicated. One of the things I most want to undo in GnuCash > happens when I'm editing a complicated split and as part of > that process I change (accidently or not) the account that I'm > using to view the split at the time. The whole thing suddenly > dissappears and I'm left with a "what just happened?" feeling -- > I know something's wrong but it takes me a little while to figure > out that my whole transaction just moved to another account view. > > I think undo has to work at a global level.
AOL! and I, from a user perspective, like the idea below as well. > > Naming the action that is going to be undone in the menu > item is a good start -- i.e. > Undo edit transaction > Undo delete transaction > Undo import prices > Undo import QIF > Undo change report options > Undo change account name > Undo delete account > > etc. This way the user has some idea of what is going to be > undone when they click that item. yup. > > The second most likely thing I want to undo is importing a > QIF or QXF file. I've taken to using save/restore just > in case the file I import isn't the file I thought it was. The other part of this thread wanders off into speculating whether undo'ing an import is a reasonable thing for a user to expect. I say, wholeheartedly, that it is reasonable. Regardless of the hoops jumped through on the backend, the undo criteria should be based on the user's experience in doing the action to be undone. The point at which something is atomically defined from the user's perspective should determine what is encompassed by one 'undo'. Whether that is clicking "import" or "okay" or pressing enter by the user, there is a point at which something is defined as "done" by the user... I should be posting this in the other part of this thread, but... maybe as a means to helping constrain the implementation of undo as something that can be done in one summer the undo framework can be setup as a sort of client-server model. the undo "server" can provide hooks for the other parts of gnucash to grab when an undo-able event has happened. The details of that event are fed from the "client" to the "server". the "SErver" stores these items and is only concerned with the implementation of the undo. it is up to the "client" to provide clean data to the undo server so that it can later provide the undo service. Undo features can then be added to gnucash piecemeal as different parts of the code get worked on. that's my .02 on something about which I know not/naught. A
signature.asc
Description: Digital signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel