CLI undo edit?

[Neil Williams]

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. GnuCash doesn't come into that category yet, it only 
concerns itself with a single book outside import/export.

I discounted the idea of a hashtable of entities but even that would be a 
single table of all affected entities, not thousands of hashtables each 
within an entity.

> I think a list per entity 
> would be very confusing,

?? Where did I say per entity? At no point is an undo list a list per entity! 
A list OF entities, yes.

It's a single list of entities - or more specifically entity changes. What I 
was considering was whether to store these changes as the entire entity or 
only as the modified parameter data, ignoring parameters that have not been 
changed. My proposed qof_undo opaque struct would simply store the data from 
a single parameter, the GUID and the type of the object. Repeated structs 
would then be built into a list.

The undo list would be a single sequential list that can be read forwards or 
backwards and holds the parameter data changes in ALL entities since the last 
save.

One list for all entities in the book. The natural place for the list may 
actually BE the QofBook - I was thinking of the backend but the book is the 
data-set so the data-set undo list should probably go there.

> 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. None of the internals need bother any user. Click a button 
in the toolbar and QOF takes the qof_undo struct from the start or end of the 
list as appropriate and sets the previous version of the parameter data in 
the entity indicated by the undo data.

As noted, this may well be a reverse list, prepending the most recent changes 
so that undo uses list->next and redo uses list->prev.

The entity will remain exposed to the developers, even when QOF is an external 
library, but the undo list will not - that will reside elsewhere in an opaque 
struct. qof_undo() and qof_redo() functions would provide access.

If it's in the book, that would be:
void qof_undo(QofBook *book);
void qof_redo(QofBook *book);

Each call only moves one step back in the list, subject to the problems of 
deleted/created entities.

Click it once and one change is undone, no matter where that change occurred 
within the book, no matter which entity is involved. Click redo and it's 
redone. The user needs to know absolutely nothing about entities. Even the 
developer using the API only needs to know the function prototypes above, 
together with the boolean functions below.

Setting the data via QOF would use the same functions as already exist in the 
objects, so this even allows the UI to track which window contains the data 
changed by the undo/redo - the object would send the same event messages as 
if the user had undone the changes manually.

So if the user makes a change in an Account, views a report and then clicks 
undo, the UI should be able to pick up the EVENT_MODIFY and realise that 
maybe the Account window should be given focus.

What *cannot* be done with a native QOF undo/redo is anything related to 
non-QOF data, like the reports, configuration data, settings, options etc. 
unless these also exist as genuine QOF objects. e.g. changing the 
smallest-commodity-unit in an Account can be undone. Changing the date fields 
of a report cannot.

> > Each would return silently if the end of the list is reached in the
> > appropriate direction. Maybe they should return gboolean so that the UI
> > can tell if more steps are available? Or should that be a separate
> > function: gboolean qof_can_undo(); gboolean qof_can_redo();
> > Both would return FALSE after a save operation.

gboolean qof_can_undo(QofBook *book);

gboolean qof_can_redo(QofBook *book);

> The UI must be able to find out if there are items available for
> undo/redo.  It needs to provide this information to the user by
> correctly dimming the Undo and Redo menu items.

That's why I mentioned qof_can_undo and qof_can_redo. Those would return a 
simple boolean. The UI can handle that, can't it? (I know I don't do a lot of 
GUI programming, but I do understand active and disabled toggles.)
:-)

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. I guess I've answered my own question!

That's how I work, I set out an idea at the top of the email and argue it out 
in the text - that way I cover the pros and the cons.

Anyway, it's ages away yet.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050807/755de17d/attachment.bin