Neil Williams <[EMAIL PROTECTED]> writes:
> David Hampton wrote:
> | I can see multiple undo lists within one application working, but it
> | will need to be well documented.
>
> If the undo list is retained within the book and only referenced from
> that book, this would provide sufficient segregation.
I presume by "retained" you mean "in core" and not "in storage"...
IMHO the undo/redo list should be size-bounded, not unlimited.
Also, it should not necessarily depend on the dirty flag. It should
be independent of the individual dirty flags. The reason: SQL. In a
SQL backend the data is necessarily never dirty (because it's saved on
every Commit operation. e.g. every time you commit a txn your changes
are saved). BUT if I make changes I might want to back out those
changes.. Hense the "undo".
-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
