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/
pgpd1m0GB8d3X.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
