Re: Scripting in Gnome

["John (J5) Palmieri" <johnp martianrock com>]

On Thu, 2004-02-05 at 13:46, Bob Smith wrote:
> Exactly. This was what I was talking about when I suggested making
> GObject's self describing. a GObject could then be introspected by
> CORBA, DBus, Python, Whatever to allow the scripting functionality
> easily. I think GObject's properties are self describing currently but
> methods are not. Anyone know what else would need to be described to
> make this possible?

GObjects is already introspective.

--
J5

> On Wed, 2004-02-04 at 19:57, James Henstridge wrote:
> > On 5/02/2004 11:06 AM, jamie wrote:
> > 
> > > Sounds very promising. The examples were interesting because thats the
> > >
> > >kind of stuff im interested in too. I was thinking more on the way VBA
> > >does things - It has application specific objects which provide a nice
> > >clean object interface to scriptable stuff in an application so i would
> > >want to replicate that and also allow a macro to interact with other
> > >apps in the same way ( the object interface would of course hideaway the
> > >bonobo calls and other glue that AT-SPI uses). Its good stuff - strange
> > >that it was hidden away, you should definitely talk it up a bit more...
> > >  
> > >
> > What you mention here is not a feature of VBA.  Instead, the feature is 
> > that pretty much every non-trivial Windows app exposes APIs via the same 
> > scripting interface (COM).  VBA (and Jscript and Python and Perl and 
> > ...) have a binding for this scripting interface, which essentially 
> > gives them the ability to script these applications for free.  This is 
> > possible because COM provides an introspection interface, so the VBA 
> > interpreter can find out what methods exist on an object, and how to 
> > invoke them.
> > 
> > If the majority of apps on the Gnome desktop exposed their object model 
> > via CORBA, then a CORBA binding for a scripting language would give 
> > similar benefits to VBA's COM glue code (and if most apps exposed the 
> > document model via dbus or dcop, then a dbus or dcop binding would 
> > provide those benefits).
> > 
> > Following on from this, you can probably see that choosing a language is 
> > a very small part of making "Scripting in Gnome" work.  The hard part is 
> > getting all the applications to support it.
> > 
> > For the Linux desktop, this is particularly hard because it isn't clear 
> > which scripting interface should be used.
> > 
> >     * For Gnome, the answer would probably have been CORBA a few years
> >       back (this is less clear cut these days).
> >     * For KDE, the obvious answer is DCOP.
> >     * For Mozilla, components are exposed in process to Javascript via
> >       XPConnect.  They don't have an out of process interface.
> >     * I think OpenOffice also has something similar to Bonobo or XPConnect
> > 
> > The language support for each of these different solutions is different, 
> > so a developer's choice of interface will affect who can actually use 
> > it. Maybe in the future dbus will fill the role of "the scripting 
> > interface for the linux desktop", but it isn't quite ready for prime 
> > time yet (as far as I know).
> > 
> > James.