Re: Using GParam in GtkTLCell.

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> >  a) the type is the same for every value in a column
> >  b) nothing that you would want to use for cell storage
> >     uses more than one of the 4 fields.
> > 
> > You don't want to use 36 bytes per model cell when you
> > only need to store 8!
> > 
> > Now, of course, Jonathan could write some code that switched
> > over G_TYPE_FUNDEMENTAL (G_VALUE_TYPE (value)) and dealt
> > with the types he knows about, but this is hard to maintain
> > and clumsy. It's considerably easier and more robust
> > simply to extract data[1] and store that.
> 
> nope, that's completely hackish!
> conceptually, GValue is an _opaque_ type, it simply has
> to be since you may not make any assumptions on the
> actual value being stored there.
> btw, you probably meant data[0] in the above (errors such as
> gtk users accessing the wrong data[] memeber are another good
> reason to really consider GValue opaque), since that's
> where the actually string pointer of a G_TYPE_STRING
> value would be stored. but it wouldn't at all be enough
> to just memcpy() data[0] around, say we support const static
> as well as dynamic strings, the implementation could look like
> this:
> 
> #define DYNAMIC_STRING_FLAG	0x01
> 
> g_value_set_string (GValue *v, const gchar *s)
> {
>   if (v->data[3].v_int & DYNAMIC_STRING_FLAG)
>     g_free (v->data[0].v_pointer);
>   v->data[3].v_int |= DYNAMIC_STRING_FLAG;
>   v->data[0].v_pointerg = g_strdup (s);
> }
> 
> g_value_set_static_string (GValue *v, const gchar *ss)
> {
>   if (v->data[3].v_int & DYNAMIC_STRING_FLAG)
>     g_free (v->data[0].v_pointer);
>   v->data[3].v_int &= ~DYNAMIC_STRING_FLAG;
>   v->data[0].v_pointer = ss;
> }
> 
> so you can't at all get away with storing data[0].
> 
> if you wanted a fully generic model, you'd simply have to use
> GValue structures all over the place. i highly doubt the
> usefullness of this though, especially because of its
> inefficiency. models as such are inherently tied to your specific
> needs, so for the List/Tree you should just provide GtkListStorage
> and GtkTreeStorage _interfaces_ and maybe provide an example
> model implementation exporting those interfaces for pure string
> storage (a commonly needed thing). 

We need a generic model. I'm not going to even bother arguing
this one - deriving a new type to create a 10 item list of names
is just very, very silly.

So, I guess we'll just have to distinguish _useful_ value types
(known fundemental types, reasonable amount of storage)
from _useless_ value types. And only allow _useful_ value
types to be stored in GtkTreeStore.

Wow, it's really useful to be able to create new _useless_ value
types...
                                        Owen