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).

Not at all. It does overlap with kjs though, and to a certain extend also with wrappers for other scripting languages (because qsa came up with a very simple way to allow a scripting langage to access C++ objects).

> So this is kinda like ARexx-ports in old Amiga programs, right?
> If so, cool.

Well, it looks like...

However, it is all but cool ! Consider this: In 2002 we get an IPC/process-control scripting system, that is just like what was available in 1990 on AmigaOS. That is 12 years behind the time.

I can forgive the inventors of this QT/KDE approaches, assuming they never used an Amiga. But hey ! There were so many serious problems with ARexx for any who was doing a little more.

Todays choice should be a completly platform and application(-environment) scripting-server, better call it API-server, that neither requires you to learn YASL (yet another scripting language) nor is bound to a certain UI toolset.

'dcop' somewhat could have been something like this, assuming, that it is possible to convert SOAP and CORBA calls. Of course, that is rather complex.

What Linux (not GTK+/Gnome or QT/KDE) need is a standardized general and system- (even network-) global API server. Applications could add their own functionality (command set) to it just as did the good old 'ARexx host-port' in AmigaOS applications, while the possibility to address these API calls would be granted to any language.

Yes, you can access the slots of objects as if they were normal js methods, and access the properties as if they are normal js properties. You can also navigate the object tree to get at child widgets etc. Not all of this is in cvs yet as I am finishing off an API cleanup and documentation exercise, but now that HEAD is open again I'll commit it.

I've generate the docs and uploaded them to http://xmelegance.org/kjsembed/ Note that they are unfinished and there are now some better ways to things - I've been using the library in xmelegance so I've been improving the API as I go along.

The new XMLActionClient class is particularly nice - here's an example script that loads some actions using it:

It doesn't make sense for Trolltech to distribute their developments as LGPL or BSD-style : that way commercial applications don't need to license the Trolltech code == 'Trolltech can't make money' , which in turns translates to 'Trolltech does not develop new stuff' == 'Everyone suffers'.

Further, TrollTech could, in future, aim for compatibility with the KDE
KJSEmbed, so that a common foundation is found between the two projects.
The LGPL nature of KJSEmbed leaves this open as a possibility without
affecting TrollTech's GPL license on their scripting product.

