Connecting C++11 lambdas to Qt4 Signals with libffi (now portable)

I know that this is probably not very useful, considering that it’s not portable and with Qt5 about to be released in June, but I found it interesting to experiment with the new language features and libffi.

The result is a class which lets you connect any function pointer or lambda, with or without bound variables, to Qt4 signals. Example of what you can do with it:

Quite nice, I think :) You can get the source for lambdaconnection.h here.

Its main drawback is the use of pointers to member functions as ordinary function pointers. It works with gcc and maybe clang, but it’s probably going to break with other compilers and/or operating systems. UPDATE: By converting everything to std::function, we can have one template function which is called by libffi and handles any further lambda calls. No need for member-function-pointers anymore. Portability shouldn’t be an issue anymore, too.

Additionally, to avoid code duplication, it simply converts function pointers to std::function objects. This adds some overhead when calling the function pointer.

Anyway, it’s only an afternoon’s work and it was fun to code. Maybe someone will find this interesting :)

Java bindings?

Since the C# bindings are apparently not really used/wanted by anyone (except for some Windows people – but that’s really not my main development platform) I thought that maybe some more people are interested in Java bindings.

There was a poll on kdedevelopers.org two years ago that showed Java ahead of Ruby and C# – but it doesn’t seem to be really representative: there are at least some Ruby plasmoids on kde-look.org, but none in C# (which was still ahead of Ruby). Given that Trolltech/Nokia abandoned QtJambi I’m not too sure about Java bindings either.

So I’m asking the community directly before I start putting too much work into a project that noone really wants: So far we have (active) bindings projects for Python, Ruby and Perl – is there any demand for Qt/KDE Java bindings in the community? Or if not for Java, for any other language/platform?

Looking forward to your comments :)

And the bindings keep rocking: Writing Ruby KIO slaves

It seems like I got into a hacking frenzy after yesterday’s Ruby plugins for Kate. Today I sat down and took another look at the KRubyPluginFactory to implement KIO slave support.

So here it is, our very first Ruby Hello World KIO slave:

We’ll also need a rubytest.protocol file that describes our new protocol:

To test it, you just have to type rubytest:/ into konqi’s addressbar and you should see nice hello world greeting.

Some more info on the structure of a Ruby kio slave: the Ruby script always has to be named ‘main.rb’ and the SlaveBase derived class always ‘Main’. The module name is the camelized form of the protocol (so a protocol ‘foo_bar’ would map to a module name ‘FooBar’). The script has to reside in <kde prefix>/share/apps/kio_<protocol name>.
The .protocol file itself should be installed to <kde prefix>/share/kde4/services.

As with the Kate plugin, I packaged this example in a tarball. It ships a Makefile and can easily be installed to your home directory with ‘make install’.
I committed this feature to both trunk and the 4.5 branch – so you can soon start coding your own KIO slaves in Ruby! :)

Why KDE bindings simply rock (or: Creating our first Ruby plugin for Kate)

Akademy really speeds up development and communication between developers:
Yesterday I was poked by Milian Wolff and he told me how many people want to write Kate plugins in languages other than C++ and ECMAScript and how he always told them that’s not possible and probably a huge amount of work to get working. Well, that wasn’t entirely true:
If the target application has a SMOKE lib that wraps its API and an according bindings extensions, it works pretty much out of the box, thanks to the gorgeous KPluginFactory API and of course thanks to our gorgeous bindings.
Kate was a bit trickier to get working though, because it used old and deprecated API to load plugins. Well, I filed a merge request on gitorious about that, fixed a bug in KRubyPluginFactory and now I’m very proud to present

The absolutely gorgeous, simple, straight-forward, packed with all the Ruby goodness, very first Ruby Hello-World Kate plugin:


You’ll also need an ui.rc file that defines the actions to be merged into the Kate main window and a .desktop file which describes your plugin. Actually I’m too lazy to post them all here, so I made a nice package containing everything you need, together with a Makefile which can ‘make install’ the plugin into your home directory.

Since all SMOKE based bindings wrap the C++ API nearly 1:1 and only add syntactic language specific sugar on top, you can create nearly any plugin you like in any language, without modifying the host application, as long as the API is wrapped in a SMOKE lib and a bindings extension. In C# you can even create KIO slaves (a monodoc KIO slave example is shipped with the kdebindings tarball). That feature hasn’t been added to Ruby yet, but is on my ToDo list.

So praise the bindings, praise the KDE plugin infrastructure and start working on Ruby Kate plugins! :)

You can find the Ruby Kate binding and the SMOKE kate lib in current kdebindings trunk.

qyotoassemblygen progress

Some time back I have started a tool called qyotoassemblygen [0], which will hopefully ease the generation of .NET/Mono bindings based on SMOKE libraries. It basically introspects a SMOKE library and generates a System.CodeDom tree from that information. The CodeDom can then be used to generate C# code and/or compile an assembly.
Although some parts were rather difficult and had to be rewritten again and again (like checking whether a method has to be marked “override” or “virtual”), I can now announce that it”s quite stable and generates all of the Qt assemblies just fine :) . I”m currently working on getting the KDE assemblies to build, which is really just a matter of sorting out *Private classes.

By using plugins the tool is not bound to Qt-based bindings, so we could as well generate assemblies for other toolkits, like Wt (for which there is already a smoke lib, thanks to Richard :) ). Plugins will also make it easy to add syntactic sugar like event support for Qyoto (which I hope I can implement for KDE SC 4.5).

