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

[Maziar]

@SGaist

Thx
Good News

1. how qt-project policy & roadmap commit in developer team ? only digia now decide ?
   2.have any roadmap av. for qt5 & Qt6 ?

2. and Frederik Gladhorn is commit roadmap in qt script section or is only Frederik idea .... ?

[SGaist]

@JulienMaille Do you mean like gmane ?

@Maziar Qt is an open governance project, so anybody can be part of it as long as he also does actively participate.
I don't really understand your use of the commit verb

[Maziar]

@SGaist

commit = authorize plan

yes qt is open source but how this open governance project decide some major change & select policy for next ?

i see QML is most focus of this project currently but how many persent of user need mL ???
have see any pool ?

[JKSH]

@Maziar said:

yes qt is open source but how this open governance project decide some major change & select policy for next ?

Many different companies and individuals work on Qt (examples: Intel, BlackBerry, The Qt Company, KDAB): http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png Each company makes their own internal decisions.

Each company works on the parts of Qt that are important to them. For example, KDAB is interested in 3D technology, so they developed the Qt 3D module: http://blog.qt.io/blog/2015/02/05/licensing-of-new-modules-in-qt-5-5/

To make decisions for the Qt Project (major or minor), the topic is discussed on the Development mailing list.

1. The community decides together.
2. If the community can't reach an agreement, then the module Maintainers will decide.
3. If the module Maintainers cannot reach an agreement, then the Chief Maintainer will make the final decision.

See https://wiki.qt.io/The_Qt_Governance_Model#Decision-making_process for more details.

[Maziar]

hi

"The community decides together."

how community decided about this topic ? and what location document this ? can have this ?

Thx

[JKSH]

@Maziar said:

"The community decides together."

how community decided about this topic ? and what location document this ? can have this ?

Note that decisions on this topic started in 2010/2011.

For the 2010/2011 decisions, see

• https://wiki.qt.io/Qt_Script_V8_Port
• https://bugreports.qt.io/browse/QTBUG-12503

People wanted to update Qt Script from JavaScriptCore to V8. They wanted Qt Script to provide JavaScript for Qt WebKit, QML, and user-scripting.

However, they found out that it is not feasible to update Qt Script like this. This is because Qt Script has many design problems (see http://article.gmane.org/gmane.comp.lib.qt.devel/4224 ). So, they created a new JavaScript engine for QML (QJSEngine).

It doesn't make sense to maintain more than 1 JavaScript engine in Qt. So, the developers focussed on developing QJSEngine.

Then, earlier this year, the Qt Company announced the idea of deprecating Qt Script: http://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/ The community had a long discussion about this topic in the blog comments, and also in the Interest mailing list.

You can read the final decision here: http://thread.gmane.org/gmane.comp.lib.qt.user/15833/focus=15838 (and you can click on the other links to see other parts of the discussion). As a result of the discussions, the Qt Company will now copy the important functionalities from Qt Script into QJSEngine.

[Maziar]

Then, earlier this year, the Qt Company announced the idea of deprecating Qt Script: http://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/ The community had a long discussion about this topic in the blog comments, and also in the Interest mailing list.

via my check seems qt user don't like this deprection whennot av. complete replacement & migration guide for example see :

[http://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/](link url)

you can see a few developer & digia clean problem not solve it !!!

this is very hasty depreciation ..... i think must solve & fix many other problem before this ....
and mixing qml & scripting is really not good job and give very bad pulses

i think qml is very important business for digia but really is for all ???

As a result of the discussions, the Qt Company will now copy the important functionalities from Qt Script into QJSEngine.

currently not done ...... but deprecation started .... it have good time for deprecation ?
and if we have poll from users how many percent of user agree with mixing qmL & scripting ???

my answer is absolute never

[JKSH]

@Maziar said:

mixing qml & scripting is really not good job and give very bad pulses
...
and if we have poll from users how many percent of user agree with mixing qmL & scripting ???

my answer is absolute never

I think you have misunderstood. There is no "mixing".

This is the situation:

• User-scripting requires a JavaScript engine.
• QML requires a JavaScript engine.
• User-scripting does not require QML.
• QML does not require user-scripting.

i think qml is very important business for digia but really is for all ???

Yes, I agree that QML is not for all. However, you don't need QML to do scripting.

As a result of the discussions, the Qt Company will now copy the important functionalities from Qt Script into QJSEngine.

currently not done ...... but deprecation started ....
...
this is very hasty depreciation .....
...
it have good time for deprecation ?

I don't understand... Could you please explain why you think this is a problem?

Anyway,

• "Deprecation" does not mean "Removal".
• "Deprecation" means "No new features will be added".
• "Deprecation" means "We won't spend time maintaining it".

You can continue to use Qt Script. Even though it is deprecated, it will still be available until Qt 6, at least.

[perim]

According to http://lists.qt-project.org/pipermail/development/2015-June/021979.html release 5.5 will be the last to support QtScript.

That means the API changes during a stable release series, for a module that in its initial release was announced as 'done' but not deprecated. So those of us who relied on this API promise are now totally screwed. The discussion of 'long term release' is beside the point - our users will update to the latest Qt version and find that our program breaks. There is talk of QJSEngine becoming a viable replacement in Qt 5.6, but even if that turns out to be the case, what do we do - convert all our code and leave users of the 'long term release' in the cold, or stay ourselves with the 'long term release' and screw all who update their systems?

It feels like a stab in the back. This kind of API change is why you increase the major version number. If that was done, distributions would know that they should allow both old and new versions of the library to be installed at the same time, and we could at least give us a migration path.

And that is assuming QJSEngine will ever get to the point of being a viable replacement, which I have yet to see.

[JKSH]

Hi @perim,

According to http://lists.qt-project.org/pipermail/development/2015-June/021979.html release 5.5 will be the last to support QtScript.

That means the API changes during a stable release series

To clarify, "deprecated" means "no more development". They won't accept bug reports, but the API will remain as-is. Qt Script will not be removed. You can continue to use Qt Script if you want.

[perim]

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

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

[JKSH]

@perim said:

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:

1. QtScript never had anything to do with neither WebKit, not V8 integration etc.. it was a ECMA compatible QSA replacement.
2. 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..