I'm sorry about the unwieldy title to this blog - I couldn't think of a shorter snappier way of putting it, but I'll try explain the tricky problem with 'C++ implicit type conversions' that I've managed to solve.

I've recently added a handy command line tool for introspecting the methods in Smoke libraries. Although it is mainly aimed at people using Smoke based language bindings, I think it might be more generally useful and worth describing to a wider audience.

Show all the methods in the QPoint class:

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.

It seems a long time ago, but in early 2000 I had just submitted my first patches to the KDevelop project and KDE. I had wanted to port the version of Squeak Smalltalk that ran under Apple's 'Rhapsody OS' to GNUStep, and I needed some sort of development environment to do that.

The Smoke based QtScript bindings are progressing well, and are now called 'JSmoke' in the style of 'JQuery' the JavaScript library or 'JScript' the .NET JavaScript implementation. In KDE promo-like words, I hope this will 'raise the brand recognition' of the state of the art KDE Smoke dynamic language bindings technology.

The project now has 24 QtScript plugins for the following libraries:

I was most surprised when the PySide Python bindings project was announced a few weeks ago. Simon Edwards wrote that "To be honest I'm not all that happy with the current situation." Meanwhile, I wasn't too happy that they had worked for eight months in secret without talking to the KDE bindings community either. I think that the PyQt/PyKDE bindings are very high quality and really well maintained, but if someone insists there really must be an LPGL'd Python binding, I personally would much prefer that it was based on 'Smoke'.

Using the Kubuntu distribution, I've been a bit envious of the Python bindings guys, because the bindings are installed by default and frequently get updated. So it made my day when I recently did an 'apt-get dist-upgrade' to get KDE 4.3 in my copy of Jaunty and saw that the KDE Korundum Ruby bindings were installed. This is great stuff Kubuntu community!

Several people have wanted to be able to write Plasma PopupApplets in scripting languages. I'm pleased to announce that for KDE 4.3 you will be able to write them in Ruby and C#.

I've translated the C++ example on TechBase Plasma/UsingExtenders. First, here is how it looks in Ruby. In the metadata.desktop file you specify a service of 'Plasma/PopupApplet' instead of the usual 'Plasma/Applet' like this:

The release team made a decision to branch the KDE svn for 4.3 in advance of the actual release. From the point of view of kdebindings I am finding it a highly error prone messy pain in the arse.

At conferences like the GCDS there is so much going on, and you get bombarded with information from all the talks one after that other, and that means that sometimes it takes a while for the meaning of it all to sink in. For me the two biggest themes of the conference were firstly the emerging Semantic Desktop, and secondly the increasing importance of visual design. We actually are in the process of inventing new ways of visual communication, and it was very exciting to be right there in the middle of it happening.