[Gnucash-changes] r14283 - gnucash/trunk - Replace gnc_tree_model_account_path_changed with manual checks whether

Andreas Köhler andi5.py at gmx.net
Thu Jun 1 03:57:05 EDT 2006


Hi,

On Thursday, 01 Jun 2006, 03:36 CEST, Chris Shoemaker wrote:
> On Wed, May 31, 2006 at 08:47:53PM -0400, Chris Shoemaker wrote:
> > On Wed, May 31, 2006 at 08:01:02PM -0400, Chris Shoemaker wrote:
> > > I think there are some problems with this...
> > > 
> > > 1) That stamp increment might not have been exactly correct, but I
> > > think it's technically required.  You've removed it entirely.  This
> > > model does not advertise persistent iters, and every insert or remove
> > > event will invalidate the iters for the paths after the "event-path"
> > > at the same depth.
> > > 
> > > 2) The old code would emit row_changed on all the ancestors of the
> > > inserted or deleted account.  I think that was correct behavior, since
> > > the inserted or deleted row may change the totals for the ancestor
> > > rows.
> > 
> > BTW, I think the need for this behavior can be demonstrated by hiding
> > out zero total accounts and then reparenting an account from a parent
> > with one child to an account that _was_ zero balance.  Since no
> > row_changed is emitted for the old parent, the filter model doesn't
> > know that it should filter out that row.  The sort model then gets
> > confused.  I get a (gnucash:22792): Gtk-CRITICAL **:
> > gtk_tree_model_sort_row_inserted: assertion `elt != NULL' failed.  And
> > then the treeview behaves strangely.

Thanks for spotting this. After having looked too long at
gtm_row_has_child_toggled, I began to successfully filter out
gtm_row_changed ;-) This was the missing test case, will remember it
next time...

> I noticed something interesting here.  While we were emitting
> row_changed on the ancestors for the QOF_EVENT_REMOVE and
> QOF_EVENT_ADD cases, we _weren't_ doing so for the QOF_EVENT_MODIFY
> case.  To see this in action, filter out zero-total accounts, and then
> either a) add a transaction to a previously empty account, or b)
> remove the last transaction in an account.
> 
> The account row visibility should change in the filtered treeview,
> but, for me at least, it doesn't.  It will correct itself if I force a
> refilter, though.
> 
> Now for the interesting part: For me (gtk2-2.6.10), this behavior
> doesn't improve (or even change at all) when I _do_ emit row_changed
> on all parents for the EVENT_MODIFY case!  Perhaps that has motivated
> some of the changes to gtktreemodelfilter.
> 
> I'm going to commit the code to emit row_changed in all three cases
> anyway.  I'd love to hear that the above test behaves better for
> someone with newer gtk+.

The code seems to work, good job!

WRT modifications: Can this be due to calling
xaccAccountRecomputeBalance after emitting QOF_EVENT_MODIFY? A quick
test showed that total==0 after having inserted a txn into an empty
account.

BTW, I saw yet another difference between gtk 2.8 and 2.9. Assume
parent has total!=0 and child has total==0. When I switch to showing
zero-total accounts, the disclosure triangle in front of the parent
account as well as the child account is not shown. I hope this is
only due to 2.9~=unstable and further tests with the account tree
will not yield new crashes or errors.

-- andi5


More information about the gnucash-devel mailing list