QtRuby and Korundum Bring eXtreme RAD to KDE

For those of you not in the know, Ruby is a relatively new general purpose scripting language that is surprisingly expressive, allowing developers to prototype and develop powerful applications in a short time. Now with QtRuby and Korundrum, that power and expressivity has increased: You can sketch out pretty interfaces with Qt Designer and automatically create Ruby code with the rbuic tool. Or do amazing things with DCOP without needing preprocessors, makefiles etc -- just type in your Ruby script and be in control of your desktop. In fact, you can find a fairly complete description of all the features supported by QtRuby and Korundrum over at the Ruby bindings section of the KDE Developer's Corner.

I've also translated a couple of tutorials into Ruby. There is a Ruby version of
Qt Tutorial #1, and the corresponding Ruby code is in
qtruby/rubylib/tutorial/. That's the one where you build a game to fire a cannon at a target; it explains the basics of Qt widgets such as using layout managers, and how signals and slots work.

For KDE, there is a Ruby translation of a KDE 3.0 tutorial
originally written for C++ by Antonio Larrosa Jiménez.
The sources are in korundum/rubylib/tutorials/. In nine steps it takes you from simple Hello Worlds in Qt and KDE, right up to building a customized browser using the KDE::HTMLPart component which communicates with a bookmarks app over DCOP.

The QtRuby and Korundum bindings have been backported to Qt 3.1.x and KDE 3.1.x, and so now it should be possible to build them on any KDE installation from the last year or two, right up to the current KDE 3.3. You can obtain recent CVS snapshots on the Rubyforge
QtRuby/Korundum site.

Dot Categories: 

Comments

by Richard Dale (not verified)

Oops, syntax error, it should be:

hello = PushButton.new(a.i18n("Hello World !"))

And PushButton is ambiguous, does it mean a QPushButton or a KPushButton in this case? So maybe use the include directive with care..

by Jaxn (not verified)

I would really love to see PHP bindings. Especially now that PHP5 is stable.

I know the first response will be that I should write one. I would love too, I just can't find any docs for Smoke (I think that is the preferred kde bindings method).

-Jackson

by Corbin (not verified)

I would like to see that too. Though I haven't even heard of smoke, so obviously your ahead of me!

I need to try out PHP5 some time...

by Richard Dale (not verified)

I keep meaning to try and write up some Smoke documentation. When I started on the ruby bindings last year I used a paper by Germain Garand which he posted on the kdebindings mailing list. I haven't been able to find it since, and keep meaning to ask Germain to possibly check it into the kdebindings cvs.

How much man effort is involved in implementing a new language binding? I would say say about 6 man months at the minimum. I've been working on the ruby bindings for over a year - I started in July 2003, and it's taken me until about now to announce the first release. I've done some other work on java and C# bindings, but really most of the last year has been spent working fulltime on getting Smoke working with the KDE classes, and implementing the ruby bindings. You can't really do a language binding in your spare time. Compare and contrast the ruby-gnome project - they have 16 or 17 developers. But their approach depends on splitting up the work, and hand crafting the bindings for each class - I call that the 'knitting circle' approach. Each developer doesn't need to be that skilled, and they can do it in their spare time.

For KDE 3.4 the Smoke library needs to be more modular, and broken up so that it is easy to implement plugin apis for the various KDE projects - kontact, kmail, kate and kdevelop for instance. The Amazing Lypanov suggested a way to do this at aKademy, and I've had some discussion since with Joseph Wenninger of the kate project, so I'm happy it can be done and put on the 3.4 release plan.

I used to think that KDE should have as many language bindings as possible, but I'm no longer sure if that's a good idea. I now think we have to focus on perl, python, ruby, java and C# and basically ignore everything else. If someone wants to give up six months and work on php bindings, then fine, but otherwise it won't happen. It takes much more effort to learn the Qt/KDE api than it does to learn the syntax of a language like php. So if you're a php programmer with server side experience, it's easier to learn ruby while you're learning the Qt/KDE api.

by Ian Monroe (not verified)

I kinda like using PHP for shell scripting, cause its syntax is so easy. I wouldn't mind some PHP KDE/Qt bindings mostly for such small jobs. Granted, I'd rather have the Ruby KDE/Qt bindings, I haven't played around with them for several months its good to see there's been plenty of progress.

by markc (not verified)

