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

[Neil Williams]

On Wednesday 20 July 2005 9:20 pm, Derek Atkins wrote:
> 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.

That I've now done. qof_instance_set_dirty will replace all calls to 
inst->dirty. Events and other calls can be added to qof_instance_set_dirty as 
necessary.

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

Agreed.

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

?? Wasn't it Chris that started talking of things in trees? I may have 
repeated the analogy but I am not at all confused about objects and 
relations / references in GnuCash or QOF. There is a hierarchy of objects, 
which Chris was referrring to, from Group -> Account -> Trans -> Split. That, 
after all, is how the current XML backend writes things out, adding the bits 
that don't fit using customised functions. QSF does not work that way, it 
restricts itself to the objects and their references, exactly as you 
describe. QOF, PilotQOF and CashUtil inherit exactly the same object and 
reference methods.

I quite like the approach actually, it's easier to deal with objects in a book 
as if the book was just a loose bag, rather than a set of rigid mailboxes 
with some (like Group) more important than others. I found it quite awkward 
that the current GnuCash XML ignores any Account that is not bound to a 
Group.

Loose organisation via references is far easier for import/export work - it 
makes partial books and partial searches possible within XML.

> There are 
> lists of objects with relations.  There is no knowledge about Accounts.. 
> And what about obects that don't fit into accounts?

Those that are QOF objects are queried as any other.

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

Umm, QSF does partial writes and could be adapted to write out only those 
entities that had changed since the last save quite easily. All you need is a 
GList of those entities.

In fact that might not be a bad idea - if there's a problem with a backend, 
the changed data could be written out as a failsafe. It could even go to 
STDOUT if there's no writeable diskspace left.

> So again you don't 
> need a partial search.

But if you do need it at some other time, it can be done.

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

Agreed.

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

And that is how I'm working to enhance it, using qof_instance_set_dirty. As 
discussed earlier, a complete iteration over all instances is overkill. No 
harm is making it a check on all registered objects.

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

OK, I see that.

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

:-)

-- 

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/2a755dd2/attachment.bin