Say hello to QtScript!

Published Friday January 5th, 2007 | by

QtScript is a new module that will be introduced in the next minor release of Qt (4.3). It is a scripting environment that you embed in your C++ Qt application. While the release of Qt 4.3 is still a few months away, fortunately QtScript has just recently been integrated into the daily Qt snapshots, so you can start playing with it now. All you need to do is add

QT += script

to your .pro file, and

#include

in your source file(s), and you’re ready to rock.

QtScript conforms to the ECMA-262 ECMAScript scripting language standard, the core language that’s the basis of JavaScript and Flash ActionScript (to name two well-known languages). The key ECMAScript extension provided by QtScript is the QObject extension; QtScript leverages the introspection capabilities of the Qt Meta-Object System to provide dynamic bindings of the signals and slots and properties of Qt objects (QObject and subclasses thereof).

To give you an idea of what it looks like, here’s a small example showing how to register a widget in the scripting environment, and then manipulate it in script code:

#include
#include
#include 

int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton button;

QScriptEngine engine;
QScriptValue scriptButton = engine.scriptValueFromQObject(&button);
engine.globalObject().setProperty("button", scriptButton);

engine.evaluate("button.text = 'Hello World!'");
engine.evaluate("button.styleSheet = 'font-style: italic'");
engine.evaluate("button.show()");

return app.exec();
}

In script code, you can connect to signals of a Qt object. The target of the connection can either be a Qt slot, or a script function. Example of the latter:

function onButtonClicked(checked) {
print ("button was checked:", checked);
print ("button text:", this.text);
}

button.clicked.connect(onButtonClicked);

As you can see, the sender() of the signal is available as the this object in the script function. You can also use array-style member access:

button['toggled(bool)'].connect(app.quit);

You can disconnect from the signal again like so:

button.clicked.disconnect(onButtonClicked);

If you’re never going to explicitly disconnect from the signal again, the target function can be anonymous:

button.clicked.connect(
function (checked) {
print ("button was checked:", checked);
print ("button text:", this.text);
}
}

Child objects are accessible as members too, so long as the child has its objectName set. A natural application of this feature is when building user interfaces at runtime: Use QUiLoader to build the form, then manipulate the form from script code:

form.buttonBox.accepted.connect(/* some function */)
form.buttonBox.rejected.connect(/* some function */)
form.userNameEdit.text = "Ned Flanders";
form.exec();

There’s more interesting stuff you can do, such as registering your own functions for value conversion (marshalling), binding C++ functions (not just slots), and making slots “script-aware” (using a class called QScriptable). See the QtScript docs in the snapshots for more information.

And finally, some quick questions and answers:

Q: What about QSA?
A: For those of you familiar with QSA (Qt Script for Applications): The new QtScript module bears no relation to QSA. The API is new and the implementation is new. QSA will reach the end of its lifetime in 2008. We’re not touting QtScript as a “QSA replacement” per se, but QtScript clearly offers a lot of the same functionality as QSA, and will naturally offer even more in the future. Just don’t expect to be able to port your existing QSA projects to QtScript in under an hour; as already stated, QSA and QtScript are similar in concept, but very different in practice.

Q: What about performance?
A: QtScript offers far better performance than, say, QSA (by a couple of orders of magnitude). The performance is comparable to SpiderMonkey in most areas.

Q: What about bindings for the rest of Qt?
A: The emphasis is not on bindings for the 4.3 release, but rather on the core scripting environment; e.g. interpreter, ECMAScript compliance, QObject bindings. We offer an API you can use for writing your own bindings, in case the QObject bindings are not sufficient. Don’t expect to be able to write entire applications in only QtScript, at least not with the first release.

Well, have fun and let us know what you think. Remember, there’s still time for us to take your thoughts into account before the first official QtScript release.

Did you like this? Share it:

Posted in Qt, Qt Script

11 comments to Say hello to QtScript!

Tobias says:

Very very very nice, I was looking in to embedding Python into Qt just to have this capability but something built in is just so much nicer. Thanks trolltech for bringing all the goodies to the open version also.

Andreas Vox says:

Great!

Any chance of support for other script languages? Eg. Python?

Juri Pakaste says:

Oh man. One envious Gtk+ user here. That’s shiny.

Jos says:

Will there be a default interpreter? Something simple like
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QFile scriptfile(argv[1]);
QString script = file.readAll();
QScriptEngine engine;
engine.evalute(script);
return app.exec();
}

I can only hope the KDE developers manage to integrate Kross into this. That would rock :)

MIchaël Larouche says:

Which is the relation between QtString and KJSEmbed, which provide both Javascript scripting to application ? Although now on KDE side we have Kross which support multiple scripting backends, which rocks !

IceRAM says:

Hmm… this could even offer a more powerful approach for creating Firefox-like extensions for Qt-based web-browsers…

Florian Link says:

I have written a Python binding which
is very similar to QtScript, but for Python
(which avoids implementing the whole script language yourself):

http://pythonqt.sourceforge.net/

It’s LGPL, so try it out and feel free to use it!

Florian Link says:

I think that you are doing a great job,
it was a good decision to abandon QSA
and to reimplement an new script from scratch!

The only big drawback that I see is that you loose all the nice features from JavaScript 2.0,
namely classes and inheritance. On the other hand, JavaScript 2.0 seems to be quite dead,
when searching for it with Google.

But for our company it will be strange when we switch from QSA to QtScript, because we will have to port our QSA classes back to JavaScript 1.x, basically. Anyways, I guess that the decision to abandon JavaScript 2.0 is not reversible for Trolltech.

We are using QSA quite a lot and I had a glance at the new QtScript API and would like
to discuss some missing features, which we would require when switching from QSA:

– calling of script functions from C++ (or is this already possible with QScriptValue::call?)

– connection/disconnection of C++ signals to script functions from C++ (e.g. QScriptEngine::connectSignalToFunction(QObject* object, char* signal, const QScriptValue& scriptfunc))

– warning/error output redirection, it is important to be able to redirect the errors and warnings to a console

– a debugger API including step by step and breakpoints (only the API, a GUI debugger would be nice but for the first release a simple debug API would be ok)

– QScriptEngine::evaluate() only takes a string, there should be a version that takes an extra filename, so that when warnings/errors happen, the Application knows in which files this happend

– C++ Wrappers like in QSA should be added, this is implemented easily and would a powerful feature!

– Bytecode like Python would be nice, this would allow to ship applications with compiled scripts

– What are your longterm plans? Do you plan full Qt scriptability like e.g. PyQt does?

yannick says:

it’s a very great news !!!!! but will it be possible to evaluate a script in a QThread instead of the main loop ? It was not possible in QSA, but I hopes it will possible with QtScript ?

yannick

rumpelstiltsken says:

I’m not quite sure why one would want to adopt this, seeing that you might change your mind in the next release, as you seem to do regularly. You’re worse than the people who do Java. So far you’ve changed the underlying code so much that applications written with the older versions are broken no matter what. Why should my company invest time and money for our developers to learn this stuff painstakingly over months and years, just so that you can pull the rug out from underneath our feet by changing it all again on a whim? Perhaps your architects need to justify their huge salaries? I’m NOT impressed. You might fool a lot of people out there, but you ain’t fooling this cat over here. Anyway, unfortunately you’re not the only dudez in the software world who suffer from this disease.

Commenting closed.