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

[Derek Atkins]

Quoting Neil Williams <linux at codehelp.co.uk>:

> > I think this was what Derek meant when he 
> > was talking about supporting a different event for editing an account
> > than for adding a transaction.  One would dirty the Account, the other
> > would only indicate that the Account contained a dirty Transaction.
> 
> I think that can be handled through the existing event handler interface, 
> without more confusion about what is meant by dirty.
> 
> Derek: Did you mean that the event would make a parent instance dirty (i.e. 
> Trans -> Account) or just that it would trigger different events in the GUI 
> according to whether it was a Trans or an Account?

Neither...  I think we need more types of events.  Right now there is no
difference between the event when you change an Account Name and when you add a
new Transaction to the account.  Right now it's all MOD_EVENT, but we probably
need a MOD_EVENT and ADDREM_EVENT to differentiate between these cases.  We
might want even more, but I'm not sure offhand.

I was just saying that right now we have a "mark_dirty()" static inline function
in every object file that effectively does the same thing.  We should abstract
that out into qofinstance and have a "qof_instance_mark_dirty" API that lets us
put that code into a single place so all qof objects handle changes in the same
way.

This new API could theoretically also tie into the event system so calling
qof_instance_mark_dirty() could also send an appropriate event...  But then
we'd need different APIs (probably macro'd) to differentiate between the event
types.

> > > Ah now that would be slower. No point, as I see it, traversing the
> entire
> > > tree - set the collection to clean and all done.
> >
> > Not the entire tree, only the dirty portion.  Extreme example: I have
> > 100000 Splits, and edit one of them which happens to be in an Account
> > with only 5 Transactions.  A tree search would search 1 book and find
> > 1 dirty*, search 75 Accounts and find 1 dirty*, search 5 Transactions
> > and find 1 dirty*, search 2 splits and find 1 dirty**, and then commit
> > one split.
> >
> >  (*) here, I mean "contains something dirty"
> >  (**) here, I mean "is itself dirty"

Eh?  You're very confused, Neil... At least about how GnuCash does it.  Your QOF
stuff might behave differently, but there is no "tree".  There are lists of
objects with relations.  There is no knowledge about Accounts..  And what about
obects that don't fit into accounts?

Also, this is only an issue with XML, and XML is always re-written from scratch.
 There are no partial writes to an XML backend.  So again you don't need a
partial search.  Note that with SQL we don't have any of these problems,
because the data is saved when you actually commit the change, in real-time. 
So the book is never dirty.

No, you need to do a full object search to determine if something changed.. 
Although we COULD limit this to each base object class, which is how it is
currently implemented.

> The SQL backend is the only one that can handle such differentiation in 
> storage and that can handle such things using the last_update mechanism. I 
> don't see the need for a second dirty mechanism.
> 
> last_update was (AFAICT) designed to cover exactly your example.

No, it wasn't.  It was designed to make sure your cache of the data is as fresh
as the data in the SQL backend, so when you have multiple users you can detect
when someone else changes the data out from under you.  It was not designed to
compute what you've changed in your local cache in order to tell you it. 
Although I suppose it COULD be used in that fashion, that was not designed to
do that.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available