[Inquiry]GNUCash SoC - Implementing Undo

Peter Selinger selinger at mathstat.dal.ca
Tue Mar 27 13:07:03 EDT 2007


akintayo holder wrote:
> 
> Hi,
>   I agree with your points, except for the single GList. I think Undo needs
> to be local in context. In other words if I Undo from a given register, it
> should only undo the operations made from that view even if they do not just
> impact this view. So it must be possible to associate an undo with a
> view/account.

I don't think the idea of a view-local undo will work. Suppose you
have a transaction as follows:

Account A: +100
Account B: -100

(1) Then you change it, from the Account B view, to:

Account C: +100
Account B: -100

(2) Then you change it, from the Account C view, to:

Account C: +100
Account D: -100

(3) Then you change it, from the Account C view, to:

Account C: +200
Account D: -200

Now suppose you hit "undo" in account B. What exactly do you expect to
happen? Should edits (1)-(3) be undone at once? Or only edit (1),
without undoing (2) and (3)? Or none of them? What if you made some
other changes in account C after (2) and (3)? Should they be undone as
well?

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. 

Alternatively, if a local undo operation is absolutely necessary, then
it should be associated with transactions, not with accounts (i.e.,
undo the last change in the highlighted transaction).

-- Peter


> I would prefer to maintain list for each account, rather than search a
> global list for undos associated with the type/view. I do see a problem with
> this approach, but the headache due to multiple lists seems equivalent to
> the managing a global list. In the global case you would need to be aware of
> the view/account and maintain positions in the list for each of these, and
> similar complexity when updating the lists etc.
> 
> With Import I would assign it to the containing Account Hierarchy. I would
> be tempted to do so with most dialogs like Price Editor and Security Editor.
> Reports would be treated to its own GList, as if it were an account.
> 
> Akintayo
> 
> 
> On 3/25/07, Derek Atkins <warlord at mit.edu> wrote:
> >
> > Um, but which account do you associate it with?
> > When you Undo don't you want to undo from the UI, not on a per-account
> > basis?
> > And what about something like a QIF Import, which really should be an
> > atomic do/undo object?  Where would you store that info?
> >
> > Keep in mind that Undo does NOT need to be persistent.  As soon as
> > you quit the application it's perfectly reasonable to lose your ability
> > to undo.  Think about the "emacs" undo operations as a decent model.
> > Or Open Office.
> >
> > Personally I STILL think it's better to just have a GList in the
> > session and base your Undo list on that.  I think putting it into the
> > account would just cause much more confusion and probably not solve
> > all the problems.
> >
> > Keep in mind that users want to "undo" changes that aren't necessarily
> > transaction input!  You might want to undo, e.g., a PriceDB entry, or
> > a new Customer, or an Invoice entry, or...  Lots of things that don't
> > touch Accounts.
> >
> > Just something to think about.  Getting the architecture right is
> > important to success.
> >
> > -derek
> >
> > "akintayo holder" <blakdogg at gmail.com> writes:
> >
> > > The reason I like Undo being associated with an account is the simple
> > way in
> > > which to enforce context. So an Undo could not impact a hidden account
> > in an
> > > unexpected way. Since accounting transactions affect at least two
> > accounts,
> > > grouping by account was more of an interface concession.
> > >
> > >
> > >
> > >
> > > On 3/23/07, Derek Atkins < warlord at mit.edu> wrote:
> > >>
> > >> I'm not convinced that the Undo feature belongs to an account.  There
> > >> are other (non-account-based) operations that should be undoable,
> > >> such as changes to the PriceDB, direct Transfer Dialog entries, or
> > >> even changes made via File -> Import.  I think the Undo log should
> > >> be part of the Book (or maybe Session), and there needs to be a way
> > >> to group operations together into the atomic undo operations.
> > >>
> > >> The rest of your statement I agree with, that Undo should check that
> > >> the state is correct before it allows the undo..  Same for Redo.
> > >>
> > >> Thanks,
> > >>
> > >> -derek
> > >>
> > >> "akintayo holder" <blakdogg at gmail.com> writes:
> > >>
> > >> > Hi,
> > >> > Its seems that with respect to multi-user transactions and Undo, the
> > >> first
> > >> > step would be to enforce this rule; A transaction cannot be Undone if
> > >> the
> > >> > state of the record does not match the state after the original
> > >> transaction
> > >> > had completed. For example, you can only Undo an account creation if
> > the
> > >> > account was still empty.
> > >> >
> > >> > I would implement the update history as an account associated data
> > >> structure
> > >> > which is stored in memory. A local history would allow undos to be
> > >> performed
> > >> > by simply traversing the account's list and picking the next change.
> > >> Anyway,
> > >> > this approach would mean that updates from other users are not
> > >> aggregated in
> > >> > one list.
> > >> >
> > >> > Thanks for the comments.
> > >> >
> > >> > Akintayo
> > >> >
> > >> >
> > >> >
> > >> > On 3/21/07, Derek Atkins <warlord at mit.edu> wrote:
> > >> >>
> > >> >> Ariel < asgnucash at dsgml.com> writes:
> > >> >>
> > >> >> > It seems to me that an undo in a multi-user environment should be
> > >> >> exactly
> > >> >> > equal to the user deleting (or changing, etc) the transaction
> > >> manually
> > >> >> > back to what it was.
> > >> >>
> > >> >> As pointed out, this isn't completely true.  In a multi-user
> > >> environment
> > >> >> another user may have updated the transaction so your "undo"
> > shouldn't
> > >> >> silently discard their changes.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >> Meaning the log file would first show a 'do' transaction and later
> > >> would
> > >> >> > show an 'undo' transaction, rather then the transaction not
> > showing
> > >> up
> > >> >> in
> > >> >> > the log at all.
> > >> >>
> > >> >> This is true..
> > >> >>
> > >> >> > It's not exactly how undo on an editor works, but I think it's the
> > >> right
> > >> >> > thing for gnucash. One consequence is that if you do something and
> >
> > >> then
> > >> >> > undo it, gnucash will ask you to save the file, while in an editor
> > it
> > >> >> > wouldn't.
> > >> >>
> > >> >> Well, in a multi-user environment you're certainly using a DB, so
> > there
> > >> >> would be no "save".  Each Do/Undo would effect a save to the DB.
> > >> >>
> > >> >> >       -Ariel
> > >> >>
> > >> >> -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
> > >> >
> > >> >
> > >>
> > >> --
> > >>       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
> > >
> > >
> >
> > --
> >       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
> 



More information about the gnucash-devel mailing list