Scripting in applications

I was interested to read Havoc’s post about scripting in applications.  I’ve often said that, as with any other right, the right to modify your software is no good if you can’t use it– and if you need to know what a compiler is, most people throw up their hands in horror and say, “But I’m not a programmer!”, whereas typing a few lines of magic into a textbox somewhere is a gentle introduction.  After all, the first one’s always free.

(But I do have to wonder whether it would be a sensible idea to allow, say, Metacity to bind keys to JavaScript scripts.  If it would, aren’t we turning into Sawfish?)

Another question: What are the benefits of doing this in-process, rather than having each program expose a D-BUS API which can be called by some kind of central daemon?  Would we want the script engines in each program to be able to signal the other programs in case a user wanted to write script to say “play Bach when I load my work spreadsheet”, or would each scripting environment be able to access only the one application?  When the user wrote any one script, would they be presented with it as part of a given application, or would it be possible to write platform-wide non-application scripts?

I think that rather than doing this piecemeal, we should consider a platform-wide policy about what language(s) are acceptable, so that people can transfer their skills from one part of the desktop to another.  They don’t necessarily have to be good to write large and complicated programs in, but they do have to be non-threatening , which JavaScript manages pretty well (consider the success of BASIC in the eighties, which raises other spectres).

I may be asking silly questions.  I often do.

Published by

Thomas Thurman

Mostly themes, triaging, and patch review.

6 thoughts on “Scripting in applications”

  1. KDE does this already, and it is really nice. I can script pretty much every part of my KDE desktop.

  2. You might want to read up on AppleScript, AppleEvents, OSA embedding, BeEvents, and Automator. I know that’s a lot to read, but scripting is a big topic.

  3. From a security/robustness perspective, an external scripting process + DBus to script apps makes the most sense, as if the scripting host dies it won’t take out scripted process.

    (Though if the scripting host dies, this could possibly leave the scripted process in some unstable state, so this isn’t a panacea.)

    Relying on DBus also allows for a variety of scripting languages — anything with DBus bindings could be used, including Python and C# as well as JavaScript, without requiring that the scripted process actually host those runtimes (which would increase memory use for all scripted apps, particularly since it’s rare that _all_ memory used by the host engine is sharable by all apps).

    And if DBus can’t support this…why not? Win32 COM certainly can (allowing Windows Scripting Host to act as the scripting engine dejure to use VBScript or JScript to automate any COM-scriptable application).

  4. Wes: Are you saying the person implementing scripting should read up on all those before they implement it, or that I should read up on them to answer my questions or before I attempt to discuss it at all or just for general interest?

  5. fwiw I wasn’t really talking about third-party scripting, I was talking about implementing the app itself in an embedded scripting language.

    The problem with Sawfish wasn’t really that it was in a scripting language; the problems included 1) it was a weird custom lisp, so a bit hard to figure out, 2) the emphasis on being a window manager construction kit instead of a window manager, i.e. emphasis on third party scripts and extensibility to the point of compromising the default behavior, and 3) the maintainer (a nice guy) went to work at Apple and there was missing maintenance.

    You can very well write something in a scripting language without screwups like making config files be programs instead of data.

  6. It’s two complementary domains, I think. DBus-scripting (like AppleScript) is about automating control of software. This is good. Gnome should have this. In fact, why don’t we already have it? For a minimal implementation all you’d need is a decently simple to use wrapper around a set of Dbus-bindings for whatever scripting language you want to use along with some convenience functions for common Gnome apps and use cases (things like “stop all media from playing”, and “Mr. Spreadsheet, what’s the value of cell A4 in the ‘Page 2’ sheet?” without everyone having to figure out how to do that out on their own).

    What people talk about now is implementing the internal logic of an application in a scripting language. This is also good. Emacs would not have become the bloated monstrosity^H^H^H^Hpowerful tool it is without it. We should have both.

Leave a Reply

Your email address will not be published. Required fields are marked *