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.

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:

Yesterday I wore my GSOC tee-shirt at GCDS and got together with Arno Rehn to review his smoke bindings library generator tool. It turns out the project is going great and is pretty much finished.

I can't say I've done a lot of mentoring other than to have an initial discussion about which variant of Roberto Raggi's C++ parsers to use. We chose to use the KDevelop one with some KDE dependencies removed, although in fact from Roberto's comments on Arno's blog it might have been best to use the Qt Creator one.

Richard Stallman is giving a keynote talk about Free Software at the Gran Canaria Desktop Summit and I am very much looking forward to hearing what he has to say. However, I just read this short post Why free software shouldn't depend on Mono or C#, and to me what it is saying seems incoherent.

On the one hand he says that:

This is not to say that implementing C# is a bad thing. Free C# implementations permit users to run their C# programs on free platforms, which is good.

When you develop a language binding you never know what sort of thing people will develop with them, and it's really fun when people turn up with something. Yesterday I was chatting with Tobias Kappe on irc and he mentioned his Selene project that allows you to create dialogs in C# that are toolkit independent.

Tobias said that he was learning the Qt api, and the project uses the GTK as an alternative toolkit. Here is an example of how you can combine both in a single source file:

Yesterday I was getting the smoke bindings lib to build with Qt 4.5 with krege on irc, and one of the errors we were getting was with a private class called 'QMetaObjectExtras' that was failing to compile. I fixed it by making the generator skip that class, but I wondered what was in it. This morning I had a look and it turns out that the new moc has a very interesting and useful new feature; you can now have constructors in your QMetaObjects.

To get a constructor added to the QMetaObject, you just prefix it with Q_INVOKABLE like this: