Following the success of
the KDE 3.2 release, the KDE project is pleased to announce a new ambitious project dubbed 'Kimono'. The aim
of the project is to write a complete wrapper for KDE/Qt using the Mono framework and is based on early work by KDE bindings hacker extraordinaire Richard Dale. In addition to using Mono for the back-end work, Kimono will entail migrating to KaXul, a fully XML-based representation of the UI. Kimono will be the main focus of the forthcoming KDE 3.3 release.

"We pretty much got things right with 3.2, so it's time to shake things
up a bit," said KDE project leader Matthias Ettrich. "Exploring new frameworks will
help shake the KDE developers out of a rut, and lead to lots of new
ideas."

It's not clear at the moment what the time frame for the Kimono project will be, so don't expect much in the short term. It is likely to slow things down at first, but in the longer term the benefits of using a real object oriented language like C# with the inherent advantages of a managed common runtime will be indisputable.

On the Internet, April fools starts at 00:00 April 1 GMT. KaXUL and the QT C# bindings are both real and have been around for some time now, but the idea that they will be the main focus of any upcoming KDE release is nothing but a joke, of course.

No, the problem of integrating the KaXul layer with the Mono bindings has been establishing a World Wide network of 'Ontological GUI Metaphysicians'. We've had to do in secret, and what with the recent worldwide concern with people with odd views, I've been reluctant to be too public.

This will only make KDE bigger, sslower and bloated!! Even GNOME won't switch to Mono. You have _got_ to kidding me. I am so disappointed. I guess its true what they say about KDE copying Windows. Why did I switch at all. :(

People like you get right on my tits! You're a moron! You clearly know nothing about the internal workings of managed code and the .NET CLR at all.

I'd love to see the whole of KDE written in managed code. The source code would be easy to read, easy to write, and it would be JUST AS QUICK you ignorant prat. And because of all these things it would evolve at a much faster rate and everyone would benefit (including you, you miserable C-loving prick). In fact, the only force holding these things back are the facist Linux gimps (like yourself) who are scared of evolution and want everything to run on their 33MHz 486 because they're too tight arsed to splash out a few hundred quid on a modern machine. If you actually bothered to have a look at .NET, how much it speeds up development, and how much smaller (yes, smaller; MSIL does a lot more per-instruction than x86) it makes your applications then perhaps you'd realise, as I'm sure some of you Linux nerds are starting to do, that Microsoft isn't the source of all evil and that you can actually benefit from embracing some of the technologies that they are partly responsible for creating.

Just to summarise, in case that wasn't clear enough... one day you'll grow out of your "real programmers use assembly language" mindset and make something *useful* in a proper language (C#, Java, VB.NET, etc.).

Richard.

P.S. I bet you're one of those people who spells Microsoft with a dollar sign too.

Had me going at first, but then:
"shake the KDE developers out of a rut"
"using a real object oriented language like C#"
"inherent advantages of a managed common runtime will be indisputable"
made me check the date.

April Fools!

P.S. I love the automatic spellcheck on webforms. You KDE developers rock!

I am Adam Treat the creator and principle developer of the Qt# bindings. There was no sabotage. Marcus is overly sensitive at times.

Richard Dale is one of the original KDE binding authors and responsible for the Qt Java bindings as well as Objective-C, QtC, and KDEC. He is also working on the Ruby bindings, the new Smoke library and the new proxy/smoke based C# bindings. He is doing great work and I look forward to seeing this progression.

Richard and I have talked and he is planning on using the bulk of the current Qt# bindings where applicable.

Another one bites the hook on April 1st. You didn't happen to note that I'm the project leader for Kommander, did you? Kommander is based on Qt Designer and creates the XML .ui files as *.kmdr files that run with kmdr-executor. So Kommander is a no compile, optional scripting language, mini application building dialog tool. It does DCOP too. BTW I'm also the project leader for Quanta Plus which means you're not real likely to find me editing in vi. ;-)

No Quanta plug? 23.782% of posts, counting the 68.542% of the time it was on a story about Quanta.

This time however the interesting factor was because of how it relates to Kommander, and son of a gun, all these things are related to the fact that we use KDE tools and technologies, which was the jist of the humor. The Kommander plug came only when it was apparent somebody didn't get the joke. The Quanta plug was done by you when you read it in where it was not. I can only assume it's some kind of obsession you have with Quanta since there was nothing at all about Quanta in it. Thanks for the plug, I guess... It's nice to have something to plug that you don't have to call the plumber for.

Is a little wit too much to ask for on April fools? Try to grasp the joke before countering. Enough of this, I have more entertaining and important things to do. ;-)

Actually, I think Mono for KDE would be a good thing (assuming there is no problem with copyrights and such things). I would like to program for KDE, but I am currently put off by the complexity of C++. I have done various things in Java (which is a nice language), so going to Mono would probably be fairly easy.

Exactly. I think there are innumerable people like you (and I). Widespread and standardized mono libraries would lower the threshold to contribute (remember, mono is not only C# -- libraries for it can be used by any mono supported language, so you'd get a number of new language bindings for free).

In the Kimono C# KDE bindings the method names start with an upper case letter. If I want to use the C# binding as a producer, and a java consumer binding does the CLR have an automagical method renaming scheme?

Am I right in thinking that method name overloading resolution is language specific in the CLR? Here's a problem - C# has unsigned ints, while java has only unsigned. The KDE api features methods overloaded on only that minor type difference.

I think people grossly under estimate the difficulties of producing a common cross-language library without compromises. But that is what we've been attempting to do with Smoke. It doesn't happen by the sprinkling of magic marketing speak 'fairy dust'. Anyone remember CORBA - just wrap an object in language neutral IDL, and bingo! Language independent components..

Mono itself is not no. However it is based on a Microsoft technology with huge legal questions surrounding it. It is linked to part of Microsoft's .Net C# etc and so Microsoft controls the direction of it and a game of perpetual "catch-up" will ensue. There is just _NO_ way around that. If you think the .Net infastructure is the cats pajamas then you will use Microsoft's implementation as it will be the one that is new and shiny.

What I find incredibly hilarious is that a slew of GNOME folks say Mono is the greatest thing since sliced bread but how is it any different then the failed Harmony project that was deemed to be a waste of time due to perpetual "catch-up" with the latest and greatest Qt? I haven't seen it looked at from this angle and this most likely not the right place to ask it either. But I do find it amusing.

I swear, if this is an april fools, I will hold a grudge on Richard Moore forever, it's NOT funny! Something like Kimono would be fantastic for KDE, but the "quote" from Ettrich sounds manufactured ("time to shake things up a bit"? right).

Ok, I call off my grudge :) The bindings and tools are indeed real. I'm just a little frustrated with the whole April 1st surrealism; you never know what's real, and something is real but just exaggerated, and who knows what to believe anymore! Come, April 2nd! :)