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. 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 > > > >> > [email protected] > > > >> > 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 > > > > [email protected] > > > > 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 > > [email protected] > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
