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

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <owt1@cornell.edu> writes:
> 
> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> > >  - GTK's callbacks can't be represented very well. (Not suprisingly -
> > >    they are fundementally not type safe)
> > 
> > Maybe we could unify all callbacks.  Every signal handler has exactly
> > the same type.  It would get its arguments from something like the
> > GtkArg structure.  But that looks like shifting the type issue from
> > the whole callback to the individual GtkArg.  ILU has dicriminated
> > unions, right?  Maybe they can help.
> 
> Unfortunately, this isn't true. The event signals all have similar
> types, but other signals "clicked", "size_allocate", etc., differ.

Yes, I know.  I didn't express myself properly.  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.

> I don't thing throwing the GtkArg structure (or an improved version)
> at the client is a good solution, at least as a visible interface,
> though it's a good solution for custom-written language bindings in
> languages that are reasonably dynamic.

Yes, and that's all I'm caring about right now.
 
> 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.

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.

> > > However, before throwing out the concept of IDL, let me toss out
> > > another possibility. Most of the issues above are issues that would
> > > be encountered in interfacing to any object-oriented language. So it
> > > would be possible to define a high-level interface to GTK in IDL, bind
> > > GTK to that, and then make all other languages talk with the high
> > > level inteface. (Presumably using ILU)
> > 
> > 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.

ILU might save us from having to do some of these steps, but it might
seriously complicate the others.

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

> Though I'm still not convinced of the need to have a dynamic
> type system beyond the widget heirarchy...

When we install the static description, we might completely get by
without dynamic types.  But they are there anyway in Gtk and I want to
use them.

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.

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