Enterprise Desktop - Scripting

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun December 21 2003 11:01, Jim Bublitz wrote:
> "Scripting" means:

[SNIP]

> In most of these cases (I'll grant the distinction isn't crisp),
> I want to use Python as high level glue, not to write an app,
> but to perform a high level task using methods from existing
> apps (especially their data storage/processing/retrieval
> methods, like address book, mail, spreadsheet, etc). Moreover,
> in many (most?) cases, I want to do this from within KMail,
> KSpread, etc. as part of the app's GUI (getting the menu entries
> up is trivial - I want the menu entries to do something in code
> I write in a language I choose). I can probably do most of these
> things in 5-10 steps already - I want them to happen with a
> single click.

[SNIP]

> DCOP *may* be an advantage in doing some of this (I have to look
> at it more)

To do the above scripting the application needs to have entry points, you 
don't want to open up every internal function of the application because that 
will be a mess and it will turn "scripting" into "application development". 
You want to have a simpler better defined interface that provides scripts 
with entry points in the application. This is where DCOP comes in, with DCOP 
the application can provide in a very easy way an interface that it presents 
to the scripting world. This interface can then either be access via the DCOP 
protocol itself (e.g. via the "dcop" command line utility) or you can use it 
to make in-process calls from your scripting language to the application in 
which the script is embedded.

As for javascript vs. python. That's really a decision the user has to make, 
using a plugin architecture there is really no reason why one scripting 
language should be preferred over the other. The applications all provide 
DCOP-based scripting interfaces (they still need a lot of improvement though) 
and the scripting engines only need to provide a way to hook themselves into 
the scripting architecture and bind themselves to DCOP exported interfaces. 

What we now need is to flesh out this scripting architecture so that we can 
tie scripts to KActions via the XMLGUI framework and have hooks in place so 
that we can load arbitrary script-engines to execute such actions.

E.g. kmainwinui.rc now has code like this to describe the KMail "Message" 
menu:

  <Menu noMerge="1" name="message" >
   <text>&Message</text>
   <Action name="new_message" />
   <Action name="post_message" />
   <Separator/>

It should be possible to add your own actions to that with something like:
   <Action name="send_inquiry" script="ruby">
      ...some ruby script...
   </Action>

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ KDE: K Desktop for the Enterprise ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/5hcbN4pvrENfboIRApQhAKCX91XWDdC4V4Gv25WwMkTRTjHFrQCfYKtj
INSqEeB+FQmCfG1JnFOE0y0=
=rsVi
-----END PGP SIGNATURE-----