On Tue, 27 Mar 2007, akintayo holder 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. > > 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. > > 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.
I think you are thinking too much like an editor. Undo transactions are recorded in the log (in order to make multi user gnucash work). When you undo a transaction it's a visible and recorded change, not just a simple 'change the entry directly'. I suggest you create a dialog which shows the before and after view. It would have two panes: on top a list of all the transactions affected as they exist now, and on bottom what they will look like after. For things like undo an import, the top pane will have a long list of transactions, and the bottom one will be empty. Or perhaps, since you never delete/add transactions and modify them simultaneously (I think?), have three views: a changed, an added, and a deleted, transaction undo screen. Personally, I would like to be able to browse back and forth through the undos, and I think this will work well: on the left a list of possible undo's, on the right the screen I mentioned above showing what the undo changes. Let the user cherry pick which transaction to undo - it doesn't have to be in strict reverse order. 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