Trolltech has announced a new beta of Qt Script for Applications. In the words of the blurb: "The QSA toolkit is made up of the following components: QSA library, which the developer of the C++ application uses to make their Qt-based applications scriptable.
Qt Script, an easy-to-learn, multiplatform interpreted scripting language. Qt Script is based on the ECMAScript standard (as is JavaScript) . Qt Scripter, a multiplatform IDE which developers can make available to their end-users. Qt Scripter (screenshot) can be used to write and edit code, to visually design forms, and to run and debug scripts." With this release, QSA is now available under the GPL. Very cool stuff and should bring a whole new level of application extensibility to KDE/Qt applications that need it. Update: 12/20 18:09 by N: Looks like we forgot about KDE's own KJSEmbed (README, doc).

Comments

As others pointed out it is not yet another language. It just has a new name because it offers an extended (Qt) API on top of the ECMAScript language. The standard is actually designed with this goal: a fixed language core embedded into a host environment. What objects make up this extension environment is up to the implementor. Can either be a DOM API in a browser or any objects in an application.

Is it wrong to see QTSA as a system-independent alternative to VB? If yes IMHO it will boost the acceptance of
Qt & KDE since VB seems to be the language for those who aren't programmers but want to write simple programs / extend existing programs from time to time.

Well though i write asm, c++ and c i still think sometimes there is better to use VB than start writing comple MFC or QT that takes pointless time. So do say that VB programmers are not programmers is lame :P

Sorry, I meant people which don't have much experiences & knowledge in information science but want to adapt / extend existing applications. Yes, you are all-right - to say it with Stroustrup: Choose the correct language for your problem.

With PyQt, you have to write a .sip file for each C++ class you want to
make available, and compile that. This is not only time-consuming and a
maintainance burden, it also produces considerable bloat. The idea of Qt
Script is to use the introspection features and the marshalling code
which is produced by moc anyway. No extra code to write.

If you read the QSA docs you see that you are encouraged to write a new QObject sub-class that only exposes the functionality of your application that you want the user to see. This is more complicated and time consuming than writing a .sip file for your class instead and will generate a similar amount of bloat.

It's missing the point anyway. PyQt is an alternative to C++ for application development - it's not an alternative to QSA. As has been pointed out elsewhere it would be fairly trivial to produce a library that uses Qt's introspection features to create Python objects and feed them to the interpreter. Such a library would complement PyQt - and you get the benefit of using a single language for both application development and user scripting.

> If you read the QSA docs you see that you are encouraged to write
> a new QObject sub-class that only exposes the functionality of your
> application that you want the user to see.

Who says that you have to follow that recommendation? In my experience,
scripting interfaces are most useful if they expose _all_ interfaces
of the application. That makes Emacs so flexible. In general, scripting
interfaces written by someone who thinks he knows which interfaces are
useful tend to suck.

>This is more complicated

??? QObjects are something a Qt programmer writes every day, so it
is absolutely trivial.

> > If you read the QSA docs you see that you are encouraged to write
> > a new QObject sub-class that only exposes the functionality of your
> > application that you want the user to see.

> Who says that you have to follow that recommendation? In my experience,
> scripting interfaces are most useful if they expose _all_ interfaces
> of the application. That makes Emacs so flexible. In general, scripting
> interfaces written by someone who thinks he knows which interfaces are
> useful tend to suck.

If you want to expose all the interfaces then you have to hope that everything is a signal or slot and that you haven't implemented something useful as an ordinary public or protected method - otherwise you still need your wrapper class.

You also need to think carefully about who your scripters are. If you have a vertical market application and use QSA to allow your system implementors to configure the application for a particular customer then it makes sense to expose the full interface. If your scriptors are non-programmer end users then you probably need to think about restricting what's available to them - otherwise you just create huge problems for your support department.

> >This is more complicated

> ??? QObjects are something a Qt programmer writes every day, so it
is absolutely trivial.

I didn't say it was complicated to write a new wrapper class, I said it was more complicated than writing a .sip file for an existing class.

> If you want to expose all the interfaces then you have
> to hope that everything is a signal or slot and that
> you haven't implemented something useful as an ordinary
> public or protected method - otherwise you still need
> your wrapper class.

No, you just have to declare the method a slot, that´s
all. And in the other direction, if you want to hide
something, you just declare it private. No wrapper
class is needed for that.

> I didn't say it was complicated to write a new wrapper
> class, I said it was more complicated than writing
> a .sip file for an existing class.

And I say it´s not more complicated, it´s trivial.
In particular, you have the additional benefit that
the interface is reusable by the DCOP bridge for
out-of-process automation, by any other bridge (like
the one I use in Dox), and that qmake or am_edit
take care of the build issues.

Since QT is trying to become a cross platform API, I think this move is a first step in filling in the missing peices - the greatest of which is the lack of a full featured HTML renderer. They can't just tell a customer to load KHTML since this implies a lot of other dependencies and may break the cross platform feature. QT has got to recreate alot of the KDE work as new QT features so as not to be dependent on KDE.