Re: user-defined data types & GtkListStore

[Owen Taylor <otaylor redhat 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.)

> 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