[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