Re: Scripting in Gnome



On Fri, 2004-01-30 at 09:46, Tim Peoples wrote:

> Along these lines, I've had an idea bouncing around in my head for
> a few months now.  Somewhat of a marriage of glade (the xml format),
> javascript, Gtk+/Gnome bindings and some sort of web service protocol
> (xml-rpc or maybe soap/wsdl) into something I have initially called
> "Gnomescript".  While I only have a cursory understanding of DBUS, it
> definately looks like it fits in quite nicely.
> 
> I'll admit that I haven't put much work into it after my initial frenzy
> of binding a few Gtk+ widgets into Mozilla's SpiderMonkey... mostly
> because I was somewhat leary of whether such a beast was really
> necessary or not (like was said elswhere, we already have Python and
>  Perl and ....)
> 
> Originally, my idea was leaning more towards "remote applications"
> somewhat like Mozilla's XUL but much more Gnome specific... but soon
> expanded that to something more akin to VB on Windows (but without
> all the ugly baggage the VB carries).  You'll have to admit that the
> availability of VB on Windows in the early nineties somewhat helped
> MS achieve their dominance on business desktops.
> 
> All that said, I still do have plans to pick this up again... that is,
> unless I can be convinced that its not worth the effort (which may not
> be all that hard to do).

My personal ideas on the matter (which I may or may not have put in my
Advogato diary - I barely remember yesterday vs 6 months ago...) were to
offer an API for making clean and *easy* bindings to an application.  I
haven't looked much at the D-BUS API in recent versions so I don't know
if it counts as "easy" or as "pain in the ass."

The wrapper API should be generic enough that it can wrap *any*
scripting language.  It should support cross-process control (in which
case D-BUS would be great, altho we also already have ORBit/bonobo) and
*also* in process scripts.  (so that apps can get inline scriptability
for "free".)

Apps would then be able to have a "plugins" menu to load scripts (in
*any* gnomescript supported language, possibly even including C/C++)
that would just be inserted into the event loop.  Additionally,
processes could use the client-side bindings to attach to already
running processes as COM/AppleScript allows.  So I could write a Python
script to, say, have Epiphany open up a website and than call the
Screenshot program to grab a view, then tell Epiphany to attach the page
to a Mozilla/Gecko bug report, and then repeat for another site.  (This
particularly over-thought-out example would be useful if you've found a
big list of sites Gecko chokes on and you want to submit them to the bug
tracker.)

Really, the most important part is the API.  If you start with D-BUS and
work from there, you'll probably just end up with an API that just
mimics D-BUS, which is a complete waste of time.  The API has to let the
app register call-in points ("functions") and attach interfaces to
objects (OO), and then the low-level implementation of how these are
exported can be *completely* arbitrary; D-BUS for remote execution and
direct bindings to embedded language APIs for inline scripts.  Or
whatever.  Just make sure you start at the top and work down -
specification first, then API, then implementation details.  ;-)

> 
> Tim.
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]