[Inquiry]GNUCash SoC - Implementing Undo

[akintayo holder]

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 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
>