Thus there is an incentive for Qt to improve both, and to pass some
of their (older) innovations back. Essentially, they can, on the
GNU/Linux/*NIX/whatever/else/should/go/here... end of things
aim to be a short-term commercial edge over the KDE solution.
This would bring money into the system, via developers who would
work for that money.

Just a thought, though a lot of my thoughts are rather silly at the moment.

I don't think you understand what this is for. This is for application extensibility for an application already written in C++. Besides, who is going to teach the users Python to do that? You think Python is a simple language for a newbie? JavaScript everybody already knows and is very simple to use and modify even if you don't understand much about it.

Could you do this? I am waiting forever for a good way to script Python for KDE, since IO want to build a fat client for the Python-based Zope application server. Please do that; I will test it for you! :-)

Creating an entirely new language would have been vastly better than sub-classing Javascript. Javascript is, simply put, the most terrible language to have ever plagued the computing world. Javascript is a case of a worthless technology being paired with a powerful, popular technology, and thereby gaining ubiquity. This echos Microsoft's success, who rode in on IBM's coattails.

Why is JavaScript bad? Because 10000 web designers didn't understand it and/or used it to create broken web pages?

JavaScript is a beautiful object-oriented scripting language that, unlike all other popular languages, uses a prototype-based object system which is much easier to learn and understand for a newbie, IMHO.
(prototype-based = you don't write classes. Instead you edit a object in real time, add methods and so on, and then clone it)

Ignoring, for the moment, that there isn't a single *good* implementation of the ECMAScript interpreter; ignoring, for the moment, that the design of JavaScript encourages bad code design; I'll focus on what I feel the real weaknesses of JavaScript are (and I freely admit that some/many of these are unmeasurable, and therefore, opinions):

* The language rules are ambiguous and anti-PoLS. Example:

a = x.y

What does this mean? Is it a method evaluation? Is it a method object assignation? Is it a method variable evaluation?

* Arbitrary rules for variable declarations... to "var" or not to "var"? A further source of confusion, yet another opportunity for bug introduction, yet another opportunity for bad code.

* The strongest arguments *for* JavaScript are for what you can do with it. That is, it is lighter-weight than Java, and you can do client-side processing. This isn't an argument for JavaScript; this is an argument for *some* scripting mechanism on the client-side.

* JavaScript looks like it was designed by a committee. Oh, wait... it *was* designed by a committee. While this looks like a cheap shot, it is actually my strongest criticism. Both DOM and JavaScript are unintuitive, and therefore require a high cost of entry as well as a high cost of maintenance.

* JavaScript is brittle. It is brittle because the specification is poorly written. Poorly written specifications are difficult to implement. Difficult implementations are error prone. Therefore, all of the problems that result from bad implementations of the interpreter can be traced back to the bad (ambiguous), formal, specification, and can thereby be attributed to the language itself.

* I can't forgive the lack of a formal class definition mechanism. Loose typing is useful, runtime class extension is a nifty feature, but ad-hoc classes is a terrible idea. It makes source maintenance a nightmare, and this in itself is enough of a reason to classify JavaScript as a bad language.

a = x.y
assigns the value of x's member y to a. What's so difficult about it?

The var rule is easy: use var if you want to create a new variable that has the scope of the current block. Otherwise you don't need var.

How could DOM be made easier? If its implementation is bad, this doesn't mean that the language is bad (and thus a bad choice for QSA).

AFAIK JavaScript was not designed by a comittee, but by Netscape.

And the lack of a class definition is possibly JavaScript's best feature, because it allows relatively powerful features in a very small language. Also note the word 'Script' in JavaScript. No one said that you should create huge programs with it.

> JavaScript is brittle. It is brittle because the specification is poorly
> written. Poorly written specifications are difficult to implement. Difficult
> implementations are error prone. Therefore, all of the problems that result
> from bad implementations of the interpreter can be traced back to the bad
> (ambiguous), formal, specification, and can thereby be attributed to the
> language itself.

Can you point us to any ambiguities in the specification ? The maintainer would certainly be interested to know. Apart from the know problems listed at

As opposed to what? Ad-hoc browser-specific behaviour? Or maybe you'd prefer no behavioural control at all, in which case we should toss :hover, :focus, :active and a few other pseudoclasses out of CSS... oops, then people won't know if what they're hovering over is really a link or not!

Unportable? HTF does client-side scripting make the Web unportable, outside of stupid, badly written browser-specific scripts which really should be tossed. Screen and projection clients mostly support EMCAScript decently; handheld doesn't, but that's to be expected (which means using client-side code on handhelds is plain STUPID), and I still wonder why people expect EMCAScript to work in aural and print modes. Uh, print is STATIC, people! And dynamic updating of aural is confusing and downright stupid.

Sites should not depend on client-side scripting, but no client-side scripting doesn't make anything better. In fact, it generally makes things worse, because then one layer of the program design is missing.

i prefer the cross-language nature of DCOP. the tool shouldn't *ideally* impose the language but let you choose it...
to me it's a setback from at least the objectives of DCOP scripting (didn't try it yet in the real world, so i can't tell for its current status).

But my main point is - there's already extremely right bindings to Qt for Python, a very mature language. They've gone and developed their own language from scratch. Give it a few generations and it might be as bug-free as Python, but you still wouldn't have access to the extraordinarily large libraries that Python already has.

NO! Your point is wrong. This is not a language from scratch. This is based on standard ECMAscript and is designed to be used for application extensibility by the USER. Not necessarily for general purpose bindings by the developer.

Which already-developed ECMAscript implementation did they use? Which off-the-shelf already-existing codebase did they use to implement their runtime? My point is that they have to develop that from scratch. Sure, they followed the ECMAscript _standard_, but that ain't code.

You don't care about the lengthy process we now have to go through to debug their implementation of the language, rather than use another, already mature language? Are you willing to even point at ONE existing ECMAscript implementation that's relatively bug free?

Oh wait, there's always KJS, which is mature. Hey, and as someone's already pointed out, it does what this new QSA is designed for. Are you beginning to see my point yet?