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

[Marius Vollmer <mvo zagadka ping de>]

Owen Taylor <owt1@cornell.edu> writes:
> 
> Maurizio Vitale <Maurizio.Vitale@esat.kuleuven.ac.be> writes:
> 
> > IDL: can generate stubs in different language (one implementation, ILU
> > from xerox PARC does C, C++, Java, Common Lisp with a somewhat less
> > supported/debugged Guile stubber).
> > IDL compilers are freely available, don't have to design/document your
> > own and you get a big chunk of CORBA interoperatibility for free.
> 
> I've done a bit of research recently on this issue, and I thought I'd
> report my results.
>
> My basic conclusion is that IDL isn't suitable for describing the
> existing practice in GTK (I'm mostly talking about ILU's subset
> of IDL, but the conclusions here are, I think, the same for full
> IDL, and for ILU's ISL.)

Yes, I came to the same conclusion, but I only quickly thumbed thru
the ILU [when it would be GPL'ed, would it be named IGLU? or GLU?]
documentation.  ILU seems to be very `cool' technology but it attacks
a much broader problem than we have here.  I have the feeling that we
might loose all the advantages of using an existing implementation
while fighting this same existing implementation.  It would probably
mean much more serious changes to Gtk.  And I already had most of my
custom infrastructur in place to generate stubs for Guile. It's only
some 500 lines of quite hackable Scheme compared to the 2.8 Meg disty
of ILU.  The other language bindings are not much different I think,
and when we combine our efforts we should get a very slick and
managable glue machine.

So I think that ILU is overkill for my/our purpose of interfacing Gtk
to high-level languages.  That does not mean that a ILU description of
Gtk wouldn't be great.  I just think that it is too much work right
now, atleast for me, who hasn't any experience with ILU like things.

> Some of the relevant points.
> 
>  - IDL doesn't support flag types. (OK, you can define constants
>    and do bit operations on them, like in C, but this is by definition
>    not typesafe, and highly unnatural in most languages)
> 
>  - 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.

I have done that for my Guile/Gtk bindings (it's of course useful to
every language binding) with gtk_signal_connect_no_marshal in my Gtk
patch.  Works great.

>  - (minor) All functions in IDL are member functions.

But there are `singleton' classes whose member functions are all
essentially `static' in the C++ sense.

> 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.
 
>   Python \
> 	    \
>   Guile     ----- ILU ---  Gtk
> 	    /
>   Perl   /

While I'm mostly interested in Guile, I'm more than willing to go out
of my way to support other languages equally well.  Unfortunately I
don't speak neither Perl, nor Python, nor Objective C.  Much less am I
familiar with their foreign function interface.  So my first try will
be quite Guile centric.

> Advantages:
> 
>  - There would be only one interface to maintain for any language
>    supported by ILU.
> 
>  - An ILU interface will probably have to be written eventually for
>    GNOME.
> 
>  - You could effortlessly have several languages running in one
>    process (and different processes!) using the same widgets.

That (different processes) would be a *very* nice feature.

> Disadvantages:
> 
>  - People would have to have ILU installed.
> 
>  - There would be some double-thunking overhead
> 
>  - The interface might not be perfectly natural for every language.
> 
> Flag types would presumably be represented in such an interface by a
> sequence (i.e., array/list) of enumeration elements. This is good
> for most  languages except ones which are fundementally C-like
> (C++/objective C).
> 
> There would have to be a separate object type for each species of
> callback. The default interface might not be to smooth for all
> languages, for instance, in Perl you would have (approximately):
> 
>   $button->signal_connect_clicked ( new Gtk::Button::Clicked (
> 		                    \&callback, $arg1, $arg2 ));
> 
> Though syntatic sugar could be provided.
> 
> Such an approach to language interfacing would definitely have its
> advantages, and we may end up there eventually in any case. But it may
> be over-ambitious in the short term, especially since there good
> interfaces already exist for most important languages.

Yes.