[Inquiry]GNUCash SoC - Implementing Undo
Nathan Buchanan
nbinont at gmail.com
Tue Mar 27 22:10:34 EDT 2007
On 3/27/07, Ariel <asgnucash at dsgml.com> wrote:
<snip>
Let the user cherry pick which transaction to undo - it doesn't have to
> be in strict reverse order.
This sounds a bit complicated for the average user, if we do decide to let
the user cherry pick, we need to have a very clear UI/warning about undoing
transactions out of order. The fact is that most people think of things in a
specific order, and whenever we allow going backward (undoing) in a
different order, we need to be crystal clear about it.
Also, how would redo work (when it gets implemented)? Say a user makes
change 1, 2, 3 and 4. ,Then the user undoes change 1 then change 3. Does
redo redo change 3 then change 1? This may be difficult for the user to keep
straight.
The usual check, which was designed for multi-user undo would still apply:
> you can not undo a transaction if it's current state does not match it's
> old. Transactions like that would still be listed, but marked in some
> fashion - I guess by showing all three version: current, old, and undo.
>
> -Ariel
>
> > 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
> >
> _______________________________________________
> 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