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

Chris Shoemaker c.shoemaker at cox.net
Wed Jul 20 16:46:35 EDT 2005

On Wed, Jul 20, 2005 at 04:20:15PM -0400, Derek Atkins wrote:
> 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.

Hmm.. bringing these two together makes a lot of sense.  

> > > > 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?

[ You may not have noticed that I wrote what was above, not Neil.  I
wasn't trying to describe what actually happens anywhere, just
explaining that trees can be more efficeint than lists if you only
need to find the minimal changed set. ]

> 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.

ISTM you have the two extreme cases: XML only needs to track dirtiness
at the file (book?) level, since it has to rewrite everything anyway.
SQL doesn't need to track dirtiness at all because commits are
immediate.  So what does tracking Collection-level dirtiness buy us?

ISTM, if there's some middle-ground where dirtiness *does* need to be
tracked on each instance because commits are not immediate, and yet
commits don't have to write ALL the data, then you'd want to find the
dirtiness by tree search, not by linear search for each object type.


> > 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

More information about the gnucash-devel mailing list