Re: user-defined data types & GtkListStore

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.


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]