Koto: Progress report

[Iain Dooley]

hello all,

Things have come a little bit 'full circle'. In the beginning of this 
project, I thought that using something like Korundum would be unsafe, 
because it provides a 'complete' binding from Ruby to KDE/Qt classes (so 
scripts could do things like get access to the file system).

I suppose the thing I am looking for here is some kind of 'KorundumLite'.

1. Ruby interpreter embedded in C++ App

Loads 'KorundumLite' which doesn't allow things like access to the 
QApplication object or anything else important or potentially unsafe, 
just basic widget types, strings, collections etc, and disallows the 
scripter to load any further libraries (whilst still providing the means 
of including other user classes).

2. UI dynamically loaded via QWidget::create() method

This will return a pointer to the top level widget in that .ui file. 
This widget can be added to a tab in the program browser.

I was completely at a loss of how to do this, but something just struck 
me: you can pass a second argument to QWidgetFactory::create(), which is 
a QObject that implements custom slots. If I can allow the application 
scripter to implement their own Receiver class that implements the 
custom slots (not DCOP, just regular slots), then somehow gain access to 
that class in C++, i could simply do:

//RubyInterpreter is a wrapper class for the embedded ruby
QObject* receiver = RubyIntepreter::getSlotReceiver();
QWidget* top_level = QWidgetFactory::create('/path/to/ui/file',receiver);

the application scripter could then simply create their layout in Qt 
Designer, and then connect all their widget slots to custom slots, 
implement those slots in their Ruby customer receiver and viola, the UI 
is then bound to Ruby control scripts. I'm certain that it's possible to 
gain access to class written in Ruby from C++ if the interpreter is 
embedded in your application (I read it in the Ruby book).

Eventually, there would be an application that would handle this by 
showing the interface, and allowing the user to right click on a widget 
in order to add a custom slot for each of it's signals or something like 
that, then the Ruby receiver class would be output from that.

3. Widgets in the UI are available to the Ruby script

A slot will be able to get access to the UI by calling the getChild 
method of the QWidget class (as recommended in the section on dynamic 
dialogs in the Qt Designer manual). Or even better, a simple interface 
class could be provided from the application that would have something like:

QWidget* getWidget("name")

which could be called from Ruby (it is quite easy to expose C++ classes 
to Ruby scripts as objects as it is well documented).

SUMMARY

So in fact, this makes extensive use of existing Korundum with one key 
difference: the Korundum is cut down quite a bit to make it safe, and 
the Ruby interpreter is embedded in the C++ application that acts as the 
browser/runner for distributed applications.

The interface between the UI and the Ruby scripts is provided by the 
application scripter's custom Receiver class, which contains custom 
slots that will be dynamically bound when the UI is loaded by the 
QWidgetFactory's create() method.

Of course none of this is actually written yet. I've just sent an email 
to Richard Dale, who is the primary developer of Korundum to see what 
his response is. If he thinks it's feasible/a good idea, then I'll go 
ahead and start building it. I suppose the first thing I would do is 
write it with the full Korundum implementation, and then cut this down 
later on (just to get something working as soon as possible).

cheers

iain