Re: Using GParam in GtkTLCell.
- From: Tim Janik <timj gtk org>
- To: Jonathan Blandford <jrb redhat com>, Owen Taylor <otaylor redhat com>
- Cc: Tim Janik <timj gtk org>, Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: Using GParam in GtkTLCell.
- Date: Tue, 26 Sep 2000 07:16:18 +0200 (CEST)
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]