[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