DevHeads.net

Policy regarding QtWebKit and QtScript

Hi,
Soon Qt 5.6 will be released and with it, 2 quite widely used
frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but
I think this is much less of a problem.

I'd say we need a plan to figure out what to do with these
dependencies. I don't think assuming that they will stay around is
very wise, so I'd suggest to come up collectively or specifically on
each project how to deal with those.

I'd say it's especially pressing on KDE Frameworks where Qt5::Script
is still quite widely used (kio, ki18n, ktexteditor,
plasma-framework).

Aleix

Comments

Re: Policy regarding QtWebKit and QtScript

By Albert Astals Cid at 12/22/2015 - 17:02

El Tuesday 22 December 2015, a les 18:10:44, Aleix Pol va escriure:
As far as I understand they are just going to be stopped from releasing, this
doesn't mean we can't keep using them, no?

Cheers,
Albert

Re: Policy regarding QtWebKit and QtScript

By Pau Garcia i Quiles at 12/22/2015 - 18:01

The 6-12-18 months they will still be buildable and usable are the time to
look for an alternative, or to enhance QJSEngine/QWebEngine, so that they
are good for KDE. According to qt-interest, some commercial and LGPL users
seem to face the same problems, therefore The Qt Company is probably open
to enhancements.

Re: Policy regarding QtWebKit and QtScript

By Luigi Toscano at 12/22/2015 - 18:06

Pau Garcia i Quiles ha scritto:
Shouldn't it be the other way around? Workable solution first and drop the old
one later?

But yeah, maybe too late, sadly.

Ciao

Re: Policy regarding QtWebKit and QtScript

By Thiago Macieira at 12/23/2015 - 06:44

On Wednesday 23 December 2015 00:06:18 Luigi Toscano wrote:
The big problem of keeping qtwebkit in the 5.6 release is that it would need
to be supported for the 3 years of the long term support release and that is
simply too much to ask for, for a module that needs security updates we are
hardly getting from upstream.

Re: Policy regarding QtWebKit and QtScript

By Pau Garcia i Quiles at 12/22/2015 - 18:28

On Wed, Dec 23, 2015 at 12:06 AM, Luigi Toscano <luigi. ... at tiscali dot it>
wrote:

As people provided specific examples of common features that would be
broken, the deprecation was delayed by 6 months (maybe 12, I cannot really
remember and time flies).

We are now at the second deprecation announcement, and this time it seems
it's for real. Most features people requested were added to
QJSEngine/QWebEngine (not necessarily with an easy or optimal migration
path).

Re: Policy regarding QtWebKit and QtScript

By Ivan Cukic at 12/22/2015 - 12:21

<a href="http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/" title="http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/">http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/</a>

Seems Qt Script will stay for a bit longer. So, I'd say getting rid of
webkit is the primary task. And a problematic one since a few distros
expressed the reluctance to ship the QtWebEngine.

As for QtScript, I see two approaches:
- kross (what is the state of it?)
- qml engines

Cheerio,
Ivan

Re: Policy regarding QtWebKit and QtScript

By Alexander Potashev at 12/22/2015 - 12:40

2015-12-22 20:21 GMT+03:00 Ivan Čukić <ivan. ... at kde dot org>:
Hi Ivan,

I don't get what you are suggesting.

QtScript support in Kross depends on Qt's QtScript.

Re: Policy regarding QtWebKit and QtScript

By Ivan Cukic at 12/22/2015 - 13:05

Meant to reimplement the scripting mechanisms we have to use Kross
instead of QtScript - to expose the scriptable objects to Kross.

IIRC (haven't checked Kross for a long time) it supported accessing Qt
objects and properties/methods, was able to run javascript with kjs
and similar, and that is mostly what we needed from QtScript.

EDIT: I've read the kross readme and the following:

So, using Kross would mean implementing the kjs backend for it that we
had in 4.x times?

Cheers,
Ivan

Re: Policy regarding QtWebKit and QtScript

By =?utf-8?Q?Thoma... at 12/22/2015 - 13:27

Isn't the designated successor for QtScript QJSEngine (I even assumed there should be some porting tools?)

About QtWebkit - what exactly does "disappear" mean in this context?
Will it be impossible to link QtWebKit 5.5 to Qt 5.6 ?
For if it would, that would be one giant ABI break and the answer would be to fork Qt... :-P

Cheers,
Thomas

Re: Policy regarding QtWebKit and QtScript

By Allan Sandfeld ... at 12/22/2015 - 13:50

On Tuesday 22 December 2015, Thomas Lübking wrote:
Best regards
`Allan

Re: Policy regarding QtWebKit and QtScript

By Lisandro =?ISO-... at 12/22/2015 - 14:04

On Tuesday 22 December 2015 19:50:43 Allan Sandfeld Jensen wrote:
And should be compilable for some time, indeed.

Re: Policy regarding QtWebKit and QtScript

By Ivan Cukic at 12/22/2015 - 13:38

That's what I meant under 'qml engines'. :)

A relevant mail by Frederik:
<a href="http://lists.qt-project.org/pipermail/interest/2015-June/017446.html" title="http://lists.qt-project.org/pipermail/interest/2015-June/017446.html">http://lists.qt-project.org/pipermail/interest/2015-June/017446.html</a>

Cheers,
Ivan

Re: Policy regarding QtWebKit and QtScript

By Christoph Cullmann at 12/23/2015 - 11:29

Hi,

1) kross is useless for it

2) QJSEngine: I tried to port with Qt 5.4, but it didn't allow for all things needed like setting up some
global functions in the engine and wrapping custom datatypes like QtScript did, perhaps this has changed
but as IMHO no porting guidelines exist, have not tried it again. (attached the state of the port,
if somebody wants to give it a try) But as the above mail indicates, such a guide should come up.

Greetings
Christoph