Re: GtkType stuff

[Marius Vollmer <mvo zagadka ping de>]

Tim Janik <timj@gtk.org> writes:

> On 25 Aug 1998, Marius Vollmer wrote:
> 
> > * Names of fundamental types
> > 
> > I would like to change them to something more straighforward, because
> > I don't think it really matters and I want to match them to the static
> > description files and therefore want to keep them simple.
> 
> well, they actually do matter. the reason i changed the typenames
> to correspond to actuall typedefs (the ones for GtkEnum, GtkFlags and
> GtkBoxed are still missing but need to be added somewhen) is that all
> type names need to correspond to actually existing typedefs in C, C++
> and probably even other languages.

I don't think that it is that simple.  There needs to be a well
defined mapping from fundamental types to types in a certain language,
C being the most important.  But this mapping need not be defined by
the GtkType<->name mapping of the Gtk run-time.  The purpose of the
fundamental types is to identify a set of really basic types that have
next to nothing in common and need to be treated each in its own
special way.  This includes conversion between the different
representations of their values in the run-time systems of different
language implementations and thus the mapping to native types of this
implementation.

In fact, the GTK_TYPE_OBJECT types are named "GtkObject", "GtkWidget",
"GtkButton", etc while their correct C types are GtkObject*,
GtkWidget*, GtkButton*.  So some special casing is already necessary.

> this is required by source generators, might that be GUI buildres,
> glue code generators or what else.

The mapping can easily be implemented inside the source generator.
For example, the guile-gtk glue generator doesn't query the Gtk
run-time at all during code generation.  And that's the right thing
because it is dealing with static, compile time things.

> further, the GtkArg system relies on type names to adhere to specifc
> namespace conventions, which must not interfere with existing or
> temptative argument names, so having a type name like "signal" is
> not possible.

Then the GtkArg system clearly has a bug.

> > * `Fundamental' cleanups
> > 
> > GTK_TYPE_CHAR should really be a character and not a byte.  When we
> > move to unicode or something, GTK_TYPE_CHAR should be the right thing.
> > Thus, there is no such thing as an unsigned character and
> > GTK_TYPE_UCHAR should go away.  To compensate let's have GTK_TYPE_BYTE
> > and GTK_TYPE_UBYTE.  Should we go the whole way and totally follow
> > Java?
> 
> nope, GTK_TYPE_CHAR and friends do not correspond to a "character" type
> that's used to store possible chracters for different font systems like
> e.g. unicode representation, but it corresponds to the C type `signed char'.

Right, I want to change that.

The "char" type of C is bogus.  Someone once said, "C has no character
type, it has byte type that is spelled `c', `h', `a', `r'."

> a certain signal can for instance have a guchar parameter that is used for
> certain flags, or with a defined value range from 1..4 to indicate
> certain behaviour (action signals).

They should use GTK_TYPE_BYTE instead.
 
> > * Composite types
> > 
> > We should have support for lists and vectors (one dimensional arrays).
> > The static type system has no problem to express this with names like
> > 
> >     "(slist GtkWidget)"
> > 
> > for a GSList of GtkWidgets (or derived).
> > 
> > For the run-time representation, I plan to introduce a new fundamental
> > type for each `fundamental' composite type (GSList, GList, counted
> > vector, zero terminated vector, maybe vector of a certain fixed
> > length) and then derive a new type from these for each concrete
> > instantiation.  Like
> > 
> >     GtkType gtk_type_register_slist (GtkType content);
> > 
> > This function would create a new type that is derived from
> > GTK_TYPE_SLIST and store the content type somewhere into the `klass'
> > of this new type.  When such a type already exists, it is returned
> > unchanged, of course.  I don't expect to get very many different type
> > registrations.  The most controversial case is probably
> > 
> >     GtkType gtk_type_register_vec (GtkType content, int length);
> > 
> > GTK_TYPE_ARGS is a composite type, too.
> 
> hm, could you give concrete examples for possible uses of the above?

Suppose GtkList would have an signal "select_children" with this
signature:

  void (*select_children) (GtkList *list,
                           GSList  *children);

where each node of CHILDREN points to a GtkListItem.  The class
initializer of GtkList would create this signal like:

  GtkType list_of_listitems_type =
    gtk_type_register_slist (gtk_listitem_get_type ());

  list_signals[SELECT_CHILDREN] =
    gtk_signal_new ("select_children",
		    GTK_RUN_FIRST,
		    object_class->type,
		    GTK_SIGNAL_OFFSET (GtkListClass, select_children),
		    gtk_marshal_NONE__POINTER,
		    GTK_TYPE_NONE, 1,
		    list_of_listitems_type);


I'll comment on the rest later.