Re: Scripting in Gnome

[Tim Peoples <tim toolman org>]

On Tue, 2004-02-03 at 14:22, Sean Middleditch wrote:
> On Tue, 2004-02-03 at 14:54, Bob Smith wrote:
> > Question. What would it take, to make GObjects self describing enough
> > for a scripting language to be modified to use GObjects automatically.
> 
> You really can't do this in a language like C.  You need to somehow tell
> the language VM which properties/methods there are, how to translate
> between the C types and the script types, how to handle memory
> management and the like, etc.
> 
> The best you could probably do in terms of automation is use something
> like SWIG to generate a binding from your header files, but your header
> files would need to be sure to include meta-data to ensure the bindings
> are correct.  Things like explaining which strings/pointers are freed
> automatically by the system and which the user/caller must free, etc.
> 
> That said, a good IDL description can make this very easy.  In AweMUD, I
> write the C++ methods/types with (almost) no thought whatsoever about
> the script bindings (my script language, Scriptix, is intended to
> integrate tightly with the host app, so types exported to Scriptix
> generally need to derive from a scripted base class, tho you could also
> write wrapper classes like with a traditional C scripting language).
> 
> I just describe the C++ constants/functions/types/methods in a
> simplistic XML format and run it thru an XSLT script to generate binding
> code.  Another XSLT scripting generates a Docbook reference manual. 
> Anyone could come along and write another XSLT script to generate
> bindings for a different language.
> 
> If someone were to think up a simplified IDL syntax to automate this for
> GObject based code (heck, even if you wanted to use AweMUD's document
> type and XSLT as a basis) and evangelize the project, you'd have the
> problem mostly solved, I'd wager.  ;-)
> 
> A method description might look like the following.  (yes, I personally
> avoid using attributes, I hate those things)
> 
> <type>
>   <name>GtkWidgetFoo</name>
>   <doc>This widget allows you to do Foo with love, honor and
> justice.</doc>
>   <method>
>     <name>doit</name>
>     <native>gtk_widget_foo_doit</native>
>     <return>
>       <type>string</type>
>       <native>gchar*</native>
>       <mustfree/>
>       <doc>The jazzy result of doing the foo in style.</doc>
>     </return>
>     <arg>
>       <name>bar</name>
>       <type>int</type>
>       <doc>How many times shall the foo be done?</doc>
>     </arg>
>   </method>
> </type>
> 
> You could probably make that more compact if you used attributes, and
> several of the names/constructs I put in that were purely to exhibit the
> ideas.  You wouldn't need to specify the native type/method names in
> most cases, for example, beacuse the XSLT script should know the rules
> for names.  Only the cases where the C code deviates from the standard
> would those be necessary.
> 
> The idea is, the XSLT script automates as much as possible.  For
> example, in most cases wouldn't need to manually specify both a type and
> a native type for a return value or argument, because the XSLT script
> would know what the default C implementation type for that is and how to
> convert it between the script language's version.
> 
> Likewise, the XSLT script would know in that for GObject methods, the
> pointer to the object must be passed as the first argument.  In cases
> where the default calling convention doesn't work, you could also insert
> code-fragments for the binding (which I do in AweMUD), which could look
> something like:
> 
> <call><![CDATA[ RETURN = gtk_widget_foo_doit(SELF, ARG:bar);]]>
> 
> SELF would become the pointer to the object, ARG:bar would be the
> already-converted-to-C version of the argument named bar, and RETURN
> would be the temporary storage for the return value as a C type, which
> the XSLT script would then use as input to convert to the script
> system's native type.
> 
> You can also use the code fragment interface to do other interesting
> things, like make methods on the script version of types with no C
> counterpart, and which instead has some custom C code embedded to do
> whatever.
> 
> You could make the XSLT scripts generate cleaned up output for Swig or
> something if you wanted to leverage existing language binding
> automation.  You could also export the interfaces over
> Bonobo/ORBit/D-BUS/XML-RPC/HAM radio/whatever automatically.  Pretty
> much all the app author ever has to do is add a few lines to their
> interface definition file and run make.  :)
> 


WRT bindings for Javascript at least... I spent about a week or so
back in November writing a few bindings for Gtk+ widgets and while
not difficult, it was somewhat tedious.

My next step was, as you suggested, writing an XML definition of each
type to be bound and then churning those through some XSLT to actually
generate the code.... this is, until I got distracted by shiney objects
(and overloaded at work).

All I need now is the proper number of "tuits" to actually make a go at
it... but, binding Gnome/Gtk+/Bonobo/etc... into Javascript should be
a no brainer (the object models map quite nicely).

Tim.

-- 
 _______________________________________________________________________
                                                      Timothy E. Peoples
                                                   Have Camel, Will Code
                                                         tim toolman org