CLI undo edit?

[Neil Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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've been trying to keep the gui
| organized so it can support multiple open books.  The idea is that any
| given window will only have pages from a single book.

I can see problems there: an entity cannot access another entity from
another book directly, it needs to store a reference, especially if any
one book can be written out without any of the others.

Periods of time fit more easily into multiple books.

This is all going to take time to develop and test.

What do you seek to achieve by this use of multiple books? Lookup speeds?

If period closing is sorted out, a standard book will be fine.

Conceptually, from a user point of view, I don't see how a book for a
single Account would be useful. Queries also concentrate on searching
within a single book - such small books may be fast but it's hard to see
how data could be aggregated to provide summaries and overviews.

Or are you talking about multiple *main* windows of GnuCash?

|  If you open a
| second book, you must open a second window.  I need to figure out how to
| integrate the account hierarchy druid code with this, because it creates
| a temporary book for the life of the import process.

I'm not sure it can, yet. I'm also not sure about such books, except for
import/export as with QSF. References between entities need careful
handling - look how long it has taken to get partial books and
references sorted out in QSF.

I think what you are looking at is similar to QOF applications like GnoTime.

| 	If it's limited to one undo operation per entity then a
| 	hashtable indexed on the GUID could work. That's the first
| 	option, not perfect but probably quite fast. A second change
| 	in the same entity would overwrite any previous ...
|
| I misread this to imply that you were keeping changes on a per-entity
| basis.

I was actually hinting at the problems with a GHashTable approach which
overwrites the value (the changed data) of any existing key (the GUID).
One hashtable indexed by GUID's would only allow one undo operation for
each entity listed in the hashtable.


- --

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC9nmik7DVr6iX/QIRAl6fAJwK5GWlbjpHxbgzNgRVtdE2TJTB1wCeP4lP
OAPhygoM+RHb7qf/jwGiYI0=
=dyRG
-----END PGP SIGNATURE-----