KDE to Get Mono C# Bindings with Kimono; Qt# Speaks of Sabotage

The aim of the Kimono project on KDE is to write a complete wrapper for KDE/Qt using the Mono framework and is based on early work by KDE bindings hacker Richard Dale. Kimono uses KaXul, a fully XML-based representation of the UI, the Dot reports. However, the changes made to KDE in preparation for Kimono has left the other binding effort, Qt#, orphaned with a dead dependancy: QtC.Marcus Urban from the rival Qt# project spoke of ‘sabotage‘ and later communicated with us regarding the issue:

This is probably going to turn into a long history of events. Basically, Adam Treat started Qt# a couple of years ago, and Nick and I joined him on the project. Qt# depends on Richard Dale’s QtC to call C++. (If we had something equivalent to MS Managed Extensions for C++ this extra layer could be integrated into Qt# more easily. It would require a tool capable of compiling C++ and emitting both CIL and native code.)

QtC is produced by KDE’s Kalyptus tool. However, the resulting C code was not compilable and required substantial hand-editing. We also had some problems because QtC was not completely in sync with Qt#. We tried to contact Richard at some point, but he disappeared from the internet for several months. So we felt like we (Qt#) were on own our as far as a C glue library. So we began to investigate alternatives to QtC.

One of the alternatives was simply to generate our own C library with more customized functionality, but produced by our own tools so that Qt# and the C glue library would be in sync with each other. Another alternative we investigated was Ashley Winters’ SMOKE library. However, SMOKE seemed best suited to scripting languages were high performance was not a priority. Also, I could not find any documentation on SMOKE. I heard that Ashley’s new Perl Qt bindings would use SMOKE, but I do not know enough Perl for that to be helpful. In other words, looking at Perl bindings that used Smoke would be be helpful.

When Adam was still working on Qt#, Adam, and I tried collaborating with Ashley, but those efforts were largely unsuccessful. After a few IRC chat sessions and email exchanges, it became clear that we had different views on

A little over a year ago, Adam stopped actively working on Qt#, and I tried to work on it myself. Unfortunately, I was very overwhelmed because we were in the middle of moving to an entirely new codebase at the time. It was not just an issue of people-hours, but I lost the only person who I could really talk to about Qt# on the very technical level. Emotionally, it left me very discouraged, so I did not release a version of Qt# for about a year.

Around this time, Richard Dale announced that he was seriously working on another C# binding for Qt using SMOKE and remoting classes. Previously, he had posted some musings about this on kdebindings list, but that was all. Then he announced his intentions to remove QtC from kdebindings. I said that in the future that would be fine because I was working on something to replace it. However, I was not expecting that he would remove QtC immediately, as he did. He also complained that compatibility with Qt# prevented him from updating QtC, but he never contacted me to advise me of this.

Marcus Urban

Update: Adam Treat, the creator of Qt# replied to the issue in our commenting section.

Update2 : In our comment’s section we had some people saying that this is April’s fools news, but these claims are false. OSNews does not follow this tradition in general. The above reply from Marcus is real.


  1. 2004-04-01 5:28 am
  2. 2004-04-01 5:45 am
  3. 2004-04-01 5:53 am
  4. 2004-04-01 5:55 am
  5. 2004-04-01 6:00 am
  6. 2004-04-01 6:03 am
  7. 2004-04-01 6:08 am
  8. 2004-04-01 6:11 am
  9. 2004-04-01 6:28 am
  10. 2004-04-01 6:36 am
  11. 2004-04-01 6:43 am
  12. 2004-04-01 6:54 am
  13. 2004-04-01 7:02 am
  14. 2004-04-01 7:23 am
  15. 2004-04-01 8:43 am
  16. 2004-04-01 9:02 am
  17. 2004-04-01 9:08 am
  18. 2004-04-01 9:36 am
  19. 2004-04-01 9:52 am
  20. 2004-04-01 10:12 am
  21. 2004-04-01 10:20 am
  22. 2004-04-01 10:30 am
  23. 2004-04-01 10:37 am
  24. 2004-04-01 10:44 am
  25. 2004-04-01 10:57 am
  26. 2004-04-01 11:09 am
  27. 2004-04-01 11:53 am
  28. 2004-04-01 11:57 am
  29. 2004-04-01 12:18 pm
  30. 2004-04-01 12:21 pm
  31. 2004-04-01 1:10 pm
  32. 2004-04-01 1:29 pm
  33. 2004-04-01 4:36 pm
  34. 2004-04-01 5:43 pm
  35. 2004-04-01 7:26 pm
  36. 2004-04-02 1:40 am
  37. 2004-04-02 5:36 am
  38. 2004-04-02 7:50 am
  39. 2004-04-02 10:15 am
  40. 2004-04-02 12:37 pm