Koto: Progress report
idoo4002 at mail.usyd.edu.au
Sun Aug 7 08:22:57 CEST 2005
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:
which could be called from Ruby (it is quite easy to expose C++ classes
to Ruby scripts as objects as it is well documented).
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).
More information about the Kde-soc