If everything works as expected, we can hopefully drop kalyptus completely in the next release and reduce our maintenance cost considerably :)

[0] http://websvn.kde.org/trunk/playground/bindings/qyotoassemblygen

Current git branch in shell prompt

Since I”ve read much about git and how great it is, I recently thought that I had to try it myself. And indeed, it is quite amazing and is nice to work with. There was one thing that I disliked, though: I never quite knew in which branch of my repository I was, especially after I”ve been away from coding for a few hours.
Of course I could just look that up, but I tend to forget that and then end up with code that belongs to a different branch. Now the shell prompt looked like a good place to show the current branch, but simply executing “git branch | grep ^*” would only work in the top-level directory of the repository. So I wrote the following function which will traverse all containing directories and look for a .git directory. Having found one, it will nicely print the the branch in dark green color, with a @ sign in front of it:

Update: As many people have pointed out, bash-completion provides a function called __git_ps1 which will happily print the current git branch and can be used as well. I don”t quite like the rest of bash-completion, though, so I”ll stick with my own.
As Yuri pointed out, git branch works from any directory, so here”s the updated (and much shorter :) ) version:

Having this in my .bashrc, I could integrate it quite nicely with my prompt:

Screenshot:
git prompt

Qyoto on Windows!

Now that the new smokegenerator is in trunk and generating smoke on windows shouldn”t be a pain anymore, I thought that I could dig out my nearly unused Vista partition on my laptop and start porting Qyoto to Windows.
First thing I did was removing the preinstalled Vista and installing it again to get rid of all the preinstalled crap Dell thought I needed. Next was installing Visual C++ and C# (the Express editions are free as in beer and work ok – nothing in comparison to KDevelop4 though) and KDE 4.3. Thanks to all of the KDE Windows team – you make Windows much more bearable! I also installed msys – can”t live without a proper shell anymore.

Now came the actual porting: To support MS .NET and not only Mono, I needed to add support for csc.exe (the MS C# compiler) to the existing C# macros. As I recently discovered how to add support for a new language to cmake (which lacks documentation but is really easy once you understood it) I simply rewrote the C# macros as a new cmake language plugin. Compilation was pretty straight-forward, then.
But as was to be expected, the examples simply crashed upon start. Long story short: Some of them work now and this is how it looks:

Qt tutorial t5 with Qyoto

This is still really unstable and crashes every few minutes with an AccessViolationException. Have to figure out why it does that.. But first I have to do some other things, mainly porting the remaining kalyptus-generated smoke modules to the new smokegenerator. This shouldn”t take too long, so I think I can complete the Windows port soon :) So stay tuned!

Update: The AccessViolationExceptions should be fixed now. If you want to try Qyoto on Windows and have problems getting it to compile or run, please send a mail to the kde-bindings mailinglist and include the complete error and backtrace. You can also search the mailing list archives since this topic came up quite often recently.

gsoc, week 11 – generating smokekde :)

Now that the Qt classes generate and compile fine (as Richard already wrote) I tried to generate the smokekde sources with the new generator last week.

After fixing quite a bunch of bugs that didn”t surface when generating smokeqt, it works now really well.
There isn”t much difference between the config files for qt and kde, too – it”s mainly the lists of stuff to include and very little stuff to be excluded (d pointers, q pointers, other private stuff…).
This really shows that the new parser is superior to kalyptus, which had dozens of hacks in it for the code to generate nicely.

In case you want to test it, get the source from /trunk/playground/bindings/smokegenerator. To make testing easier, I wrapped the generation in cmake, so a normal cmake; make; make install should build and install smokeqt and smokekde for you.

The new generator still generates a lot of code for deprecated methods, which isn”t really nice – but maybe the parser can be modified so it recognizes __attribute__((deprecated)) flags.
There are also still issues with fixed-width array types, which luckily don”t occur too often in KDE sources. This only affects KMD5 for the moment. I”ll fix this next week, so then should smokekde with smokegenerator be equal to smokekde with kalyptus :)

Hello Planet!

Hi,

my name is Arno Rehn and I”m a bindings developer. I”m working mainly on the C# bindings for Qt and KDE together with Richard Dale.

Currently I”m also working on my gsoc project – Rewriting the SMOKE generator using one of Roberto Raggi”s C++ parsers.
SMOKE is a library which provides the possibility to dynamically call methods on classes. It is the foundation for many of the Qt/KDE bindings, like Ruby, C# and PHP.
The old generator for the SMOKE sources is based on a perl tool, kalyptus, and only works with a bunch of hacks in the code. It tends to break on new releases of Qt or KDE which introduce new features.

The goal of my project is to create a stable and robust tool, similar to the moc, which you just run on the headers of your project and you then end up with a bunch of source files that are the basis for bindings for your project.

Eventually I decided to use the new parser from KDevelop4, since that has a pretty convenient API (unlike the QtJambi / qtscriptgenerator one). It took some time to remove the KDevPlatform/KDevelop specific bits, though. It would”ve also been nice if I could”ve used the DUChain from KDevelop, but that seems to be so tightly integrated that I would have to provide half of KDevelop to use it.

I”m pretty much ahead of time – the generator is nearly finished. By the end of the GCDS, which I”m attending until Thursday, it should be working completely – at least with the Qt classes.

P.S.: I know that gsoc has started quite some time back, but I was really to lazy/busy to start a blog ;-)