CLI undo edit?

[David Hampton]

On Sun, 2005-08-07 at 17:46 +0100, Neil Williams wrote:
> On Sunday 07 August 2005 4:58 pm, you wrote:
> > On Sun, 2005-08-07 at 00:04 +0100, Neil Williams wrote:
> > > A list would be more flexible - undo lists have to be sequential so a
> > > generic qof_undo() would need a single GList of all changes and rolling
> > > such a list in strict sequential order back and forth (i.e. a redo as
> > > well as undo) is far faster than iterating / searching.
> >
> > My vote would be for a single unro/redo list.  
> 
> I think you might misunderstood that. There can only be one list per 
> application using QOF. All undo operations within that application would use 
> the same list. If it lives in the book, all undo operations on that book 
> would share the same undo/redo list and those programs that support multiple 
> books can have multiple lists, accessed according to whichever session or 
> book is set as current.

I can see multiple undo lists within one application working, but it
will need to be well documented.  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.  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 think a list per entity 
> > would be very confusing,
> 
> ?? Where did I say per entity?

Your first paragraph.

	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.

> At no point is an undo list a list per entity! 

O.K.

> > and it would require exposing the internals of 
> > gnucash (the entity) to all users so they can understand how to use the
> > undo functionality.
> 
> ?? Not at all, the undo would be native to QOF, it would all be 
> behind-the-scenes.

That's good. My statement was based un a misunderstanding of what you
wrote.

> I can't see what you're getting at, I know the UI needs to be able to detect 
> if there are changes available to undo or redo - what I was asking was is it 
> preferable to have that functionality as a pair of separate functions rather 
> than confusing things by calling undo when all you wanted was to know if you 
> can undo.

Separate functions.

David