Re: Objects in GTK 1.4...

[Owen Taylor <otaylor redhat com>]

wmperry@aventail.com (William M. Perry) writes:

> To make this work I had to register my own fundamental types for
> 'GtkListOf' and 'GtkArrayOf'.  There are then subclasses for
> GtkListOfString, GtkListOfObject, and GtkArrayOfString.  This allows me to
> import functions that take `GList *'.
> 
> (gtk-import-function nil "gtk_tree_remove_items"
> 		     '(GtkTree         . tree)
> 		     '(GtkListOfObject . items))
> 
> This would also allow for better type-checking, both at compile time and
> run-time.  Right now a lot of functions take a GList and assume that it
> really contains GtkWidgets or whatever it is expecting.  An example is
> gtk_tree_remove_items_internal ():
> 
>   while (tmp_list)
>     {
>       widget = tmp_list->data;
>       tmp_list = tmp_list->next;
>       
>       if (widget->state == GTK_STATE_SELECTED)
> 	gtk_list_unselect_child (list, widget);
>     }
> 
> If someone (gods forbid) passed in a GList of strings instead of
> GtkWidgets, this would explode.

Hmmm, I guess you mean gtk_list_remove_items_iternal(). 

But, point taken. There are only a very small number of functions that
take GLists as arguments. And a slightly larger number that return
GLists of results. But it would be nice to have that type of information
in the type system.

The GLib-1.4 type system is not yet finalized, and there is still
some debate in this area; it's partially a matter of deciding what
the type system is there for.

Note that there also is a distinction between the dynamic type system,
and what is represented statically in the .defs files. Right now, for
instance, methods are not represented at all in the dynamic type
system. The .defs format does have some idea of parametric types.

If you have a copy of the 1.4 CVS checked out, the defs file format
is described in docs/defsformat.txt.
 
> When is 1.4 expected to release anyway?  I'm going to have to do a fair bit
> of updating to deal with the conversion to G_Object and friends.  Need to
> know when I should schedule a day or two of pure hacking for the
> transition. :)

It should be later this summer; I can't provide an exact date at this point.

                                        Owen