Re: GtkType stuff

[Tim Janik <timj gtk org>]

On 26 Aug 1998, Marius Vollmer wrote:

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

yep, but most of them correspond *very* closely to C-related types,
since those are more or less "wrapped" by glib types, which is what Gtk
uses throughout the code, the fundamental type names should actually adhere
to that as well.
you might want to argue about the usefullness of the basic types defined
by GLib, but that seems to go more into a religious war, than into something
technically usefull.
anyways, the decision to make Gtk use the underlying Glib types has already
been made (right upon the creation of Gtk).

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

nope, this was needed to distinguish argument names that have a type
identifier from those that don't.

> > > * `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'."

if i get you right, you argue that GTK_TYPE_CHAR which corresponds to
the C type `char' should be renamed to GTK_TYPE_BYTE, because the C
language "char" type should have been named "byte" in the first place?
and that's the reason you want to change all GTK_TYPE_CHARs into
GTK_TYPE_BYTE for all existing Gtk code?

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

let that be -5..+6 or 102..242, you want a GTK_TYPE_SBYTE (signed) also?
as i said, GTK_TYPE_CHAR corresponds to the C type "char", and unless
an upcoming C standard replaces the "unsigned char" type with "byte",
i see no reason why Gtk should do this. finally, Gtk is implemented
in C, and if you want your scheme bindings to use "byte" instead
of "unsigned char", you can probably produce some glue code for
that as well, though i'd guess people would become majorly confused...

> > > * 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);
> 

hm, this looks actually quite appealing, but gtk_type_register_slist()
would probably better be something like gtk_type_slist_container() or somesuch,
which deals with reinvokation for the same pointer type.

> 
> I'll comment on the rest later.
> 
> 

---
ciaoTJ