Kimono Project Nets KDE [April Fools' Day]

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.

Dot Categories: 

Comments

by Vevaxel (not verified)

That looks very interesting! Is it something similar to Fluxbox's window grouping?

(Of course, I hope it is not an April fools thing...)

by anon (not verified)

you know you want to implement that in kwin =)_

by Anon (not verified)

I realise this is a joke, but I would love to have that. Pleasepleaseplease, Lubos?

by David (not verified)

"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."

Let's not fall into any hype please. That is the worst thing that can be done. I think Mono can certainly be useful if used in the right way (i.e. having a community implementation and ignore what Microsoft are doing), but I just don't like what some people are coming out with about it. There seems to be some paranoia that we need to somehow copy from what Microsoft is doing. I just don't understand the rational behind a clone of Avalon and anything else Microsoft may, or may not, be doing. Most of it is kept up by hype, and it's not as if we are going to have native compatibility with any of it so we need to accept that now.

I think it is a safe bet that this has a lot to do with work at Novell/Suse about integrating many technologies (as the work on Qt# seems to have got back up and running out of nowhere), but of course, no one will say anything :).

I say yes if it is good compelling technology and the community can have its own implementation, and it is used for those reasons, rather than "we need this because MS will put this in...". This will mean putting native compatibility with MS .NET very low down on the list of priorities, because it just isn't an achievable goal. This must be a community technology, and it must be better and more compelling than anything Microsoft has. The use of XUL and KaXuL above is a good example, and a step in the right direction. I read the presentation on KaXuL and it looks very useful, so I'm chuffed to see it being used.

Put simply, if this can be used and marketed in a way that says that this is a better, more useful way of using .NET principles together with exclusively open source technology and toolkits, I think a lot of good can come from it. If it is perceived by developers as simply a way of maintaining compatibility with native MS.NET, it will fail spectacularly because it puts Microsoft in the driving seat technologically and in mind share. It will also do an immeasurable amount of damage to the image of open source development that may not be recoverable.

Go forward, but be safe and, above all, be sensible with it. If done right, and if it can create and gain mindshare in people, then this should really, really cheese some people off in the north-west of the United States.

by David (not verified)

"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."

Then again I really just can't stomach this statement. "Slow things down a bit" has April fool written all over it. You bastards! You take real, believable technology that could absolutely definitely be used to do all this and turn it into something that is quite believable. If this is a joke, it is very, very good and if it isn't your timing stinks. Go on, I give up.

by David (not verified)

No, this is definitely pants - but it looks good!

by Richard Dale (not verified)

I just went for the way C# has reproduced java bug for bug:
- Static methods, no class methods with dynamic dispatch
- Classes are not first class citizens
- No way of adding to an existing class, aka mixins Objective-C delegates
- Meaningless, over-complicated class hierarchies (ContextBoundObject huh?).

I've desperate to think of a way to incorporate java style event listeners into KDE for years, but the technical problem of integrating such utterly naff technology with KDE has been impossible to date.

-- Richard

by Navindra Umanee (not verified)

What do you mean by "Classes are not first class citizens"? Did you mean to say functions?

In Smalltalk or Objective-C or ruby you can send a message (ie invoke a function call if you think that way) to an instance of a class in exactly the same manner. In those languages the target of the message could either be an instance or a class, it doesn't make any difference.
But in C# or java, invoking a static method is a different sort of thing. This is a design flaw, it screws up remoting with static methods.

If class B inherits from class A, then class A's class methods will be overriden by class B's class methods. In contrast in java or C# there is no dynamic despatch on static methods. So you need this for a factory pattern. I think the C# framework has a factory interface, but they are solving the problem in the wrong way.

-- Richard

by Navindra Umanee (not verified)

Ah I think I see what you mean. Thanks for explaining!

April 2nd

Actually when I read through my explanation it isn't very clear. I'm afraid I drunk too much wine while laughing at all this last night

But it is certainly true that java/C# static methods are poor compared with classes as instances being sent class methods as messages. Classes should be objects, and just like any other sort of instance.

I'm sure there must be a good write up about this somewhere out on the web, that would do a better job of explaining than I could.

-- Richard

"I just went for the way C# has reproduced java bug for bug"

Of course it has! You need to remember that C# essentially started the day after Sun won its Java case with Microsoft. They weren't allowed to embrace and extend Sun's Java specs, so they created their own.

Deep within Microsoft's psyche is the fundamental fear of third party products. They need to control everything they use. If they can't buy it they clone and extend it. They're like an anti-Debian. They've got an implicit social contract that everything running on a Windows system will be controlled by Microsoft. C# is nothing more than their version of Java that they get to control.

Happy April 1st!

by Guillaume Laurent (not verified)

> - No way of adding to an existing class

Apparently this is planned for the next version of C# (no joke, heard this from a colleague at work yesterday). Along with generics and anonymous functions.

TIMELINE: April 2nd

"Apparently this is planned for the next version of C# (no joke, heard this from a colleague at work yesterday). Along with generics and anonymous functions."

I think you can split the source of a class over more than one file, which is a different feature to Objective-C categories or ruby mixins. They are dynamic runtime based features.

I think the combination of anonymous delegates as closures with iterators looks very nice.

What I've read about Java 1.5 hasn't sounded very impressive (an apparently underwhelming generics implementation is supposed to be the star. I think that the C# 2.0 anonymous delegates are more interesting.

-- Richard

by Guillaume Laurent (not verified)

> I think you can split the source of a class over more than one file

Yes, it's not dynamic as in ObjC or Ruby, but it should still be a useful feature (more than just a commodity to avoid large files, that is).

> I think the combination of anonymous delegates as closures with iterators looks very nice.

Yes. Very Ruby-ish, very very useful.

> What I've read about Java 1.5 hasn't sounded very impressive [...]

I totally agree. Java 1.5 is basically a poor catch-up of C#, which has been IMHO a very impressive language from the start. Java tried to draw lessons from C++ but pushed it too far, and C# really restores the balance, while also drawing lessons from Java itself. I really hope C# will be available in full on Linux one way or another.

Ideally, Novell would drop GTK, standardize on Qt/KDE, then put resources on Mono so it becomes useable for real work, and later on port (not bind) Qt to C# (or may be a binding would be acceptable after all, but offhand I'm not so sure it would).

"Yes, it's not dynamic as in ObjC or Ruby, but it should still be a useful feature (more than just a commodity to avoid large files, that is)."

Yes, the feature that I think would be really useful is Aspect Oriented programming to customise the behaviour of an existing class. The non-fiction version of Kimono is based on a multi-language AOP environment with C#/Mono or Java/gcj as the primary languages. You might be able to write advice in ruby, perl as well as the primary language, as ruby, perl, java and C# will share the same common runtime in the Smoke library.

"Yes. Very Ruby-ish, very very useful"

Ah, ruby now there's a *really* interesting language..

-- Richard

by Guillaume Laurent (not verified)

> The non-fiction version of Kimono is based on a multi-language AOP environment with C#/Mono or Java/gcj as the primary languages.

I'm eager to see how this one comes out.

> Ah, ruby now there's a *really* interesting language..

Isn't it ? :-) I think it's by far the "sexiest" langage I've ever dabbled with (not that I've learned dozens, of course, but still). One of the very few which really make me *want* to code something with. I would say it completely obsoletes Python but in the long run it would seem that Python's more rigid syntax gives it an edge when it comes to long-term maintenance (especially when you're working on somebody else's code). It certainly obsoletes Perl, though.

I would desribe ruby as a 'painterly masterpiece', the code and design is made up of very simple pieces, but the parts all seem to fit together in a coherent whole. That's like a master painter uses apparently simple brushstrokes. Just look at an individual brush stroke, and you can't see anything special - look at the whole painting and you can.

The non-fiction, already existing QtRuby and Korundum ruby bindings are a great way to write Qt or KDE apps. There've been various fixes along with DCOP support for the KDE 3.2.2 release.

I haven't had much time to write anything big, but Alex Kellett has, and I really think they look very tidy and maintainable. The Smoke runtime has over 950 classes, and 29000+ methods, so the combination of the full api with ruby is potentially a killer RAD environment.

-- Richard

"...so the combination of the full api with ruby is potentially a killer RAD environment."

Well, let's rephrase that. It WILL be a killer RAD environment. Please, no Visual Basic implementations....

by Guillaume Laurent (not verified)

> I would desribe ruby as a 'painterly masterpiece'

Very nice metaphor. :-)

