On 3/27/07, Ariel <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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" <[EMAIL PROTECTED] > 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 < [EMAIL PROTECTED]> wrote: > >>>>>>>> > >>>>>>>> Ariel < [EMAIL PROTECTED]> 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 > >>>>>>>> [EMAIL PROTECTED] PGP key available > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> gnucash-devel mailing list > >>>>>>> gnucash-devel@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 > >>>>>> [EMAIL PROTECTED] PGP key available > >>>>>> > >>>>> _______________________________________________ > >>>>> gnucash-devel mailing list > >>>>> gnucash-devel@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 > >>>> [EMAIL PROTECTED] PGP key available > >>>> > >>> _______________________________________________ > >>> gnucash-devel mailing list > >>> gnucash-devel@gnucash.org > >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > >>> > >> > >> > > _______________________________________________ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Got Mole problems? Call Avogadro at 6.02 x 10^23. _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel