[Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch

[Ulf Hermann]

Hi,


Since at least Qt 5.8 (maybe even earlier, I cannot look it up right now) you can use the QML debugger with plain QJSEngines. Just start the application through Qt Creator's debug mode or use the "-qmljsdebugger=port:..." argument and connect with Qt Creator to the specified port. The QML debugger will give you many familiar debugging facilities like single stepping, break points, etc.


regards,

Ulf

________________________________
From: Development <development-bounces+ulf.hermann=qt.io at qt-project.org> on behalf of NAVSYSTEMS LTD <dh at navsystems-uk.com>
Sent: Friday, June 16, 2017 6:45:29 PM
To: development at qt-project.org
Subject: [Development] QtScript (deprecated) vs QJSEngine and reasons why QJSEngine isn't up to scratch

I have been using QtScript for many years (along with many other qt modules). Porting from QtScript to QJSEngine is clearly not trivial especially when I have multiple QScriptEngine uses in many processes but thats specific to my use not general. One very nice feature in QtScript is the debugger. In fact the debugger can even be split out into a separate process e.g a remote debugger (using QScriptDebuggerFrontend/Backend and a developer built of QScriptTools) and I'm sure others use this feature too. The debugger isn't simply a nice feature as without a debugger the amount of time needed to develop and debug scripts becomes so great its probably a non-starter. So looking at QJSEngine the first major obstacle to porting is the utter lack of any debugger support. This means for me at least QJSEngine is still not up to the job. I use scripts in several different applications (suites of applications actually), for us, they are not used for UI interaction but for behind the scenes custom data processing and realtime control. Our applications expose hundreds of QObject based classes and other data types to script land. Use of signals and slots and exposing signals to javascript is commonplace. For one application that is installed on unattended computers in remote locations the ability to connect a remote script debugger is an absolutely essential feature. So to keep this post short and to the point I won't ramble on anymore but will simply state that the first and probably most important deficiency, as I see it, is simply the lack of debugger support in QJSEngine. I am certain that there are others. There have been some posts earlier relating to QJSEngine vs QtScript performance but I cannot comment as I have not tried to port anything other than a simple test application and I have not benchmarked it either. I strongly suspect that the lack of debugger will make adoption of QJSEngine far less likely for many existing QtScript users other than those who's use cases are very trivial. NB I also use WebKit and am looking at the QWebEngine replacement but thats a whole other story and is similar and also rather unpleasant. Of course deprecation has to happen sometimes but premature deprecation and removal of features tend to force people to stick with the earlier working version s. So the question I would like to ask is are there any plans to extend the QJSEngine framework to add debugger support or should I assume I'm going to be stuck forever?

NavSystems (IOM) Ltd. +44 (0)1624 851253

Mobile:   +44 (0)7624 330943
<skype:davehussey?call>Use Skype<http://www.skype.com/go/download> to call me or send files.
Registered in the Isle of Man No: 122393C  VAT: GB 003 1736 25
Registered office: Kissack Court, Parliament Street, Ramsey, Isle of Man, IM8 1AT
Consider the Environment. Do you really need to print this e-mail?
Information in this e-mail may be confidential and is intended only for the recipients to which it is addressed.
Please notify the sender if you receive this e-mail by mistake.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170617/2d568710/attachment.html>