Re: Classes for fundamental types, renaming GtkArg

[Tim Janik <timj gtk org>]

On 25 Aug 1998, Marius Vollmer wrote:

> Hi,
> 
> look at this snippet from gtktypeutils.c
> 
>     static inline GtkType
>     gtk_type_register_intern (gchar	       *name,
> 			      GtkType	parent,
> 			      GtkEnumValue *values)
>     {
>       GtkType type_id;
>       GtkTypeInfo info;
> 
>       info.type_name = name;
>       info.object_size = 0;
>       info.class_size = 0;
>       info.class_init_func = NULL;
>       info.object_init_func = NULL;
>       info.reserved_1 = values;
>       ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> What about using the `klass' field of the GtkTypeNode for this?  Feels
> cleaner.

currently, the use of the reserved_1 field is just an implementation issue,
and info.klass==NULL already has indeed a very meaning.

> I think we can give individual and arbitrary definitions to the
> `klass' for every fundamental type.  For GTK_TYPE_OBJECT its something
> derived from GtkObjectClass, for enums and flags its a pointer to all
> literals, for boxed types it can be a pointer to a struct with the
> copy/destroy functions and the size, etc.  These conventions could
> even be exported to the user.
> 
> Waddaya think?

basically, this is a good idea. the actuall class structures, though,
have to at least adhear to something like the `GtkTypeBaseClass' structure,
i refer to in one of my last mails "Subject: hook functions (Re: Sound
 events in Gtk)".

> Plus, is anyone else worried about the heavy stuff that Gtk does at
> type initialization time?  I think at least touching all enum literals
> can be avoided and the long list of GTK_TYPE_* variables can probably
> be reduced to a single one.

what do you actually intend to do to make this happen?
a bunch of the enum functions need to be available pretty much after
start up, thus the enums and flags values have to be registered upon
startup time.
basically, the existing type trees, with the tree starting out with
the GtkObject type as a special exception, have to be available
from gtk_init() on, so GUI builders and language wrappers can query
certain stuffs about them.

[i say "trees", because even for the GtkEnum or GtkFlag types we feature
a flat class hirarchy. i've written a small query tool that, amongst other
things, dumps the actuall trees, starting with a specified root, to stdout.
it's currently in the CVS module "gle" as gle/tools/gtkquery. to visualize
for instance the enum tree, you'd invoke it as
$ gtkquery tree -r GtkEnum
]

> And I more and more dislike the name GtkArg.  I would like to rename
> it to GtkValue.  What is now called `object args' should be called
> `object attributes'.  While I'm all for source compatability, I think
> that Gtk is still too young to develop anachronitis.

even across the 1.0 border we've already been keeping some API and naming
oddities that would have been nicer other ways from the start on.
especially the GtkArg system has undergone one major rewrite recently,
in order to get child args and the skipping of type names going.
some language wrappers and also GUI builders already make lotsa use of this,
so we should really stick to the existing naming conventions, and not change
the whole system over and over again. in the end, "arguments" is not too bad
as a name for runtime configurable object parameters, eventhough it may have
had been named nicer in the first place...
apart from that, an "argument" usually has a defined name, type and value
(well, the actuall value can and should certainly vary), so "GtkValue" would
definitively be a bad name, as it omits the type and name implications.
a possibly better candidate would have been "parameter".


---
ciaoTJ