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

[Chris Shoemaker]

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

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

-chris