[Inquiry]GNUCash SoC - Implementing Undo
Nathan Buchanan
nbinont at gmail.com
Tue Mar 27 21:44:44 EDT 2007
On 3/27/07, akintayo holder <blakdogg at gmail.com> wrote:
>
> In the scenario given, It would not be possible to undo from account B as
> the state of the transaction would've been modified elsewhere.
Modified elsewhere, yes, but it's still the same user. I don't see why this
should be restricted to an account view, other than you indicate that it may
be simpler to implement. How much more difficult do you estimate a global
list would be?
I think it is the lesser of all evils, as a global list may involved undoing
> a transaction that isn't visible or switching to a different account view.
> If I were to Undo (3) I would need to show Account C or D by jumping to
> them, or I could just undo the change quietly. Both seem less than
> friendly
> to me.
How so? I believe Word/OOWriter/most text editors jump to the location of
the undo already.
A transaction based approach would cause issues with deletes, and bobbled
> operations where you cannot find the transaction you just modified usually
> because you don't know which one it is.
>
> On 3/27/07, Peter Selinger <selinger at mathstat.dal.ca> wrote:
>
> > 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
> > >
> >
> >
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
--
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Got Mole problems? Call Avogadro at 6.02 x 10^23.
More information about the gnucash-devel
mailing list