> so the combination of the full api with ruby is potentially a killer RAD environment

Well, if my stint with gtkmm has taught me anything, it's that :
- bindings *must* be distributed as a standard part of a platform, otherwise nobody will use them
- bindings are great for quick'n drity prototypes or proof-of-concepts, but they break down very quickly when you delve into details where lies the proverbial Devil.

There could be exceptions to that last rule, but I'm pessimistic by nature on these issues. :-)

The Smoke library is autogenerated as part of the kdebindings configure. It can then be used by perl, ruby, java and c#. The java and C# dynamic proxy interfaces will also be autogenerated as part of kdebindings configure.

To have a look at the current state of C# code generation, check out kdebindings from the HEAD branch. Edit smoke/kde/generate.pl.in and change the string '-fsmoke' to '-fkimono'. Then configure kdebindings with the '--enable-smoke=kde' option. The .cs sources will be generated in smoke/kde.

You'll see why we don't have to have 10-15 people hacking away on SourceForge for a year before they excitedly announce version 0.15 of xx language binding. I call that the 'knitting circle' approach to language bindings, slow and sociable but not particularly effective if you have production code depending on all those regular manual updates.

-- Richard

by Guillaume Laurent (not verified)

I haven't looked at kdebindings yet. Are there sample perl/ruby progs in it ?

