So right now, without modification, I should be able to write a python module that introspects a GObject and creates a binding on the fly? Or I can create a program to generate IDL and a set of stubs/skels for making a CORBA object out of the GObject by inspecting the GObject? If so, sweet. We're almost there. If not, what more is needed to do this? On Thu, 2004-02-05 at 12:18, John (J5) Palmieri wrote: > 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. > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part