[Inquiry]GNUCash SoC - Implementing Undo

[Andrew Sackville-West]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070328/e32a06d2/attachment.bin