[Gnucash-changes] Spruce up the delete window dialog to make it more HIG compliant.

[Neil Williams]

On Wednesday 20 July 2005 7:53 pm, Chris Shoemaker wrote:
> That reminds me of a question I've had.  ISTM, there's some vision of
> "dirtiness" propagating from Instance to Collection.

There is now, yes.

> However, I think 
> it would make sense if dirtiness propagated up the containment
> hierarchy.  E.g. User dirties a Split, which dirties the split's
> Transaction, and Account, which dirties the account's Group, which
> dirties the Book.

Why such a tortuous path? Split -> Collection -> Book. Checking the book 
automatically checks all collections. The Book won't know WHICH split has 
been changed so you gain nothing.

With a backend that only stored dirty instances (e.g. by using a local cache - 
SQL), then marking the Trans, Account and Group as dirty is 
counter-productive. Those haven't changed, only the Split has changed - it 
could make a big difference if the backend is actually a network connection.

These backends could identify which collections are dirty in the book - then 
identify which instances are dirty by *only* having to iterate over a those 
collections, instead of all collections and thereby all instances. In your 
example, the backend would only have to iterate over the Splits, not the 
entire book. If you make Group dirty everytime a Split is changed, you lose 
all ability to identify *which* instances are actually dirty.

> Now, a check for the need to save can just check 
> the book.

With the new qof_instance_set_dirty() that will be done in one call.

> And, the code that commits changes and clears the dirty 
> flag could also travserse the tree instead of committing whole
> Collections, or searching in a Collection for the single split that was
> dirtied.

Ah now that would be slower. No point, as I see it, traversing the entire tree 
- set the collection to clean and all done.

The QofCollection dirty marker is a single boolean for the entire collection, 
it does not require iterating through the collection itself, either to set or 
to clear.

> Incidentally, why does Split not even have a dirty flag?

I'll be changing that - every object will use qof_collection_is_dirty and 
qof_collection_make_clean in their object definitions.

> What design 
> decision governs whether a core engine object should derive from
> Instance or Entity?

?? All core structs contain a QofInstance which itself contains a QofEntity.

-- 

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/20050720/f13464e4/attachment.bin