GNOME.org
 

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



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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]