GncTreeView

[Chris Shoemaker]

On Tue, Jun 07, 2005 at 06:59:28PM -0400, David Hampton wrote:
> On Tue, 2005-06-07 at 15:37 -0400, Chris Shoemaker wrote:
> > David,
> >         I've had a pretty good look at gnc-tree-view.{ch} and I think
> > it's fantastic.  This is exactly what all the other tree views were
> > begging for.  And the integration with gconf is great.  I think it's
> > going to make for nice behavior of treeviews and much cleaner code,
> > too.
> 
> Thanks.
> 
> >         Mind you, I haven't actually tried to use the api, just read
> > through the code, but I have some ideas/suggestions:
> 
> I did look at your budgeting code while working on the changes, and
> tried to make the GncTreeView flexible enough to meet what you were
> doing.
> 
> >         All the viewcols are of the "attribute" type.  This is good
> > for most cases, but maybe it would be good to allow adding a viewcol
> > of the "cell_data_func" type.  I know you could always make your own
> > viewcol and then call gnc_tree_view_append_column(), but that doesn't
> > get you all the gconf/sorting/pango/selection menu goodness that the
> > other viewcols get.
> 
> You can't get sorting without using the GtkTreeModel, because the
> sorting happens in a GtkTreeModelSort that is layered between the data
> model and the view.  The gconf/slection menu code should work correctly
> for append_column() as long as you provide a pref_name.  Not quite sure
> what you mean by the pango reference.  IIRC the only use of pango was
> sizing the column title.

For now, it seems like calling add_text_column and then fetching and
customizing the CR is the way to go.

> 
> >         Also, IIUC, add_numeric_column still requires that the model
> > column be G_TYPE_STRING, right?  Maybe it's possible to go a step
> > further with something like add_monetary_col().  It could take two
> > model columns, one for the commodity and one for the amount.  Then,
> > internally, you could use a cell_renderer_text, and set your own
> > cell_data_fun to turn commodity+gnc_numeric into a string.
> 
> It requires that the model return a string to the view.  Says nothing
> about what the model uses to create this string.  That's internal to the
> model.  You can finda ll the available types at
> http://developer.gnome.org/doc/API/2.0/gobject/gobject-Type-
> Information.html#G-TYPE-INVALID:CAPS, but the only easily usable ones
> are boolean, int, double, string, and pointer.

Yeah, I know I could always convert money to string in the model and
then things are easy in the treeview, but...  when possible, I prefer
the model to export the "rawest" data-type possible, and then convert
to string in the view's cell data function.  That way, I always have
the flexibility to make two views display the same underlying
data-type with two different data->string translations.  I can think
of some unusual multi-currency applications of this, but it's not
critical.

> 
> >         As for GtkCellEditable, I guess the way to use this would be
> > to call gtk_tree_view_column_get_renderers() on the viewcol returned
> > by the add_xxx_column to get the renderer, then set "editable"
> > property to true and connect to "edited" signal.  It's a little
> > difficult to do that without making making some reasonable assumptions
> > about how the add_xxx_column functions are packing the cellrenderers
> > into the viewcol.  Maybe you can just make that an explicit part of
> > the api by saying, "this function will add N CRs under these
> > conditions..."
> 
> Does gnc_tree_view_account_add_custom_column() provide what you're
> looking for?

:) When I wrote account_add_custom_column(), I didn't have in mind the
full breadth of what one can do with cell renderers.  Also, I wasn't
brave enough to write gnc-tree-view, so it only works with accounts.
It solves the task of in-tree text-editing quite nicely though, and it
works great with budgets.  But... we have to make a design decision
regarding gnc-tree-view: If we provide a robust way to fetch the CR
that was added to the viewcol, then we don't have to provide wrapper
functions like add_custom_column, because api users are free to do
whatever they want to the CR.  OTOH, if we *don't* provide some
reliable way to get the right CR, then whatever functions we offer
like add_custom_column have to be suitable for every intended use.
And, I'm not sure I've imagined all the potential uses yet, so it'd be
a bit of a guess to try to design a sufficient interface.

We *could* hedge our bets and try a little of both:

1) We could add this comment to the gnc-tree-view's documentation: 
For add_text_column: "If you specify NULL as the 'stock_icon_name' this
function will return a GtkTreeViewColumn with only one GtkCellRenderer
packed."

and for the add_xxx_column:
"The returned GtkTreeViewColumn will have only one GtkCellRenderer packed."

That'd be sufficient for now until we came up with a better policy.

2) I (or you, if you prefer) can look into generalizing my
account_add_custom_column to fit into gnc-tree-view.  Off the top of
my head, I think this would mean that the "cell source" callback would
have to accept not only the column, and cr, but also the model and a
treeiter.  Likewise, the "cell edited" cb would have to accept model
and iter, (and column and text).

I can't guarantee that this would satisfy every future need, but it
does seem pretty darn flexible.

-chris