[PATCH] Updated add/edit account window

Eskil Bylund eskil.bylund at gmail.com
Thu Jan 19 16:23:32 EST 2006


2006/1/19, Chris Shoemaker <c.shoemaker at cox.net>:
> On Thu, Jan 19, 2006 at 09:31:54PM +0100, Eskil Bylund wrote:
> > 2006/1/19, Chris Shoemaker <c.shoemaker at cox.net>:
> > > On Thu, Jan 19, 2006 at 08:19:14PM +0100, Eskil Bylund wrote:
> > > > > Only that the static tree model probably shouldn't contain selection
> > > > > state.  It might be shared by multiple views that want different
> > > > > selections.
> > > > >
> > > > No, of course. See above.
> > > >
> > > > > Maybe that's why you wanted to provide the treemodel as an argument?
> > > > > So you could filter the non-static treemodels?
> > > > >
> > > > Yes. Currently there are no non-static treemodels that will be
> > > > filtered, but I added it just in case.
> > > >
> > > > To summarize above: I would like to remove the GtkTreeView specific
> > > > functions from the model and make the Filter dialog use its own model
> > > > for storing selection state.
> > >
> > > It would definitely be nice to show selection state with checkboxes.
> > > But it'd also be nice to use the static account types tree model.
> > >
> > > What do you think about this:?
> > >
> > > Keep the selection state private to the filterBy dialog instead of
> > > using a new tree model for each dialog.  You can even put that
> > > selection state right into a new field in the AccountFilterDialog struct.
> > >
> > > Instead of using an attribute mapping to the checkbox's treeviewcolumn
> > > from the new model's selection-state column, use a GtkTreeCellDataFunc
> > > that updates the "active" property of the GtkCellRendererToggle from
> > > that private selection state field.  Then the filterBy dialog can
> > > always use the static treemodel.
> > >
> >
> > Yes, this is a good solution. I'll implement this right away.
> >
> > To not spam the list with lots of mail, I've attached another patch
> > for GncTreeModelAccountTypes here. It makes the model emit the
> > "row_changed" signal when the selection is changed. The cell renderer
> > won't render properly otherwise.
>
> Just to make sure we're on the same page...  That patch isn't needed
> to implement what I described.  In fact, I don't think the
> get/set_selected functions are used anywhere - and that's good.
>
> What I described means connecting to the "toggled" signal of the
> cellrenderertoggle, in order to update the private selection state.
>
> Crappy ascii diagram:
>
>   Composite Model Concept             connection             "View"
>   ----------------------              ----------           -----------
>
>   * AccountTypeNames
>     (from the static      <-- attribute mapping        --> * Name column
>     treemodel)
>   * SelectionState        <-- "toggled" signal handler --- * Selected
>     (from                 --- "CellDataFunc"          --->    column
>     AccountFilterDialog)
>
> -chris
>

Yes, I understood this, but the "row_changed" signal should still be
emitted _if_ the model would to be updated using those functions...



More information about the gnucash-devel mailing list