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).
Qt Script for Applications 1.0 beta1, now GPL'd
Dot Categories:
Comments
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++?
how much does this overlap with DCOP?
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.
> 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)
Haven't we been able to do something similar for a while with the embedded version of KJS?
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.
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.
Is KJSEmbed already able to call the slots of a QObject?
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.
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).
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.
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.
Yeah GPL sux, it shoud be bsd (or lgpl) for commercial use.
check this
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
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.
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
Yep, and the Python language bindings too. There's two implementations of scripting extensions to Qt right there. Why develop _another_?
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.
this reminds me of applescript
It would be cool if this framework could be adapted to load support for other languages like Python as plugins. The GUI looks great!
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.
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! :-)
PyKDE already lets you write applications (and otherwise "script") KDE.
Why on Earth did they develop Yet Another Goddamn Language?
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.
Read it again. "based on". They've implemented their own.
My turn again ;-). It's a subset, not really new language. Read just a tad further ;-)
Hey leave Tad out of this! : )
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.
simple question: what make you believe that javascript is a bad language ?
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.
* 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.
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.
> 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.
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.
Would you care to restate your questions without the insults? If you do, then I'm willing to answer them. Grow up.
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.
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.
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 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.
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.
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?
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.
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.
Of course it is trivial. See http://www.thekompany.com/projects/vp (although the code isn't currently maintained).
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?
> 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.
So QSA uses the existing KJS implementation?
This is what ECMAscript was designed _for_. Period.