Re: [gtk-list] Re: A description format for Gtk features

[Owen Taylor <owt1 cornell edu>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> [ ... ] The callback wouldn't get a single GtkArg but a sequence of
> GtkArgs that hold all arguments and a way to return a value.  That
> is almost genuine dynamic typing and it might be better to add
> support for that directly to ILU.  Or not.  I don't know.

The thing is, ILU is meant to work with languages with languages like
C++ and Java, where dynamic typing would be a monstrosity.

[ ... ]

>> It would be nice to have statically type-safe solutions where
>> possible, since it is much harder to make statically typed languages
>> act like dynamically typed ones then vice-versa.
>
> Yes, but Gtk currently uses something resembling a dynamic type
> system, if only internally.  Using the signal mechanism from a
> statically checked language like C is not type safe at all, currently.

Yes. However, GTK's type system is conceptually static. (Which is good,
since otherwise doing language bindings would be a nightmare.) And
it seems that language bindings often need extra effort now to
translate from GTK's dynamic representation of its type system to the
language's static view. What you seem to be doing is adding this extra
step for things like enums as well.

And I do think we should try to make it possible for languages to
provide a type-safe interface to the signal mechanism. (Funny, I'm
sounding like a static-type-safety bigot here, and I'm usually pretty
much on the other side.)

> We could try to improve that but I have the feeling that it would
> involve a significant redesign and we would gain very little.  But if
> you have some ideas I would be happy to include them in the type
> proposal.

As long as languages can use the GTK type system in a static fashion,
an internal dynamic structure isn't really a problem. But if every
language converts it back to something static, it isn't doing much
good either.
 
> > > I want to do exactly that.  But I started to design my own IDL thingy
> > > that is custom-made for Gtk (before knowing about ILU).  I still think
> > > that a custom-made IDL is viable, because it is not too difficult and
> > > we can keep it reasonably efficient.
> > 
> > Hmmm, I see your strategy as a bit different - to provide enough
> > information about the core to allow language specific interfaces to be
> > built. Which "just" makes the N interfaces easier to build, while the
> > ILU approach would, in theory, mean writing only one interface. 
> 
> Yes, there are multiple parts to it.  One is to define a language to
> describe the interface in, a IDL.  Another is to make Gtk more aware
> of the needs of such an formalized interface description.  The next is
> to actually codify the interface into this IDL.  The third will be to
> write stubbers to generate code for a specific language.  If you want
> to go further you might add some network marshallers for all the
> umpteen network protocols out there.

If you want to make something talk IIOP, you need to have a type
system that looks pretty much like that of CORBA IDL ... So rather
than writing network marshallers that work with your type description,
it would probably be a lot easier to, along with the generators for
the GUILE, Python, Perl, etc. interfaces, to make one for ILU, and let
that do the dirty work.

> > Not to say that your approach isn't sound. In fact, (though I haven't
> > looked at the implementation yet), it seems to cover the necessities
> > pretty well, at least for languages where static type safety isn't an
> > issue.
> 
> I think it pretty much reflects the current Gtk situation in this
> regard.  Things can be statically described where Gtk has a prototype
> or some other C declaration in a header file.  The rest (which isn't
> much), like signal callbacks, are not covered by the static
> description.
> 
> We could certainly add static information about these things to the
> description, like
> 
>     (define-object GtkObject ()
>       (signals
>        (none destroy)))
> 
>     (define-object GtkWidget ()
>       (slots
>        (string name))
>       (signals
>        (bool event (GdkEvent event))
>        (bool enter_notify (GdkEvent event))))
> 
> Etc.  Do you have a use for that?

Errm, well at this point I should admit that the only languages I'm
actually using now are C and Perl. But yes, I think it would be a good
idea. You could certainly use this information to generate the
necessary callback objects in an IDL interface. 
 
> Then it is crucial that these types are detailed enough to guarantee
> type safety.  For example, strings are passed as a GTK_ARG_POINTER, but
> GTK_ARG_POINTER is also used for any number of different structures;
> booleans are passed as GTK_ARG_INT, but GTK_ARG_INT is also used to
> pass enumerations.  Even some GtkObjects are passed as
> GTK_ARG_POINTER, but that might be a bug.

No argument here.
 
> It would also be nice to hand out enough information to do *all* type
> checking in the high-level language, not just enough to prevent
> crashes.  That means being told that a function expects a
> GtkRadioMenuItem and not just a GtkObject.  (This is currently only
> relevant to the static descriptions, but I don't think it hurts to
> unify the type system for the static descriptions with the run-time
> type system).

This information should be present already in the C interface, at
least for function prototypes. Unfortunately, for signals, usually the
only thing that is known about the object is that it is an Object
(because of gtk_signal_connect_object). So the language needs to have
some way of safely downcasting, though that should exist in most
languages.

Regards,
                                        Owen