Re: Scripting in Gnome

[Sean Middleditch <elanthis awesomeplay com>]

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

> For example, modify a Javascript interpreter to deal with GObjects. You
> could embed that Javascript engine in a given application and then do
> stuff to the GObjects in the application. Embedding Javascript in that
> fashion would feel like Javascript does in a web browser. You could
> easily do simple stuff like:
> 
> Rhythmbox.WindowTitle = "(Foo) - " + Rhythmbox.CurrentSongName;
> 
> Bob
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.