Re: user-defined data types & GtkListStore

["Bryan Kubishta" <bkubisht driscollinc com>]

> On Thu, 2003-04-10 at 20:01, Bryan Kubishta wrote:
>
> > Hi, I'm brand new to the list, but didn't see anything about this while
> > searching the archives.  It looks like the core GTK developers monitor
this
> > list, which must be an incredible asset!
> >
> > I want to store DBDATETIME structs in a column of GtkListStore, because
it
> > has the full date/time representation that our database has, instead of
> > requiring me to muck with GTime or GDate conversions and possible loss
of
> > data.  Customizing the text renderer for my TreeView was no problem
because
> > I had customized them before, so displaying would be simple.
> >
> > So much for foresight!  The approach I took was to define a new
fundamental
> > GType (G_USER_TYPE_DBDATETIME), and register it.  It seemed simple,
because
> > my struct type easily fits in the data field of GValue.  I based my
setup &
> > registration code after what was done in gvaluetypes.c, and it
successfully
> > registers to the next fundamental type (196) without warnings.  But then
> > when I try to pass this new GType value into gtk_list_store_new() and
traced
> > into that code, it was glaringly obvious that  it relies on
> > gtktreedatalist.c->_gtk_tree_data_list_check_type (type), which has all
the
> > fundamental types hardcoded!  Why why why?  Wouldn't it be better to
have
> > the check_type function loop through a range of registered fundamental
> > types, instead of explicitly switching
>
> The problem with supporting custom fundamental types, is that there
> is no way of extracting the "data" from a GValue in a generic and public
> way, so you'd have to store a full GValue structure for every data
> items. Which would be a lot of overhead. (24 bytes per item as compared
> to the current.)
>

I saw the suggestion in the archives about puting everything in a single
column, and even considered it for the sake of efficiency.  But the
convenience of having GTK handle sorting by specific columns is so nice, so
I dropped the idea.  The GTypes of my columns can be different every time
the program runs, (each column maps to whatever type happens to be in the
database table currently being viewed) so I didn't want to tackle the
sorting using my own structure.  TreeViews and ListStores _almost_ gave a
perfect framework for this.

But along the same lines of performance, I noticed that each column of data
is stored in an individual linked list.  I've got all my data stored
row-by-row instead of column-by-column.  Can anyone here verify that there's
a significant speedup by storing data grouped by column instead of row?

Also I noticed that the renderer gets called for all tree_view cells,
regardless of whether they are visible to the user or outside the bounds of
the tree_view.  Is there a simple way to eliminate this waste, or am I doing
something wrong?

-Bryan
> > So there's my dilemma.  Is there a better way to achieve my goal than
> > creating a new user type?  Can I make my current approach work without
> > modifying the core gtk code?
>
> The approach I always seem to be advocating here for doing TreeViews is:
>
>  - Put only a single column in the store, of type G_TYPE_POINTER,
>    or if you want to get a little fancier, of a boxed type you register,
>    and in that column, store a pointer to the application data structure
>    that each row corresponds to.
>
>  - Use gtk_tree_view_column_set_cell_data_func() to set the attributes
>    on the cell renderers for display.
>
> It's a little more complex than the more common usage of direct
> cell renderer attribute => module column mapping.
>
> But:
>
>  - You can frequently avoid copying application data into the
>    model, which is a nuisance, especially if your app data types
>    don't map well onto GLib types.
>
>  - It's more flexible in what you can store and how you can format
>    it for display.
>
>  - It can be more efficient. There is a distinct overhead for
>    extra columns.
>
> Regards,
>                                              Owen
>
>