Qt 5.5 : Qt Script deprecated ..... What is replacement ?

perim

http://lists.qt-project.org/pipermail/development/2015-June/022004.html

Dropping the deprecated modules completely is actually what is being discussed.

JKSH

http://lists.qt-project.org/pipermail/development/2015-June/022004.html

Dropping the deprecated modules completely is actually what is being discussed.

In that email, Lars said, "...remove the deprecated modules from our Qt 5.6 release (maybe
with the exception of Qt Script)". Qt Script will still be released with Qt 5.6.

But more importantly, see http://lists.qt-project.org/pipermail/development/2015-June/021992.html

Maziar

@JKSH

i no understand why forget problem:
ONE of most important module of qt deprecated without ANY real replacement

yes we currently have unsupported module (qtscript) and have wish don't have one major bug because it not ANY support !
then what number of user can start one program with name ZZ use one module (qtscript) when it deprecated ?

and when qt6 out what happen for ZZ with qtscript module ??
these mean application lifetime problem in QT

please don't comment av. in ver 5.6 ...... we write code for six month use ??

qt-dev

I think removing QtScript (or makes it depreciated) it's really a huge mistake..
And I absolutely agree with a topic.

First of all, let me point out two very important things:

QtScript never had anything to do with neither WebKit, not V8 integration etc.. it was a ECMA compatible QSA replacement.
QtScript in most of cases had nothing to do with GUI part. I wrote a lot of code where QtScript was a convenient way to easy customize application logic, for sorting, filtering etc. Defining some custom objects sometimes etc. I can give a lot of examples where having such engine is superb ability to write efficient flexible code.

Again, I always assumed that having a lightweight scripting ability without dependency on any heavy web engines together with absolutely fab binding system to native QObjects infrastructure is absolutely unique selling point.

I like QML, I agree 100% that it requires modern web engine infrastructure but again, how on Earth it's connected with light weighted scripting engine which is absolutely independent part of Qt.

I understand that Qt itself is changing and probably efforts needed to support compatibility on a core level, but at the end of the day Digia charges for that.
Qt is not not only about drawing windows, gadgets, labels etc... it's an infrastructure..

QML is not and will not in any way a replacement for QtScript. I also understand that it will be really really (if not impossible) difficult to make a bindings for V8 as good as they are now available for QtScript just because a nature of those two cores.

I think if it's a problem of maintainers then better Digia/Qt-Project announce that and I am sure there will be people willing to keep this module on a proper compatibility level to be in a mainstream.

qt-dev

@Maziar Just to support what you are saying, you are absolutely right! QSA was great, and many people used it... Then is was discontinued in favor of ECMA compatibility, which was a pain, but I can accept that.

But current decision is absolutely unexplainable, in sense of removing something which is good, which is not breaking anything in QML and heavily used in a lot of projects.

And an argument of not having two JS engines in not acceptable either, because they are just different by the way they are used...

For example I have have a QML GUI using all modern features, but it doesnt mean that I am not willing to used QtScript for business logic in sorting models, or customizing some non-GUI components..