Re: Using GParam in GtkTLCell.

[Tim Janik <timj gtk org>]

On 24 Sep 2000, Owen Taylor wrote:

> 
> Tim Janik <timj gtk org> writes:
> 
> > >   /* public for GTypeValueTable methods */
> > >   union {
> > >     gint	v_int;
> > >     ...
> > >     gpointer	v_pointer;
> > >   } data[4];
> > > };
> > >          ^ an array of size 4?
> > > 
> > > Am I missing something here?  You only seem to use the first one.  The
> > > reason I ask is that I would like to have the model fill in a GValue
> > > when queried.  As a result, I was going to store the data for the model
> > > as the data field of the GValue, but would rather not have it be any
> > > bigger then it has to be.
> > 
> > the GValue structure is actually just meant to be used for
> > short term value transfers, that is passing them around to
> > callers and the like.
> > as such, values around are mostly going to be stored on the
> > stack, i.e. in automatic variables, so another 1 or 2 pointers
> > shouldn't be much of an issue.
> > you probably do not want to use GValue as the actuall storage
> > backend for your model, model storage is usually implemented
> > in pretty specific terms of what you actually want to model
> 
> _But_ we are also providing simple data-storage models - 
> GtkListStore and GtkTreeStore. These needs to store per-column
> data in generic form. These will be the most frequently
> used models.
> 
> A full GValue is complete overkill for this because:

right.

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

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