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.
As for the other types of scripting:
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.)