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

[Maziar]

Hi

After QSA in Last now Qt script deprecated after 5.5 !
http://qt-project.org/wiki/New-Features-in-Qt-5.5

what is replacement for it for in application scripting ?
if is QJSEngine where is debugger & binding for it ?

what you really need to deprecate ?

[JKSH]

Hi,

@Maziar said:

what is replacement for it for in application scripting ?
if is QJSEngine where is debugger & binding for it ?

QJSEngine is meant to be the replacement. However, Qt Script will continue to be available for the rest of Qt 5.x. It won't be removed until at least Qt 6.

For debugging, see "Script Exceptions" at http://doc.qt.io/qt-5/qjsengine.html. There is no equivalent for QScriptEngine debugger, however.

Can you explain what you mean by "binding"?

[Maziar]

1. without debugger script engine really not usable in complex scripts.and then many application use script really can not upgrade to QJSEngine.

I think first qt team do same support all part of qtscript to QJSEngine such as debugger
and without it forgetting one part is not good for Application lifetime policy of QT

2.binding : http://en.wikipedia.org/wiki/QtScript
The tools for import use entire qt framework in script

[JKSH]

@Maziar said:

1. without debugger script engine really not usable in complex scripts.and then many application use script really can not upgrade to QJSEngine.

I know.

Keep in mind though, that "deprecated" means "not recommended for new projects, but available for existing projects". It is fine for existing projects to keep using Qt Script.

I think first qt team do same support all part of qtscript to QJSEngine such as debugger
and without it forgetting one part is not good for Application lifetime policy of QT

If you want to request a debugger for QJSEngine, You can post a feature request to https://bugreports.qt.io/. (It's better to post there, because most of the Qt team doesn't see this forum).

2.binding : http://en.wikipedia.org/wiki/QtScript
The tools for import use entire qt framework in script

Interesting! I didn't know that tool existed. Note that it is a Qt Labs experiment, not part of Qt. It was not ported to Qt 5. (You can also post a feature request for this, but I don't know if it will get priority)

Anyway, QML items are scriptable and don't need bindings. If you use Qt Quick to create your GUI and use QQmlEngine (which is a subclass of QJSEngine), you can can script your GUI without bindings.

Do you currently have a project that needs these features?

[JulienMaille]

Wow I can't believe QtScript is marked as deprecated. That's such a disapointment
I'm using scripts and qtscriptgenerator a lot to customize my GUI and add flexibiltiy to my application.
I don't use Qt Quick and don't want to. Does it mean I won't be able to switch to SJSEngine?

[JKSH]

@JulienMaille said:

I don't use Qt Quick and don't want to. Does it mean I won't be able to switch to SJSEngine?

That's ok, you'll still be able to use Qt Script for many years.

I don't know what the Qt Project's plans are for QJSEngine. If you're interested, you can subscribe to the Interest mailing list and ask there -- Qt engineers are active on that list.

[JKSH]

@Maziar said:

what you really need to deprecate ?

I did some searching and found this: http://article.gmane.org/gmane.comp.lib.qt.devel/4224

[Maziar]

is old documentation

i think many section change to qt 5.5

[SGaist]

Hi,

Before anything else, please have a look at this excellent answer on the mailing list.

[JulienMaille]

Is there a way to read the interest list from thunderbird or a newsgroup client instead of the web version?

[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.