Skip to content

Korundum Ruby To Do List

Monday, 25 April 2005  |  richard dale

Aaron was interested in what I thought needed doing with KDE/ruby and I mailed him this to do list the other day. Here it is in case anyone else is interested.

A lot of the items are tidy sub-projects that perhaps people might be interested in taking up (btw anything involving ruby is usually fun)..

  • Logo I called it Korundum, rather than something more mundane like RubyKDE or whatever, because I wanted people to think of it as a complete RAD environment, rather than just bindings. People think of ruby as a 'scripting language', when it is much more than that. So I wanted a non-whimsical sounding name, and Korundum is supposed to sound something like 'Kryptonite'. The idea is that it can turn an ordinary programmer into superman - a possible idea for a logo would be a sort of 'Incredibles' type of character.

  • More modular At the moment all the kdelibs headers are parsed and a single library is generated, which is huge. At aKademy last year, I discussed with Alex how to break it up into smaller libraries so we can wrap all the various KDE plugin apis with Smoke library bindings. And as everything is autogenerated, it doesn't require much maintenance effort. Pretty much all other bindings projects require manual effort to keep up to date with the latest releases. I didn't manage to do the 'modularising' for the KDE 3.4 release in the end, but it's probably the most important technical limitation of the bindings at the moment.

  • KDevelop Interactive Ruby (irb) integration, with a graphic front end. Autogeneration of ruby rdoc docs from the kdelibs headers, and a documentation viewer. Better class browser parsing based on the ruby bison grammer. Ruby autocompletion if possible (very tricky).

  • Soap/DCOP bridge I was discussing this with Till Adam at FOSDEM. He was using this really clunky gsoap code generator, but I think you could do it all dynamically with ruby. The idea would be to interogate a SOAP server, and dynamically generate DCOP slots matching the services. That way every tool that could access DCOP could also access SOAP automagically. Doing something with REST is also important. I think every KDE app of the future should be expected to always be connected to the internet, and looking for services like autoscrobbler or whatever.

  • Tutorials/Documention I've translated a few, but need to do a ruby version of Zack's KConfigXT tutorial for instance. KDE needs more books in general, it is hard to learn the api at the moment.

  • i18n There needs to be a ruby option added to the xgettext utility. All the i18n calls are in the ruby api, but there is no means of extracting the strings at the moment.

  • Usability Apart from lack of docs/books I see there are two big problems with the KDE development environment; firstly an over complicated build process based on automake, and secondly the fact you can't test a KPart or an xml menu until the app has been installed. There was discussion on the kde-core list a couple of months ago, but I'm not sure exactly what came out of it. The ruby KDE projects in KDevelop suffer from both these problems, just like the C++ ones.

  • Rails Add a project template/debugging/rhtml syntax highlighting for Rails in Quanta or KDevelop