Final Project status of Kontact-scripting

[Kun Xi]

Hello mentors,

Here is the final status report:

      Summary for Kontact-scripting

The original motivation of this project is to implement GTD( Get
things done) in Kontact via automated script add-ons. KJSEmbed is
selected as the script engine for the sake of the simplicity of
JavaScript. Our approach starts from a forked Kontact suite codebase,
then script/add-on[1] features are added step by step. The original
proposal "Common scripting/plugin subsystem for Kontact" can be
accessed from here :
<http://developer.kde.org/summerofcode/kontactscript.html>, current
SVN is hosted in:
$KDE_SVN/branches/work/soc-kdepim-scripting


Achievement

- Singleton script engine.

A singleton KJSEmbedPart is wrapped in the libkdepim, so it is quite
easy to add scripting feature to any application in Kontact suite. For
the case of Kontact, if the component is loaded as a part(i.e the
component is in the same address space as the host), kontact can
access component's script namespace. Otherwise, they have to talk via
DCOP interface. How to hide the difference to the script developer is
one of main challenges in the future development.

- Easy-to-use object proxy template

The main contribution of this project, in my opinion, is the
development of KABProxyImp class. This template is inspired by Kst
project. It encapsulates all routine procedures to expose one C++
native object to the script namespace, property, method and object
construction are fully supported. The derived class only needs to
implement few necessary functions:
  put/get if property is supported
  call if method is supported
  construct if the object construction is supported

Please take a look at the $TOP_DIR/libkdepim/kabproxy_imp.h and one of
the example: $TOP_DIR/kaddressbook/addressee_imp.(h|cpp). If you want
to add the scripting feature to your own application, KABProxyImp
could be a good start for you.


- Intuitive namespace management

Each component exposes all its objects to one specific namespace, that
would help to prevent name confliction. For example, KMail will expose
the following objects/methods:

Mail
  |_ Mail.Inbox
  |_ Mail.Outbox
  |_ ...
  |_ Mail.Message -- the message object which can be constructed via
new keyword.

So all KMail-specific scripts can be reused in the Kontact application.

- Poor man's debugger

Script debug is supported via JSConsole. The script developer can
output the debug information by calling "println" function, then
checks the standard error to troubleshoot the problem. JSConsole also
provides a interactive console for the developers.


Future work

Reture of the Signal/Slot

Signal/slot mechanism is implemented by simply exposing the Qt object
via addObject method[2] in the pilot development. This implementation
has lots of disadvantages: only slot function can be accessed from the
script; we lose the control of the object; etc. Current implementation
needs to "portmap" the signal/slot from internal object to the
external proxy.

Refactor, Refactor, Refactor

Never hesitate to refactor the code if it not simple. Currently, all
the call function in KABProxyImp-derived class is not so beautiful, we
need to figure out a more efficient way to validate the argument.

Security

An preference page should be added to customize whether the add-ons
are enabled or disabled. Futher feature would include security level:
if one add-on wants write privilege in the read-only security level,
the user is prompted to permit or deny this operation.

Load on-demand

When Kontact script wants to access Mail.Inbox, at that time, KMail
component is not loaded, the script engine throws an exception, the
native host would catch the exception and load KMail component and
continue the script. In a word, more interactivities should be
supported between the script engine and native host.


DCOP support

Hide the difference between the DCOP and Singleton script engine to
the script developer.


Acknowledge

Special thanks to google soc project, it provides such a nice
opportunity for me to read high quality open source code, otherwise, I
would never have the motivation to dig into what's inside the hood of
the Kontact. Thanks to my mentors and KDE developers, I always could
get help from all of you whenever I knock the door,
#kde-devel at freenode.org. And thanks to my wife, Angela, I really
appreciate your love and patience while I kept working for this
project.



[1] Plugin has been used in Kontact source code to indicate the parts
(aka kmail, korganizer), to avoid confusion, we use Add-on to indicate
any external scripts that can be loaded during run-time to implement
some specific function.

[2] Framework for embedding the KJS Javascript Interpreter
<http://xmelegance.org/kjsembed/classdocs/index.html>