25
Apr
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
- richard dale's blog
- Login or register to post comments
- 685 reads
Syndicate Blogs
Comments
Name
You know, the strongest association 'Korundum' makes for me is not Kryptonite or anything like that, but rather "Conundrum," which I suspect isn't really what you're going for ;-) However, if you've heard of 'corundum' it's a very appropriate name, so I approve.
Using Korundum is really easy
While working on the KIMIface implementation for Licq, I needed a test program.
I thought that while I could easily write a C++ application, I could use this as a chance to have look at Ruby.
It took a while until I figured out how to add command line options, maybe you could add that to the short examples on the Ruby bindings page on developer.kde.org
This weekend, after reading some Ruby tutorials, I converted the code to be more Ruby style and that makes the source really nifty :)
Btw, the KDE3.3 version of Korundum seems to only generate DCOP slots when subclassing a class from module KDE, when I tried to use it in a class derived from Qt:: Object I got warnings when the slot syntax wasn't correct, but even the corrected slot never showed up in kdcop.
When changing to something like KDE:: PushButton it worked.
Anyway, very nice work!
Re: Using Korundum is really easy
It took a while until I figured out how to add command line options, maybe you could add that to the short examples on the Ruby bindings page on developer.kde.org
Yes, ok I'll do that.
Btw, the KDE3.3 version of Korundum seems to only generate DCOP slots when subclassing a class from module KDE, when I tried to use it in a class derived from Qt:: Object I got warnings when the slot syntax wasn’t correct, but even the corrected slot never showed up in kdcop.
When changing to something like KDE:: PushButton it worked.
Yes, that is a current limitation of the DCOP support. The class doesn't have to be a subclass of DCOPObject, but it must be a KDE class. I don't seem to have actually documented that anywhere, oops sorry about that.. If the class is a DCOPObject subclass, you can do more with it though. There is some explanation about that in the korundum/README file.
On the ruby page at developer.kde.org...
it says there'll be support for ruby-style type signatures for signals/slots in place of the current C++-style ones. Is this still planned? Would be quite nice, especially for those who would attempt to learn Ruby/KDE before C++... (which is what I originally did, and failed at)
Asides from that, QtRuby/Korundum is very nice. My favorite part thus far is probably that doing
attr_accessor :attribute
slots 'attribute=()'
actually works, which I wouldn't have expected to.
Re: On the ruby page at developer.kde.org...
it says there’ll be support for ruby-style type signatures for signals/slots in place of the current C++-style ones. Is this still planned? Would be quite nice, especially for those who would attempt to learn Ruby/KDE before C++… (which is what I originally did, and failed at)
Ah yes, I should add the to the list. I also forgot about porting to Qt 4 where the slots and signals work differently. So maybe do the ruby slot type stuff for that. Also it needs to work with DCOP, so we need to make it work with that too.
It's a shame you have to be exposed to C++, I'm really sorry about that ;). It would be a good idea to write a 'C++ for ruby programmers' doc so that it would be easier to understand the C++ types to follow the Qt and KDE C++ documentation. Germain Garand has done one for PerlQt, so that would be a good starting point.
Asides from that, QtRuby/Korundum is very nice. My favorite part thus far is probably that doing
attr_accessor :attribute
slots ‘attribute=()’
actually works, which I wouldn’t have expected to.
Excellent! Very neat indeed - I didn't know it did that. I ought to write it up that tip and add it to the developers corner site.
Another attribute as slot example
Here is another example which shows how setting a ruby attribute as a slot would actually be used. It connects a 'textChanged' signal on a LineEdit field directly to a ruby attribute 'mytext' declared with an attr_accessor.
It uses an 'include Qt' statement so the Qt classes don't have to be prefixed with 'Qt::'. Blocks of code are passed to the button and editor field, which is a way of customising the constructor without having to subclass.
require 'Qt'include Qt
class SlotAttributeTest < Widget
attr_accessor :mytext
slots 'mytext=(const QString&)',
'show_mytext()'
def show_mytext
puts "mytext: %s" % @mytext
end
end
a = Application.new(ARGV)
a.mainWidget = test = SlotAttributeTest.new
layout = VBoxLayout.new(test)
edit = LineEdit.new(test) { |e|
layout.addWidget(e)
e.connect(e, SIGNAL('textChanged(const QString&)'),
test, SLOT('mytext=(const QString&)'))
}
button = PushButton.new(test) { |b|
b.text = "Show mytext"
layout.addWidget(b)
b.connect(b, SIGNAL('clicked()'), test, SLOT('show_mytext()'))
}
test.show
a.exec
Re: On the ruby page at developer.kde.org..
I tried this test program:
require 'Qt'class FooBar < Qt::Widget
attr_accessor :foo
slots 'foo=(QString)'
signals 'baz(QString)'
def doit
puts 'foo: %s' % @foo
emit baz('hello')
end
end
a = Qt::Application.new(ARGV)
test = FooBar.new()
a.mainWidget = test
Qt:: Object.connect(test, SIGNAL('baz(QString)'), test, SLOT('foo=(QString)'))
test.doit
test.doit
test.show
a.exec
And the attr_accessor declaration of :foo does actually create a ruby method to use as a slot to connect to. When the signal baz was emitted with a value of 'hello' it set the @foo instance variable via the implicitely created ruby method.
But it didn't work when I defined a signal like:
As it assumed 'baz' was a local variable then, rather than a 'baz=' method call.
UPDATE: But this works fine though: