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
