GncTreeView

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GncTreeView

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

        Mind you, I haven't actually tried to use the api, just read
through the code, but I have some ideas/suggestions:

        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.

        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.

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

        Nice work!

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GncTreeView

Chris Shoemaker
On Tue, Jun 07, 2005 at 03:37:22PM -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.
>
>         Mind you, I haven't actually tried to use the api, just read
> through the code, but I have some ideas/suggestions:

I gave it a spin and I'm still impressed.  I coded up in about 10 min
what had previously taken me about 1 hr, and I estimate it would have
taken only about 30min if I'd started w/ GncTreeView, plus I got the
pretty alternating colors for free. :)

A few more comments:

   Something like gnc_tree_view_new() or
gnc_tree_view_new_with_model(), would be convenient.  It seems almost
conventional in gtk.

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

        I realize now, that I can add a col with the add_text_column
function, grab the col's renderers and change the type to
cell_data_func after-the-fact.  Apparently I can have my cake and eat
it, too.  But, it does hinge on getting the right renderer.  I feel a
bit icky just grabbing the first in the list returned by
gtk_tree_view_column_get_cell_renderers.  Maybe you could provide a
helper func to return the cell renderer I expect to be added when I
call add_xxx_col.  Or mark it with an object property?  I don't know.

        Does the second-to-last column have to be visible by default?

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GncTreeView

David Hampton-2
In reply to this post by Chris Shoemaker
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.

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

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

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GncTreeView

David Hampton-2
In reply to this post by Chris Shoemaker
On Tue, 2005-06-07 at 17:10 -0400, Chris Shoemaker wrote:
>    Something like gnc_tree_view_new() or
> gnc_tree_view_new_with_model(), would be convenient.  It seems almost
> conventional in gtk.

That's true in cases where the the model (or whatever) is optional.  At
the moment I think the GncTreeView code pretty much still requires you
to have a model.  (Just adding the second function should be trivial,
though.)

>         Does the second-to-last column have to be visible by default?

Yes.  Its sole purpose is to take up any slack space if the window is
expanded wider than the current contents of the window, and it has a
minimum width of zero.  Without it, when you expand the window too wide
the GtkTreeView code will expand the size of the final column containing
the pulldown button.

What's the problem you're seeing?

David


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GncTreeView

Chris Shoemaker
On Tue, Jun 07, 2005 at 07:04:33PM -0400, David Hampton wrote:
> On Tue, 2005-06-07 at 17:10 -0400, Chris Shoemaker wrote:
> >    Something like gnc_tree_view_new() or
> > gnc_tree_view_new_with_model(), would be convenient.  It seems almost
> > conventional in gtk.
>
> That's true in cases where the the model (or whatever) is optional.  At
> the moment I think the GncTreeView code pretty much still requires you
> to have a model.  (Just adding the second function should be trivial,
> though.)

yup.

>
> >         Does the second-to-last column have to be visible by default?
>
> Yes.  Its sole purpose is to take up any slack space if the window is
> expanded wider than the current contents of the window, and it has a
> minimum width of zero.  Without it, when you expand the window too wide
> the GtkTreeView code will expand the size of the final column containing
> the pulldown button.
>
> What's the problem you're seeing?

no problem.  I just misunderstood its behavior.  It seems to function
correctly.

-chris

>
> David
>
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: GncTreeView

Chris Shoemaker
In reply to this post by David Hampton-2
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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel