Re: Using GParam in GtkTLCell.



On 25 Sep 2000, Owen Taylor wrote:

> 
> Tim Janik <timj gtk org> writes:

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

i'll say it again, if you want "full genericity", you get
to deal with complete GValues, there's simply no way around
this.
however, i don't think support for _all_ GValue types is
what we want for a generic model, considering that you can
limit your model's per-cell storage to something like:

union {
  gint32 int32; /* bool, [u]int16, [u]int32, enum, flags */
  gpointer pointer; /* strings, objects, boxed types */
  gfloat floatval;
}

i.e. 4 bytes on intel, covering 90% of an average user's needs.
if you then allow the user to implement custom _column_
implementations for their models, they can easily adapt
your storage thingy to their needs (jonathan, did you take
third party implementations of storage columns into account?)
   
> 
> Wow, it's really useful to be able to create new _useless_ value
> types...

see, just because some values will require more than one
data value to store them, doesn't mean they are useless,
that's simply a misattribution.

>                                         Owen
> 
> 

---
ciaoTJ





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