On 3/27/07, akintayo holder <[EMAIL PROTECTED]> 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.
Modified elsewhere, yes, but it's still the same user. I don't see why this should be restricted to an account view, other than you indicate that it may be simpler to implement. How much more difficult do you estimate a global list would be? 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. How so? I believe Word/OOWriter/most text editors jump to the location of the undo already. 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 > > > > >> > 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 > -- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 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