[PATCH] Updated add/edit account window

Andreas Köhler andi5.py at gmx.net
Thu Feb 16 12:20:40 EST 2006


Hi,

On Wednesday, 15 Feb 2006, 23:25 CET, Chris Shoemaker wrote:
> On Wed, Feb 15, 2006 at 06:40:10PM +0100, Andreas Köhler wrote:
> > Here is a patch that tries to replace the list store with a filtered
> > GncTreeModelAccountTypes. If you do not want to go this way (do not
> > think so), there are still two open bugs in my own code ;)
> 
> Just out of curiousity, were you referring to bugs in this patch?
> Anyway...

I try to fix all bugs I know of _before_ I send in a patch :) No, I
was referring to minor mistakes I made, but which have now gone to
/dev/null.

> I just applied a rather extended version of this patch as r13271.
> Take a look.  I think you'll see that it's much nicer to hide the
> complex conversions of paths and iters between the filter model and
> the child model _inside_ gnc-tree-model-account-types.c, where it has
> to be considered anyway.
> 
> But, in the account dialog, this becomes as simple as using
> 
> GNCAccountType
> gnc_tree_model_account_types_get_selection_single(GtkTreeSelection *sel);
> 
> and
> 
> void 
> gnc_tree_model_account_types_set_selection(GtkTreeSelection *sel,
>                                                 guint32 selected);

Yeah, looks good to me!

> Now, I didn't commit the
> gnc_tree_model_account_types_get_iter_from_type(), but we should
> hold on to the idea, because, if we decide to use a GtkComboBox,
> the GtkTreeSelection functions won't help. We'd need something
> very much like gnc_tree_model_account_types_get_iter_from_type() [
> and ...get_type_from_iter() ], _except_ they should work with the
> _filter-model's_ iters, not the child model's iters.  The goal
> here is that there be only one kind of account-types treemodel -
> the filtered kind - so we want to hide the child model and _all_
> its iters.

Roger that.

There is still one open issue I need to address, although I got the
feeling that the current solution is ok. Do we need sorting on the
model? Any consensus about that?

-- andi5


More information about the gnucash-devel mailing list