Qt Script for Applications 1.0 beta1, now GPL'd

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

Dot Categories: 

Comments

by AC (not verified)

This looks like it would be very useful. Can you write whole Qt apps with it, or is it limited to just playing a supporting role to C++?

by me (not verified)

how much does this overlap with DCOP?

by Tim Jansen (not verified)

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

by ac (not verified)

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

by .jon (not verified)

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

Go abstract ! Not specific again...

.jon (long time (still) Amiga user and ARexx coder)

by ac (not verified)

Haven't we been able to do something similar for a while with the embedded version of KJS?

by Navindra Umanee (not verified)

Yeah, I'm not really informed too well on this. Maybe Rich can say how QAS and KJS relate to each other. Of course there's DCOP in there too.

by Richard Moore (not verified)

Looking over the documentation the two seem to be virtually identical.

- QAS has a nice built in script editor which kjsembed does not, but kjsembed can load designers ui files anyway and it would be easy to add.

- KJSEmbed has facilities for working with KActions (I will soon be committing a new version which will load XML files that define actions). QAS doesn't have this, but could be made to.

- KJSEmbed has the full Javascript language available, while QAS only has a subset. eg. KJSEmbed can use the standard javascript Math and RegExp facilities.

- KJSEmbed can access the DOM from a KHTML part so it can work nicely with HTML and XML documents.

- KJSEmbed is LGPL while QAS is GPL.

Hope this sheds some light.

Rich.

by Tim Jansen (not verified)

Is KJSEmbed already able to call the slots of a QObject?

by Richard Moore (not verified)

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.

Rich.

by Navindra Umanee (not verified)

Oh, wow. Did we ever announce this?

Where is the documentation for KJS? I tried to find it on developer.kde.org but it wasn't where I thought it would be (http://developer.kde.org/language-bindings/tools/index.html).

by Richard Moore (not verified)

The docs aren't online at the moment (until recently they weren't even written!). You'll be pleased to hear that part of my documentation exercise it a tutorial for the dot.

Rich.

by Richard Moore (not verified)

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:

test_actions
Test Actions

file_quit
KStdAction
app.quit()

show_sidebar
KToggleAction
Show &Sidebar
tree_win
Ctrl+T
window.toggleSidebar()

show_messages
KToggleAction
Show &Sidebar
output_win
Ctrl+M
window.toggleMessages()

Cheers

Rich.

by Anton Velev (not verified)

Yeah GPL sux, it shoud be bsd (or lgpl) for commercial use.

check this

by Kevin Krammer (not verified)

The examples in the article you referred to, are flawed.

For example it doesn't matter for an application which license kicker is based on if it just wants to dock to the system tray.

The application just creates its tray handler and tells the window manager that it wants it docked into the system's tray.
The tray area might be provided by kicker.
No linking, no license problem.

Same for the embedding example.
The application links against the LGPL interface, the system decides which component to load.
The application only links against LGPL code, no license problem.

That's why most (all?) KDE base libraries, including koffice libs, are LGPL.

Cheers,
Kevin

by Trestop (not verified)

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

You want Trolltech to make money. Q.E.D.

by John Allsup (not verified)

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.

Merry Christmas,

John

by Richard (not verified)

Yep, and the Python language bindings too. There's two implementations of scripting extensions to Qt right there. Why develop _another_?

by ac (not verified)

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.

by fault0 (not verified)

this reminds me of applescript

by $c0rpi0n (not verified)

It would be cool if this framework could be adapted to load support for other languages like Python as plugins. The GUI looks great!

by Richard Moore (not verified)

Actually extending this to python would be quite easy. You just need to make an equivalent of the JSObjectProxy class in KJSEmbed and you're done. It is only a few hours work.

Rich.

by Stephan Richter (not verified)

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! :-)

by Richard (not verified)

PyKDE already lets you write applications (and otherwise "script") KDE.

by Richard (not verified)

Why on Earth did they develop Yet Another Goddamn Language?

by Sad Eagle (not verified)

Why on earth do people make comments about things they don't know much about?

