Aaron wrote an interesting blog about scripting and dynamic language support, and I thought I'd like to add some comments of my own about where we're heading with non-C++ languages in the KDE 4.5 SC release.
Language bindings are infrastructure, and they are a kind of compiler technology. We take the C++ headers and compile them into a form that allows the C++ methods to be called in other languages.
Infrastructure technologies only really succeed when they become 'boring and invisible'. For instance, there are many products which are based on the Linux kernel, but Linux is so 'boring and invisible' that for the most part, nobody even knows whether their television, GPS system or router contain Linux, and the products 'just work'. Similarly, the gcc compiler just works and we don't worry whether or not our latest build will seg fault, because the project has got to the stage where we can depend on gcc and only need to think about building our code, without be distracted by worries about whether or not it will work.
I've been working on various language bindings and technologies for the Qt and KDE apis for about 10 years now. At first, my work was 'exciting and visible', and involved much heroics in getting something like a Java binding to work at all for the whole Qt/KDE api, let alone being complete, reliable and easily maintained. I'm excited to think that we are finally getting to the point where people will think language bindings are 'boring' and they expect them to just work.
The major bindings innovation for KDE 4.4 has been Arno Rehn's new C++ 'Smoke' library generator that he wrote for his Google Summer of Code project. We now have an industrial strength tool that can be used by normal people (as opposed to language bindings gurus) to produce language independent bindings libraries to wrap any KDE library. It is just a matter of creating a fairly simple XML file that consists mainly of the names of that classes you want to include, and a pretty standard simple cmake file to go with it, and then you're done. With a bit of documentation of TechBase about how to do this, and maybe some helper scripts we can make this really easy. This means that we can make a 'cultural shift' where people expect to create a bindings library for every KDE project as a matter of course, and that code will be part of their project instead of being inside the kdebindings svn module.
Mark Kretschmann of the Amarok project made some interesting comments on Aaron's blog about QtScript is the best language application scripting and extension. This is because on Windows, and the Mac to a lesser extent, even very common languages like Python or Ruby can lead to quite serious 'dependency hell' problems. I know how much Mark and some of the Amarok team like Ruby, and so I know that they wouldn't have switched to a QtScript-only policy for Amarok without pretty good reason.
So to summarize, I think we need to have a social change within the KDE project where languages bindings for non-C++ languages and scripting, are no longer 'fringe activities', but are part of the mainstream. We have made enough technical progress to be able make that change.
I have been talking about the Smoke based bindings, but I'm pretty sure Simon Edwards and others have got the PyKDE bindings to a similar stage of maturity, and I've seen some signs of non language bindings guys start to produce Python bindings recently which is really good. I hope more Python bindings will be created as part of a KDE app or library and be maintained in the same svn or git module, rather than in kdebindings.
A final exciting piece of news - today Chris Burrel announced this on the kdebindings mailing list:
"I'm interested in committing the work I've done on PerlQt4 to the
Woo hoo! I can't wait for KDE 4.5..