"focus on perl, python, ruby, java and C# and basically ignore everything else" but that leaves out the one scripting language that is arguably more popular than any of the ones just listed. For all the individual worth of the various languages mentioned, I'd put money on PHP being the more approachable, therefor generally usable, language for desktop fiddling by the masses. Perhaps I am biased and when I say "the masses" I really mean me but I really do suspect that if a PHP + Qt/KDE gui building app was available it would see more and faster desktop trinket innovation than from any other language.

With Qt4 beta SDKs available and the release of PHP5, now would be a good time to put some effort into some PhpQT / PhpKDE project. Anyone seriously interested ?

by Roberto Alsina (not verified)

I am sure you gonna find someone. However, after spending a few months trying to fix OTPC[1] I can tell you: a 15KLOC app in PHP is going to be an amazing feat. Not pretty, but amazing.

[1] Other people's perl/php code

by Jaxn (not verified)

Like I said before, I am ready and willing to do PHP bindings.

I will make you a deal Richard...

You get that smoke documentation done and I will do PHP bindings (with the help of friends like Marcus Whitney).

-Jackson

by Richard Dale (not verified)

Yes I certainly don't want to discourage anyone, only point out it's quite a lot of work. I've just emailed Germain Garand about some Smoke notes he had, and he's sent them to me, so I'll try and get it written up and put in the kdebindings cvs and on the KDE Developer's Corner site. I've been meaning try and get Smoke written up better for a while.

You can subscribe to the [email protected] mailing list and ask bindings questions there. To use Smoke with PHP, it will need to have some sort of 'catch-all' function which is called if a particular method can't be found. In ruby that's 'method_missing' and in perl it's 'autoload'. So you catch method calls there, and then forward them onto Smoke.

class MyClass

def method_missing(methId)
puts "can't find method: #{methId.id2name}"
end

end

obj = MyClass.new
obj.foobar -> can't find method: foobar
obj.baz -> can't find method: baz

I don't know if that makes sense - you can call any old method on obj, and it will be trapped by method_missing, and print an error message in this case. The first step is to try and do something similar in PHP..

by Marcus Whitney (not verified)

http://us2.php.net/manual/en/language.oop5.overloading.php

Note the __call magic method that does exactly what you are describing. We're ready :)

by markc (not verified)

So it's early 2005 and I am wondering if there has been any progress realizing a php-qt application anywhere on the planet ?

Better still php-kde. I just did a google search and this is one of the few pages that came up :-) I guess I can always try again in 2006.

by Jackson (not verified)

I did some work on it and got some of the Smoke stuff working, but then had to put it aside for other stuff (i.e. stuff that feeds my family).

It would be cool though.

by markc (not verified)

Well Well, half way thru 2007 and still no sign of a PhpKDE. There is a php-qt project that has been picked up, although there is still no viable release that I am aware of, and it is still not a PhpKDE.

Anyone heard of anything out there somewhere, particularly based on KDE4 ?

by Jonas B. (not verified)

I'm trying out the Gentoo distribution. Which package should I emerge to get QtRuby?

by Richard Dale (not verified)

Alex the qtruby co-author would know:

http://lypanov.blogspot.com/2004_06_06_lypanov_archive.html#108661246168...

Is it kdebindings?

by Ian Monroe (not verified)

Yes, its kdebindings make sure you get the 3.3.0 version which is marked ~x86. At least the last time I installed kdebindings it didn't install ruby stuff, but it did when I emerged 3.3.0 over night.

by M (not verified)

Besides various bindings it would be nice to have some advanced C++ features in Qt as well. I am especially missing:

1) exceptions
2) multiple inheritance from two QObjects
3) better use of namespaces

A library without exceptions in 2004 is a bit poor really.

by Morty (not verified)

You sure? When I built Qt last night I used: configure -no-g++-exceptions. I wonder if you change this to yes, do you get your exceptions?

by M (not verified)

No that has nothing to do with Qt its a only a compiler option. You would need some additional (though trivial) code in Qt. Exceptions are a much better way to do error handling, since you don't have to check for errors based on the return value of each function you call, but can simply monitor a block of code. Another advantage is that exceptions can be thrown during object creation in the constructor and that the return value of a function can be used for something else then an error/status value.

by Christian Loose (not verified)

> You would need some additional (though trivial) code in Qt

trivial? The code itself might be trivial, but it's by far not trivial to make a class exception safe. Take a look at the amount of articles about exception-safety on http://www.gotw.ca.

Christian

by M (not verified)

Ok, agree you have to be a programmer to be able to do it.

by Ian Monroe (not verified)

I'm going to guess its because Qt is portable and perhaps (until recently?) exception handling hasn't been portable enough. But I don't know really.