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

[Owen Taylor <owt1 cornell edu>]

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

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.

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

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. Though I'm still not convinced of the need to have a dynamic
type system beyond the widget heirarchy...

Regards,
                                        Owen