Sample ruby programs are under kdebindings/qtruby and kdebindings/korundum.

PerlQt/PerlKDE bindings that also use the Smoke library aren't in the KDE cvs, although it would obviously be brilliant to have them there.

-- Richard

"Ah, ruby now there's a *really* interesting language.."

Yer, Ruby is a really interesting language. It certainly has the name but it doesn't seem to have the hype to carry into 'mainstream' areas. Pretty sad really. Hopefully someone or something can do something about that :).

Wow. Because osnews has it it must definately _NOT_ be an Aprils Fools joke and MUST be valid.

Did you actually read the article on OS News?

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.

The _Dot_ reports. So they are feeding off _THIS_ article. Either you were being sarcastic and I didn't pick up on it for which I apologize, or you really need to dig deeper.

To the Dot, you had me going there for a minute too. :)

My connection blows. Didn't see you were joking.

It is I who am the retard! Sorry.

by Rayiner Hashem (not verified)

To be fair. OSNews took the bait too. The article text has changed since it was posted. Hats of to Richard Moore for the excellent prank :)

by Shane Simmons (not verified)

Why must every tech-related site do incredibly stupid April Fools' Day jokes?

by Thomas (not verified)

Maybe to fool the techies once in a while?

by Bert (not verified)

Well, probably not a April joke as it is possible.

by David (not verified)

Yer this was a real stickler, because you really had to look at it to see how ridiculous the bottom two paragraphs are. At first glance the whole lot is totally believable because the projects are actually real and feasible. It also had triple the impact because of all the recent shenanigans.

"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."

Very funny! So I take it .NET and Mono are taking over completely then?

Very good. It got me.

PS. Anybody fancy taking up this project now?

by rjamestaylor (not verified)

Becareful people. While structured like a silly AFJ Perl6 got its start as a silly AFJ about a common runtime for Perl and Python (captialization optional). Now look at it.

by Richard Moore (not verified)

For those of you who haven't figured it out, yes this is joke... but all the tools described are real, so those who support it could make it happen. :-)

Happy April 1st!

by Anonymous (not verified)

I think that all of the stories that are jokes should be labeled as such. Otherwise, many people get confused, and the website loses credibility.

by Joseph H Camel (not verified)

They seem to have been planning this for a while, theres even funding and all. See the press release about financial support for the project here...
http://www.gatesfoundation.org/kimono

by There is no Apr... (not verified)

"... Kimono will entail migrating to KaXul, a fully XML-based representation of the UI ... in the longer terms the benefits of using a real object oriented language like C# ... will be indisputable."

I think the language we should be using for writing apps is JavaScript, not C#. Unlike C#, JavaScript implements a completely object based system featuring prototypes. Also, because JavaScript is an interpreted language, the need to compile KDE will disappear.

KDE is currently written in a slow and obsolete language (C++), and compiling it can take days. This has prevented many users from trying KDE, and upset because they cannot upgrade to the latest version.

Look at this:
http://developer.kde.org/language-bindings/js/index.html
http://dot.kde.org/986101966/

by qwerty (not verified)

Hopefully you are not against mono just besauce its a "Ximian" project.

by Frank Kafka (not verified)

Does really is it a "Ximian" project? ARRRRGHHHH...