Last I checked, ECMAScript/JavaScript/JScript was in wide use in those exotic programs called web browsers.

by Richard (not verified)

Read it again. "based on". They've implemented their own.

by Sad Eagle (not verified)

My turn again ;-). It's a subset, not really new language. Read just a tad further ;-)

by anon (not verified)

Hey leave Tad out of this! : )

by Sean Russell (not verified)

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.

In any case, I expected better from the Qt folks.

by cylab (not verified)

simple question: what make you believe that javascript is a bad language ?

by Tim Jansen (not verified)

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)

by Sean Russell (not verified)

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.

* DOM. DOM sucks, and JavaScript uses DOM. DOM is heavy and unintuitive. The actual API behavior seems to vary between browsers.

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

by Tim Jansen (not verified)

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.

by Harri (not verified)

> Ignoring, for the moment, that there isn't a single *good*
> implementation of the ECMAScript interpreter;

Can you please tell us what kind of problems you have found in all ECMAScript implementations out there ?

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

An implementation is free to warn about a missing "var". The QSA interpreter does so, other implementations don't even compile code without it.

> * DOM. DOM sucks, and JavaScript uses DOM. DOM is heavy and unintuitive.
> The actual API behavior seems to vary between browsers.

What does the DOM have to do with ECMAScript ?

> 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

http://www.mozilla.org/js/language/E262-3-errata.html

I couldn't find anything wrong after reading through the standard a dozen times.

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

QSA is following the "strict mode" upcoming Edition 4 of ECMAScript. It knows about classes, typed variables, access specifies and everything you can dream of. Check out the current draft here:

http://www.mozilla.org/js/language/es4/index.html

Harri.

by Steve (not verified)

Why do you people defend JavaScript? It really is a pile of crap. The DOM is a pile of crap too. IMO you should use client side scripting sparingly.

Are you criticizing him just because his argument may not be "well-formulated" to you?

If so than you are giving JavaScript a defense that it does not deserve. JavaScript is a complete pile of crap, as is every other client-side scripting technology. There simply are not any good ones.

Client side technologies make the Web what it shouldn't be: unportable.

Get a life instead of nit-picking the details of someone's argument.

Sean Russel I applaud you.
This message board is a pile of sh*t.

by Richard Moore (not verified)

Would you care to restate your questions without the insults? If you do, then I'm willing to answer them. Grow up.

by Dark Phoenix (not verified)

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.

by Philippe Fremy (not verified)

And it is used not only in web browsers, but in industrial environments as a glue language. So Qt is definitely making the right move here.

by emmanuel (not verified)

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

by Tim Jansen (not verified)

But dcop is quite limited and only useful for very simple scripts. It doesnt help you when you create a Qt/KDE GUI, or extend a class. And I wouldnt want to use it to access complex data.

by Richard (not verified)

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.

*shrug* it just doesn't make sense to me.

by ac (not verified)

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.

Maybe you don't understand the concept of application extensibility?

by Richard (not verified)

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.

And python's trivially embedded as an application scripting language.

by ac (not verified)

Your point is that they had to develop from scratch? Sorry, I don't care for your point. *yawn*

Python is trivial to embedd as a Qt scripting language? Uh-huh. Then why didn't you already do it? I suggest you try it first, then try to deploy it, and then come back with proven arguments.

by Phil Thompson (not verified)

Of course it is trivial. See http://www.thekompany.com/projects/vp (although the code isn't currently maintained).

by Richard (not verified)

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?

by Bernd Gehrmann (not verified)

> You don't care about the lengthy process we now have to go through

We?

> Oh wait, there's always KJS, which is mature.

You realize that the primary author of KJS is working
for Trolltech? ;-)

> Hey, and as someone's already pointed out, it does
> what this new QSA is designed for.

No, you just show that you haven´t understood what QSA is.
KJS is just a ECMAScript interpreter, which is just a
component in a comprehensive scripting framework.

by Richard (not verified)

So QSA uses the existing KJS implementation?

by ac (not verified)

This is what ECMAscript was designed _for_. Period.