Kross - The Scripting Framework

Speaker: Sebastian Sauer

Kross is the scripting engine for KOffice and provides a complete framework to embed scripting interpreters transparently into native applications and bridge that way worlds together.

KDE does provide a rich set of bindings for different languages. PyQt/PyKDE, QtRuby and even developing KDE-related tasks with Java and C# is supported. If it comes to embedded scripting the choose got cut down to QSA and KjsEmbed which both provide an embedded JavaScript-interpreter with a very small subset of the functionality, existing modules and 3rd-party support other languages like Python or Ruby are enjoying. There is no cpan-like collection of 3rd party modules for nearly everything, maintained and improved by large communities and reusable for own tasks.

The open source world is about choices, about reusing functionality and about flexibility. So, why not increase the number of supported languages which could be embedded into an application? Well, writing the code to embed the Ruby-interpreter into an own application, writing more code to add Python, LUA or Perl support and then write bindings for your applications internals for each single supported language would be the consequence and that's only for one single application cause every application provides own bindings, the developers prefer one interpreter over another and at the end we would reinvent the wheel for each single application that likes to embed the interpreter the developer likes most.

What is needed, is an transparent and scripting-interpreter independent way to deal with embedded scripting. That is where Kross comes into the game. First it is transparent cause the application that uses Kross doesn't need to know what scripting-language is used at all. All the application needs to know is, that there exists a library which provides scripting-functionality. Well, in fact the application doesn't need to know that too cause maybe Kross is provided and used within an application-plugin (that's how Krita and Kexi are including Kross) or maybe just as KPart if that's what the application prefers.

All the application needs, is the loaded plugin to pass objectinstances to it. The plugin and Kross will know how to handle those instances with some - again interpreter-independent - binding-code the application provides. Such bindings are implementing the interfaces that should be exposed to Kross and Kross itself will then take care of the scripting-backend or -backends. In fact even the core of Kross doesn't know what interpreter does finally evaluate the scripting code or how the evaluation is done. All this is handled by interpreter-plugins loaded dynamic at runtime. That means, we have a strict isolation of the interpreter-dependent code and the application itself does not depend on any interpreter! Even better, the interpreter-related code could be packaged separate and only installed if it's really needed/wanted by the enduser. That leaves us enough room to embed for example Java, Mono or Prolog if someday someone things, that his application needs it, without any dependency we would introduce that way. Even better, all applications that are using Kross, could from now on use the new interpreter too and that without one single line of touched code in the application or it's bindings and even without any recompile.

Python and Ruby are fully integrated and support for Kjs/KjsEmbed is planned. Both already supported interpreters are implementing the bridge with just a small hand of files (~5 per interpreter if I remember correct :-). The main work is done within the Kross-core the application and the interpreters are using to talk with each other. Well, in theory it shouldn't be that difficult to even let one interpreter talk with another interpreter that way.

It's even better. We don't reinvented the wheel rather then providing access to already existing technologies. So, you are even able to use the whole power of PyQt, PyKDE and QtRuby in your native KDE-application. You are able to build complex GUI's that way, include them at runtime dynamically as part of your application, connect signals and slots, trade object-instances, manipulate your KApp, access DCOP, QWidget's or whatever you like to archive. As example at Kexi we decided, that we don't like to depend on PyQt to display a simple GUI for a small ~100 line "Export Database-table or -query to XHTML File" python-script. So, we wrote additional ~100 lines of python-script to fallback to TkInter if PyQt is not installed and guess what; it works great. In theory even PyGtk should work (I never tried it), what means we are able to access Gtk at runtime without depending on it.

Kross started initial as part Kexi-plugin and was end of last year moved to koffice-libs. Cyrille Berger did a great job and doesn't only implemented the Ruby-plugin, but also wrote the very nice and powerful bindings for Krita. Isaac Clerencia wrote bindings for KSpread and KWord-support is planned.

Sebastian Sauer

Sebastian Sauer was born 1977 in Siegen, Germany and is located in Berlin since some years. He is a developer since the old C16/C64 days around 15 years ago. Some years ago he started to code with Qt and joined the KDE-project once KMLDonkey became an official part of KDE-extragear. Later he joined the KOffice-team and wrote Kross - the scripting framework.

When not coding for KDE he studies International Media and Computing, administrates debian-systems, reads fantasy books, tries to improve his english skills and enjoys his life.

Media

Video (Ogg) (137M)