Scripting in KDE applications

Today I watched Ian Geiser’s presentation on KSJEmbed thanks to the webcast from aKademy — it was a very interesting presentation and made me want to start coding scripting support for Krita immediately, but it didn’t solve my quandary: which engine to use.

I’ve got a lot of history in scripting and Qt, having once even written a book on PyQt. Ian mentioned three types of scripting: scripting from within an application, scripting running application through Dcop and finally writing standalone application using a scripting language. My interest at the moment is scripting from within an application, because Krita (and all of KOffice) needs that kind of scripting where your typical user can click on a ‘Make a script’ button, write their script and then assign that script to a toolbar button, and have had that need for that for ever.

Ian was very clear in mentioning that KJSEmbed has some problems, notably with memory management, object ownership and object mapping. The biggest problem however wasn’t addressed in his presentation: embedding a scripting interpreter in an application is only useful if users can edit and manage their scripts from within their application. That means an embedded gui designer and an embedded editor. I can live with almost any problem — I wouldn’t mind the language being the WordPerfect Macro
Language as long as I’ve got a drop-in engine + GUI.

KJSEmbed doesn’t have that: some noise has been made before about this not being hard, about using Qt Designer and KDevelop for that. However there’s nothing done yet, and it’s not an attractive idea to start spending time on that kind of infrastructure if I’d rather be working on Krita.

QSA from Trolltech already offers the kind of drop-in functionality, and even uses the same language, Javascript. Only there appear to be license problems with QSA, where there’s an ambiguity about whether scripts written for QSA need to be GPL’ed themselves. This is a real pity, because QSA was at a previous KDE conference announced as going to be used KDE-wide. (At least, I seem to remember a Dot article on the topic, but I cannot find it right now.) And the fun thing is, QSA is already a souped-up version of the kjs engine from Konqueror, just like KJSEmbed…

As for the other types of scripting:

Ian was also a little dismissive of Python, sip and PyQt, which rankled somewhat with me. However, given the relative immaturity of KSJEmbed, the serious limitations in the type of arguments slots can have and the other limitations Ian mentioned, I’d still use PyQt/PyKDE for standalone applications written in a script language. Phil Thompson has solved those problems already, and quite a few others, too. And then I haven’t even started on the whole issue of Javascript versus Python as a language :-).

As for dcop scripting, I’ve never seen it much in use: it’s nice to write GUI test scripts, in theory, but I’ve never found much other use for it, myself. (Which is not to say dcop is useless, it’s just better used to tie applications together in ways that users don’t even see.)