On Fri, Feb 23, 2007 at 12:53:41PM -0400, Peter Selinger wrote: > As I understand it, in a large GnuCash installation, multiple users > could access the same backend database. The lock-edit-commit mechanism > prevents conflicts. > > So what should be the default behavior of U2 and U3 (undo or redo) if, > for example, the transaction has meanwhile been edited by another > user?
could you, depending on how long the undo queue is, maintain locks until the transaction leaves that queue? I suppose that leaves an ever growing list of uncommitted actions and the potential for more and more data loss if there is a problem. A > > -- Peter > > Karl Chen wrote: > > > > > > Hi Gnucash developers, > > > > First, excellent work - Gnucash is awesome. I especially > > appreciate the book data format which has allowed me to make batch > > changes externally. > > > > I have a wishlist request: Undo functionality. I think Undo > > (various levels described below) would add a LOT to usability. > > > > I've searched the mailing lists and Bugzilla and only found > > something about CashUtil, which seems abandoned. I'd like to > > request and add a Bugzilla wishlist item for Undo functionality in > > Gnucash. > > > > It's especially easy to lose text because of the auto-complete > > feature. It's easy to accidentally change the account of a split > > and then have to hunt around to find it. If you accidentally > > change an amount or date field, even if you realized what you just > > did, you might not remember the value to revert to. I often have > > to look in backups just to get back a value I accidentally > > changed. (I version-control the account file so at least I can do > > this reliably.) > > > > I see the following kinds of Undo with increasing utility and > > implementation difficulty: > > > > U1. Undo in account register entry fields (text, date, account, > > amount, etc.) while editing a transaction. > > > > U2. Undo for transaction insert, delete, modify, after the > > transaction has been committed. > > > > U3. Undo for larger or more complex operations, such as deleting > > an account. > > > > Lack of U1 is a big hit to usability - it's almost a standard in > > GUI applications, since default widgets support this. > > Implementation of U1 is the easiest since it's "widget-local". > > The next level, U2, is harder, but would also improve Gnucash a > > lot. The "please confirm" dialogs would be obsoleted by U2. U1 > > and U2 have orthogonal implementation, and having U2 is almost as > > good as having both U1 and U2 since you can save and undo the > > entire transaction. > > > > Even just single-level undo would help a lot, though sequential > > undo (and redo) would be even better and is worth the extra > > marginal effort. > > > > For an example of a project with great Undo support, see Gimp. > > You can undo pretty much any operation; nothing requires > > confirmation. > > > > Thanks for reading so far and I would love to get feedback. > > > > -- > > Karl 2007-02-22 14:15 > > _______________________________________________ > > gnucash-devel mailing list > > [email protected] > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >
signature.asc
Description: Digital signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
