Scripting, Malaga and KDE 4

I'm now back from Malaga and have just about recovered, so I thought I'd blog a little about the discussions etc. I've been involved in over there. For me, obviously, the big questions were about scripting. Until now, KDE has been weak in the area of scripting applications - this will not be true of KDE 4.

First of all, we need to define what we mean by application scripting: In the discussions we've had at akademy we've limited it to ways to script the functionality of applications, and the ability to add minor customisations. We're not talking about full on RAD development here (that's Richard Dale's department). Obviously there is cross-over between application scripting and RAD as the two are opposite ends of a continuum, but the requirements and target audience are quite different. We want application scripting to be usable by system administrators who want to customise applications (eg. to fit with their corporate environment), by normal users, and by beginners. A few of use cases should help clarify this:

1. Consider a company that requires external email to be archived to a central repository. This not an appropriate piece of code to go in the general release of KMail, but it is a pain to handle it outside of kmail. By letting the sys admin code a script we should make it easy to make this supported.

2. Consider plasma - this will be the replacement for kicker and kdesktop in KDE 4. It should be possible for users to develop simple plasmoids (applets) without learning C++. These should be able to make use of the plasma libraries and be able to look 'cool' but will usually have only basic programming logic requirements.

3. Consider a user who is performing a repetitive task. They should be able to record it once then simply replay it for the subsequent times.

This is what we are talking about when we say 'application scripting'.

In order to achieve these goals, we need several things. Firstly we need a scripting language, next we need bindings both to commonly used parts of qt/kdelibs and to the applications themselves. Finally, we need a workbench in which these scripts can be developed. There are other components we'd like too - a macro recorder and KHotNewStuff integration (so people can download the scripts) spring to mind.

The challenge now is to develop these tools to a high quality as early as we can in the KDE 4 release cycle so that we can tightly integrate them into the applications.


Do you want to create another new scripting language, or do you want to use an existing one (like Lua, TCL, PHP, Perl, Python, Ruby)?

By gemuend at Sun, 09/04/2005 - 17:01

We'll be using Javascript (ECMA 1.5) for this. At the moment the code is all using KJSEmbed which uses KHTMLs KJS (this is also what apple uses incidently). Matthias has suggested we look at the forth-coming QSA 2, which we'll be evaluating when it becomes available. The new QSA will support ECMA 1.5 too, so we can migrate to it if we decide that is a better option.

By Richard Moore at Sun, 09/04/2005 - 17:11

Aren't the Kexi folks involved with a scripting system for KDE that will support arbitrary languages? That might be worth some investigation time.

By jel at Sun, 09/04/2005 - 18:21

Hi rich && hi others :)

Something like a year ago I started to develop the Kexi scripting bridge named Kross. My main goal was to have a interpreter independend scripting framework where interpreters are dynamic loadable plugins. Compared to kdebindings I concentrated mainly on embedded scripting (use scripting code embedded in an application for stuff like Macrofunctionality, etc.) rather then writting whole applications with the scripting framework. At the moment there exists a well working python binding for it that has only ~8 files of sourcecode. I even wrote some code for a kjs-binding which was quit simple too.

I don't propose to just use my framework rather then to look at it and take some ideas. We really need such a interpreter-independend solution. So, I like to help on the progress and developing to get something cool out for KDE4.

Will there be a wiki or something else where we could put techs-aspects, ideas, proposals, etc. at? Maybe better then to blog about it :)

By Sebastian Sauer at Mon, 09/05/2005 - 12:50

maybe just create some pages at to collect ideas?

By Sebastian Sauer at Mon, 09/05/2005 - 13:09

I don't propose to just use my framework rather then to look at it and take some ideas. We really need such a interpreter-independend solution.

Yes, we need an interpreter and language independent solution, autogenerated and covering the entire api including overriding virtual methods and so on. That is what we have in the Smoke library used for the QtRuby/Korundum and PerlQt/PerlKDE bindings.

I agree that a wiki of bindings ideas/techniques would be a good thing. Maybe there are some things in your current framework that could be used in the next version of Smoke for KDE 4.

By Richard Dale at Thu, 09/08/2005 - 09:47

This is REALLY great. KDE has great scripting features with DCOP etc., but no one knows about it. It'll be really nice to see that power become directly beneficial to users :)

But... please, for the love of god... make it work with python, too! :)

By jel at Sun, 09/04/2005 - 18:18

I won't be working on python support, if someone else wants to then they'll be made welcome.

By Richard Moore at Sun, 09/04/2005 - 19:24

That will be the job of us SK developers.
Drop into #superkaramba sometime. We just had a big discussion on SuperKaramba and Plasma today, and things are moving quickly.

By Ryan Nickell at Sun, 09/04/2005 - 23:23

Yeah, but that only covers a tiny subset of what we're looking at. Plasma is just one component - we're looking at the whole desktop and application framework.

By Richard Moore at Mon, 09/05/2005 - 12:04