Qt Script for Applications 1.0 beta1, now GPL'd
Friday, 20 December 2002 | Numanee
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:
QT Script - AC - 2002-12-19
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++?
dcop - me - 2002-12-19
how much does this overlap with DCOP?
Re: dcop - Tim Jansen - 2002-12-20
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).
ARexx - ac - 2002-12-19
So this is kinda like ARexx-ports in old Amiga programs, right? If so, cool.
Re: ARexx - .jon - 2002-12-26
> 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)
KJS? - ac - 2002-12-19
Haven't we been able to do something similar for a while with the embedded version of KJS?
Re: KJS? - Navindra Umanee - 2002-12-19
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.
Re: KJS? - Richard Moore - 2002-12-20
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.
Re: KJS? - Tim Jansen - 2002-12-20
Is KJSEmbed already able to call the slots of a QObject?
Re: KJS? - Richard Moore - 2002-12-20
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.
Re: KJS? - Navindra Umanee - 2002-12-20
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).
Re: KJS? - Richard Moore - 2002-12-20
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.
Re: KJS? - Richard Moore - 2002-12-20
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: <!DOCTYPE actionset> <actionset> <header> <name>test_actions</name> <label>Test Actions</label> </header> <action> <name>file_quit</name> <type>KStdAction</type> <script type="js">app.quit()</script> </action> <action> <name>show_sidebar</name> <type>KToggleAction</type> <label><text>Show &Sidebar</text></label> <icons>tree_win</icons> <shortcut>Ctrl+T</shortcut> <script type="js">window.toggleSidebar()</script> </action> <action> <name>show_messages</name> <type>KToggleAction</type> <label><text>Show &Sidebar</text></label> <icons>output_win</icons> <shortcut>Ctrl+M</shortcut> <script type="js">window.toggleMessages()</script> </action> Cheers Rich.
Re: KJS? - Anton Velev - 2002-12-20
Yeah GPL sux, it shoud be bsd (or lgpl) for commercial use. <p> check <a href="http://dot.kde.org/1037348700/1037568690/1037621798/1037624498/1037631211/1037638725/1037642772/">this</a>
Re: KJS? - Kevin Krammer - 2002-12-21
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
GPL makes sense commercialy - Trestop - 2002-12-23
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.
Re: GPL makes sense commercialy - John Allsup - 2002-12-23
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
Re: KJS? - Richard - 2002-12-21
Yep, and the Python language bindings too. There's two implementations of scripting extensions to Qt right there. Why develop _another_?
Re: KJS? - ac - 2002-12-21
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.
wow... - fault0 - 2002-12-19
this reminds me of applescript
Other languages? - $c0rpi0n - 2002-12-19
It would be cool if this framework could be adapted to load support for other languages like Python as plugins. The GUI looks great!
Re: Other languages? - Richard Moore - 2002-12-20
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.
Re: Other languages? - Stephan Richter - 2002-12-21
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! :-)
Re: Other languages? - Richard - 2002-12-24
PyKDE already lets you write applications (and otherwise "script") KDE.
Why? - Richard - 2002-12-20
Why on Earth did they develop Yet Another Goddamn Language?
Re: Why? - Sad Eagle - 2002-12-20
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.
Re: Why? - Richard - 2002-12-20
Read it again. "based on". They've implemented their own.
Re: Why? - Sad Eagle - 2002-12-20
My turn again ;-). It's a subset, not really new language. Read just a tad further ;-)
Re: Why? - anon - 2002-12-20
Hey leave Tad out of this! : )
Re: Why? - Sean Russell - 2002-12-20
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.
Re: Why? - cylab - 2002-12-20
simple question: what make you believe that javascript is a bad language ?
Re: Why? - Tim Jansen - 2002-12-20
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)
Re: Why? - Sean Russell - 2002-12-21
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.
Re: Why? - Tim Jansen - 2002-12-21
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.
Re: Why? - Harri - 2002-12-21
> 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.
Re: Why? - Steve - 2004-04-08
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.
Re: Why? - Richard Moore - 2004-04-09
Would you care to restate your questions without the insults? If you do, then I'm willing to answer them. Grow up.
Re: Why? - Dark Phoenix - 2006-12-21
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.
Re: Why? - Philippe Fremy - 2002-12-20
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.
Re: Why? - emmanuel - 2002-12-20
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).
Re: Why? - Tim Jansen - 2002-12-20
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.
Re: Why? - Richard - 2002-12-21
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.
Re: Why? - ac - 2002-12-21
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?
Re: Why? - Richard - 2002-12-21
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.
Re: Why? - ac - 2002-12-21
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.
Re: Why? - Phil Thompson - 2002-12-21
Of course it is trivial. See http://www.thekompany.com/projects/vp (although the code isn't currently maintained).
Re: Why? - Richard - 2002-12-22
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?
Re: Why? - Bernd Gehrmann - 2002-12-22
> 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.
Re: Why? - Richard - 2002-12-24
So QSA uses the existing KJS implementation?
Re: Why? - ac - 2002-12-20
This is what ECMAscript was designed _for_. Period.
Re: Why? - Harri - 2002-12-21
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.
Comparable to M$ VisualBasic? - Ruediger Knoerig - 2002-12-20
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.
Re: Comparable to M$ VisualBasic? - Margus Eha - 2002-12-20
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
Re: Comparable to M$ VisualBasic? - Ruediger Knoerig - 2002-12-22
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.
Re: Comparable to M$ VisualBasic? - Tim Jansen - 2002-12-20
Right now, it is an alternative to VBA, not VB. (With some work it would probably be usable for stand-alone apps though)
Python.... - Tsali - 2002-12-20
.... plus pyQT/pyKDE does this stuff already, doesn't it? Although I must admit, the dropdown for the intellisense looked really juicy in that screenshot!
Re: Python.... - Bernd Gehrmann - 2002-12-20
No it doesn't. 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.
Re: Python.... - Tsali - 2002-12-20
It sounded to me from reading their FAQ that Trolltech was writing bindings into their C code anyways to make this thing work. Thank you for your clarification.
Re: Python.... - Tim Jansen - 2002-12-21
QSA can access all slots of a QObject and its properties. So if you want to make a non-QObject accessible, you either need to convert it to a QObject, or write wrappers.
Re: Python.... - Phil Thompson - 2002-12-21
This is somewhat misleading. 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.
Re: Python.... - Bernd Gehrmann - 2002-12-22
> 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.
Re: Python.... - Phil Thompson - 2002-12-22
> > 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.
Re: Python.... - Bernd Gehrmann - 2002-12-23
> 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.
QT just filling in the gaps - Timo - 2002-12-20
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.
Re: QT just filling in the gaps - Richard Moore - 2002-12-20
Actually, the core of KHTML is not even dependent on Qt. That's why it has been ported to platforms such as Atheos. I suspect the maintainance overhead is the main reason it's not in Qt. Rich.