application scripting

Chris Liechti cliechti at
Mon Nov 26 00:13:23 CET 2001

[posted and mailed]

Keith Ray <k1e2i3t4h5r6a7y at 1m2a3c4.5c6o7m> wrote in
news:k1e2i3t4h5r6a7y-477B3A.14113525112001 at 
> So... no one has every implemented recordability in a Python-scriptable
> application?

no i have that done neither but i write down my thoughts so that you're not 
left alone with you message ;-)

> In article 
> <k1e2i3t4h5r6a7y-52C738.09510621112001 at>,
>  Keith Ray <k1e2i3t4h5r6a7y at 1m2a3c4.5c6o7m> wrote:
>> Introduction:
>> AppleScript is the only ScriptingArchitecture that I know about that 
>> allows recording. An application is recordable when all (or most) 
>> user-interface handling results in the generation of one or more 
>> AppleEvents, which are directly routed to the application itself for 
>> execution. The AppleScript system can record these AppleEvents in a 
>> script, which the user can then edit. This can be a very user-friendly
>> way for a user to start scripting, but of the relatively few 
>> applications that support AppleScript, even fewer support
>> recordability. 
>> Mac Applications that are scriptable, but not recordable, have an 
>> architecture something like this: 
>> [GUI] -> commands -> [Model] <- commands <- [ScriptEngine]
>>                          Scripts or AppleEvents --^
>> but recordable applications have an architecture like this: 
>> [GUI] -> AppleEvents -> [ScriptEngine] -> commands -> [Model]
>>   Scripts or AppleEvents --^

i dont know the mac that good. i guess that you want to say that there is a 
mac specific way to do control apps (AppleEvents). This seems to be similar 
to COM in the windows world.
recordable apps have to provide a menu point to start/stop recording, 
because only the app itself knows what input events create what actions in 
the script.

the text below does not use system specific features, only embedded python.

>> Questions:
>> Can anyone describe how recordability would be implemented in a C++ 
>> application with (embedded) Python? 

i assume that the python interpreter is embedded and available for the user 
that wants to write scripts (eg a menu entry to start the recorded scripts 
and maybe an interactive console, could be nice for testing).

your app has to provide a module that exposes the methods of your model to 
python (load/save file, modify data etc.).
a python script with recorded commands for your app begins with "import 
app". for simple apps it is sufficient to provide some functions in the 
module, for larger apps i would recomend an object oriented approach.

>> Would a Python-embedded application have to generate Python source
>> code, to implement the recordability pattern shown above? 

yes, but thats realy simple. every action just writes out one line of 
python code plus some standard text would be copied at the begining of a 

    	import app"file")

for OO scripts you would have to generate some variable names too:
    	import app
    	document ="file")

maybe you want to have a look at some sample COM scripts. the approch is 
slightly diffrent but its the way msword, excel and may other windows 
software is scriptable (ms uses vbscript but there are python bindings too 
(win32com extension modules from active state))


Chris <cliechti at>

More information about the Python-list mailing list