Discussion:
Deprecating modules with 5.5
(too old to reply)
Knoll Lars
2015-02-03 07:33:46 UTC
Permalink
Hi,

I’d like to mark a few modules as deprecated with 5.5, and most likely
remove them from the binary packages with 5.6. These modules are:

* Qt WebKit
* Qt Declarative (Qt Quick 1)
* Qt Script

All of these modules are by now a couple of years old, don’t receive
updates above the bare minimum and have a replacement that is actively
being developed in Qt 5.

Cheers,
Lars
Ziller Eike
2015-02-03 07:47:14 UTC
Permalink
> On Feb 3, 2015, at 8:33 AM, Knoll Lars <***@theqtcompany.com> wrote:
>
> Hi,
>
> I’d like to mark a few modules as deprecated with 5.5, and most likely
> remove them from the binary packages with 5.6. These modules are:
>
> * Qt WebKit

As long as WebEngine is not (yet?) a “full" replacement of Qt WebKit functionality, most notably
https://bugreports.qt.io/browse/QTBUG-44221
we should still include Qt WebKit in our binary packages.
Assistant and Qt Creator will otherwise only have a QTextBrowser backend for displaying help,
leading to broken looking documentation, since that does not even roughly support the CSS that
we use in Qt documentation.

Br, Eike

> * Qt Declarative (Qt Quick 1)
> * Qt Script
>
> All of these modules are by now a couple of years old, don’t receive
> updates above the bare minimum and have a replacement that is actively
> being developed in Qt 5.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Eike Ziller, Senior Software Engineer - The Qt Company GmbH

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
Knoll Lars
2015-02-03 07:50:21 UTC
Permalink
On 03/02/15 08:47, "Ziller Eike" <***@theqtcompany.com> wrote:

>
>> On Feb 3, 2015, at 8:33 AM, Knoll Lars <***@theqtcompany.com>
>>wrote:
>>
>> Hi,
>>
>> I’d like to mark a few modules as deprecated with 5.5, and most likely
>> remove them from the binary packages with 5.6. These modules are:
>>
>> * Qt WebKit
>
>As long as WebEngine is not (yet?) a “full" replacement of Qt WebKit
>functionality, most notably
>https://bugreports.qt.io/browse/QTBUG-44221
>we should still include Qt WebKit in our binary packages.
>Assistant and Qt Creator will otherwise only have a QTextBrowser backend
>for displaying help,
>leading to broken looking documentation, since that does not even roughly
>support the CSS that
>we use in Qt documentation.

Yes, of course we can only remove it once we don’t have dependencies onto
the module in other places anymore.

Cheers,
Lars

>
>Br, Eike
>
>> * Qt Declarative (Qt Quick 1)
>> * Qt Script
>>
>> All of these modules are by now a couple of years old, don’t receive
>> updates above the bare minimum and have a replacement that is actively
>> being developed in Qt 5.
>>
>> Cheers,
>> Lars
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>--
>Eike Ziller, Senior Software Engineer - The Qt Company GmbH
>
>The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
>Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
>Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
>Charlottenburg, HRB 144331 B
>
André Pönitz
2015-02-03 19:25:54 UTC
Permalink
On Tue, Feb 03, 2015 at 07:47:14AM +0000, Ziller Eike wrote:
>
> > On Feb 3, 2015, at 8:33 AM, Knoll Lars <***@theqtcompany.com> wrote:
> >
> > Hi,
> >
> > I’d like to mark a few modules as deprecated with 5.5, and most likely
> > remove them from the binary packages with 5.6. These modules are:
> >
> > * Qt WebKit
>
> As long as WebEngine is not (yet?) a “full" replacement of Qt WebKit
> functionality, most notably https://bugreports.qt.io/browse/QTBUG-44221 we
> should still include Qt WebKit in our binary packages. Assistant and Qt
> Creator will otherwise only have a QTextBrowser backend for displaying help,
> leading to broken looking documentation, since that does not even roughly
> support the CSS that we use in Qt documentation.

I think the main dependency here is that Qt Creator needs to render Qt
documentation. What technology this uses is of secondary interest. It
just needs to be "good enough", and it preferably should not be a lot bigger
than actually needed for the task.

WebKit was already a bit of a stretch here, I do not really see WebEngine as
an improvement in the size and overhead departement. It's a huge club for a
task that's just a wee bit beyond the QTextBrowser fallback's capabilities
(which was, btw, working reasonably well for a while about two or three
years ago, until some change in the doc style sheet made it really ugly
again).

Creator would benefit most from a *lightweight* HTML renderer, possibly
thin wrappers around platforms' native renderers, _or_ a doc style that's
usable in QTextBrowser, less so from being used as a pawn in the WebKit vs
WebEngine discussion, both of which are not really good fits for the task.

Andre'
Knoll Lars
2015-02-03 20:14:42 UTC
Permalink
On 03/02/15 20:25, "André Pönitz" <***@t-online.de> wrote:

>On Tue, Feb 03, 2015 at 07:47:14AM +0000, Ziller Eike wrote:
>>
>> > On Feb 3, 2015, at 8:33 AM, Knoll Lars <***@theqtcompany.com>
>>wrote:
>> >
>> > Hi,
>> >
>> > I’d like to mark a few modules as deprecated with 5.5, and most likely
>> > remove them from the binary packages with 5.6. These modules are:
>> >
>> > * Qt WebKit
>>
>> As long as WebEngine is not (yet?) a “full" replacement of Qt WebKit
>> functionality, most notably https://bugreports.qt.io/browse/QTBUG-44221
>>we
>> should still include Qt WebKit in our binary packages. Assistant and Qt
>> Creator will otherwise only have a QTextBrowser backend for displaying
>>help,
>> leading to broken looking documentation, since that does not even
>>roughly
>> support the CSS that we use in Qt documentation.
>
>I think the main dependency here is that Qt Creator needs to render Qt
>documentation. What technology this uses is of secondary interest. It
>just needs to be "good enough", and it preferably should not be a lot
>bigger
>than actually needed for the task.
>
>WebKit was already a bit of a stretch here, I do not really see WebEngine
>as
>an improvement in the size and overhead departement. It's a huge club for
>a
>task that's just a wee bit beyond the QTextBrowser fallback's capabilities
>(which was, btw, working reasonably well for a while about two or three
>years ago, until some change in the doc style sheet made it really ugly
>again).
>
>Creator would benefit most from a *lightweight* HTML renderer, possibly
>thin wrappers around platforms' native renderers, _or_ a doc style that's
>usable in QTextBrowser, less so from being used as a pawn in the WebKit vs
>WebEngine discussion, both of which are not really good fits for the task.

Yes, making the Qt WebView module work on all desktop platforms could be a
possible solution.

Cheers,
Lars
Thiago Macieira
2015-02-03 22:26:15 UTC
Permalink
On Tuesday 03 February 2015 20:14:42 Knoll Lars wrote:
> Yes, making the Qt WebView module work on all desktop platforms could be a
> possible solution.

I think the consensus here is that we need some more work on Qt WebView /
webengine before we can drop QtWebKit from the binaries.

That said, yes, I agree on deprecating it or, at least, warning people that
this is coming.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Knoll Lars
2015-02-04 08:10:48 UTC
Permalink
On 03/02/15 23:26, "Thiago Macieira" <***@intel.com> wrote:

>On Tuesday 03 February 2015 20:14:42 Knoll Lars wrote:
>> Yes, making the Qt WebView module work on all desktop platforms could
>>be a
>> possible solution.
>
>I think the consensus here is that we need some more work on Qt WebView /
>webengine before we can drop QtWebKit from the binaries.
>
>That said, yes, I agree on deprecating it or, at least, warning people
>that
>this is coming.

Yes, agree on both things :)

So deprecate with 5.5, drop from packages once WebView and WebEngine can
together cover most use cases.

Cheers,
Lars
Rutledge Shawn
2015-02-05 14:33:13 UTC
Permalink
On 3 Feb 2015, at 20:25, André Pönitz <***@t-online.de> wrote:

> I think the main dependency here is that Qt Creator needs to render Qt
> documentation. What technology this uses is of secondary interest. It
> just needs to be "good enough", and it preferably should not be a lot bigger
> than actually needed for the task.
>
> WebKit was already a bit of a stretch here, I do not really see WebEngine as
> an improvement in the size and overhead departement. It's a huge club for a
> task that's just a wee bit beyond the QTextBrowser fallback's capabilities
> (which was, btw, working reasonably well for a while about two or three
> years ago, until some change in the doc style sheet made it really ugly
> again).
>
> Creator would benefit most from a *lightweight* HTML renderer, possibly
> thin wrappers around platforms' native renderers, _or_ a doc style that's
> usable in QTextBrowser, less so from being used as a pawn in the WebKit vs
> WebEngine discussion, both of which are not really good fits for the task.

I agree. For every kind of documentation in every app which has a help system, and in other use cases where people use real web browsers without needing all the features, it would be great to have a lightweight alternative which has no Javascript, no plugins, and a means to turn off network access. (It probably needs CSS support though, unfortunately.) That would be best for the sake of security as well as conserving memory and CPU cycles.

Already, when documentation links to outside web sites, Creator calls up the system browser if you click such a link. It should stay that way, IMO.
Lisandro Damián Nicanor Pérez Meyer
2015-02-05 17:39:54 UTC
Permalink
On Thursday 05 February 2015 14:33:13 Rutledge Shawn wrote:
[snip]
> I agree. For every kind of documentation in every app which has a help
> system, and in other use cases where people use real web browsers without
> needing all the features, it would be great to have a lightweight
> alternative which has no Javascript, no plugins, and a means to turn off
> network access. (It probably needs CSS support though, unfortunately.)
> That would be best for the sake of security as well as conserving memory
> and CPU cycles.
>
> Already, when documentation links to outside web sites, Creator calls up the
> system browser if you click such a link. It should stay that way, IMO.

This will greatly reduce webkit/webcore usage in most apps, so benefiting us
distributions security-wise.

--
Ponga su mano en una estufa caliente por un minuto, y le parecerá como una
hora. Siéntese con una muchacha bonita por una hora, y le parecerá un minuto.
¡Eso es relatividad!.
Albert Einstein (1879-1955)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Jaroslaw Staniek
2015-02-03 08:24:04 UTC
Permalink
On 3 February 2015 at 08:33, Knoll Lars <***@theqtcompany.com> wrote:
> Hi,
>
> I’d like to mark a few modules as deprecated with 5.5, and most likely
> remove them from the binary packages with 5.6. These modules are:
>
> * Qt WebKit
> * Qt Declarative (Qt Quick 1)
> * Qt Script
>
> All of these modules are by now a couple of years old, don’t receive
> updates above the bare minimum and have a replacement that is actively
> being developed in Qt 5.

Thanks for the update.
Is there a replacement for, say, 90% of Qt Script features, including
these where performance counts?
I understand that the concern here is that the engine itself isn't and
won't be updated.

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Knoll Lars
2015-02-03 08:29:08 UTC
Permalink
On 03/02/15 09:24, "Jaroslaw Staniek" <***@kde.org> wrote:

>On 3 February 2015 at 08:33, Knoll Lars <***@theqtcompany.com>
>wrote:
>> Hi,
>>
>> I’d like to mark a few modules as deprecated with 5.5, and most likely
>> remove them from the binary packages with 5.6. These modules are:
>>
>> * Qt WebKit
>> * Qt Declarative (Qt Quick 1)
>> * Qt Script
>>
>> All of these modules are by now a couple of years old, don’t receive
>> updates above the bare minimum and have a replacement that is actively
>> being developed in Qt 5.
>
>Thanks for the update.
>Is there a replacement for, say, 90% of Qt Script features, including
>these where performance counts?

QtQml should with 5.5 have most of the required API and the performance
should not be a whole lot worse than QtScript (as the JS engine in there
is by now ~5 years old). Please let Simon and myself know if you’re
missing some functionality or find some larger performance gap.

Cheers,
Lars

>I understand that the concern here is that the engine itself isn't and
>won't be updated.
>
>--
>regards, Jaroslaw Staniek
>
>KDE:
>: A world-wide network of software engineers, artists, writers,
>translators
>: and facilitators committed to Free Software development - http://kde.org
>Calligra Suite:
>: A graphic art and office suite - http://calligra.org
>Kexi:
>: A visual database apps builder - http://calligra.org/kexi
>Qt Certified Specialist:
>: http://www.linkedin.com/in/jstaniek
Jaroslaw Staniek
2015-02-03 08:35:45 UTC
Permalink
On 3 February 2015 at 09:29, Knoll Lars <***@theqtcompany.com> wrote:
> On 03/02/15 09:24, "Jaroslaw Staniek" <***@kde.org> wrote:
>
>>On 3 February 2015 at 08:33, Knoll Lars <***@theqtcompany.com>
>>wrote:
>>> Hi,
>>>
>>> I’d like to mark a few modules as deprecated with 5.5, and most likely
>>> remove them from the binary packages with 5.6. These modules are:
>>>
>>> * Qt WebKit
>>> * Qt Declarative (Qt Quick 1)
>>> * Qt Script
>>>
>>> All of these modules are by now a couple of years old, don’t receive
>>> updates above the bare minimum and have a replacement that is actively
>>> being developed in Qt 5.
>>
>>Thanks for the update.
>>Is there a replacement for, say, 90% of Qt Script features, including
>>these where performance counts?
>
> QtQml should with 5.5 have most of the required API and the performance
> should not be a whole lot worse than QtScript (as the JS engine in there
> is by now ~5 years old). Please let Simon and myself know if you’re
> missing some functionality or find some larger performance gap.

Thanks for the info. As for performance, I'd mention I am looking for
equivalents of QScriptClass which is a handy and light tool.

Other than that - QScriptEngineDebugger equivalents?

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Hausmann Simon
2015-02-03 08:50:38 UTC
Permalink
Hi,

Functionality wise, what type of "class" do you wrap with QScriptClass?


Simon

Original Message
From: Jaroslaw Staniek
Sent: Tuesday, February 3, 2015 09:36
To: Knoll Lars
Cc: ***@qt-project.org
Subject: Re: [Development] Deprecating modules with 5.5


On 3 February 2015 at 09:29, Knoll Lars <***@theqtcompany.com> wrote:
> On 03/02/15 09:24, "Jaroslaw Staniek" <***@kde.org> wrote:
>
>>On 3 February 2015 at 08:33, Knoll Lars <***@theqtcompany.com>
>>wrote:
>>> Hi,
>>>
>>> I’d like to mark a few modules as deprecated with 5.5, and most likely
>>> remove them from the binary packages with 5.6. These modules are:
>>>
>>> * Qt WebKit
>>> * Qt Declarative (Qt Quick 1)
>>> * Qt Script
>>>
>>> All of these modules are by now a couple of years old, don’t receive
>>> updates above the bare minimum and have a replacement that is actively
>>> being developed in Qt 5.
>>
>>Thanks for the update.
>>Is there a replacement for, say, 90% of Qt Script features, including
>>these where performance counts?
>
> QtQml should with 5.5 have most of the required API and the performance
> should not be a whole lot worse than QtScript (as the JS engine in there
> is by now ~5 years old). Please let Simon and myself know if you’re
> missing some functionality or find some larger performance gap.

Thanks for the info. As for performance, I'd mention I am looking for
equivalents of QScriptClass which is a handy and light tool.

Other than that - QScriptEngineDebugger equivalents?

--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Jaroslaw Staniek
2015-02-05 15:32:08 UTC
Permalink
On 3 February 2015 at 09:50, Hausmann Simon
<***@theqtcompany.com> wrote:
> Hi,
>
> Functionality wise, what type of "class" do you wrap with QScriptClass?

Examples (you can guess from what project by looking at my footer):
- Light data types (anything you see in databases and isn't mapping to
javascript types). Long long?
- Any very numerious non-QObject objects or calculated entities and/or
properties that have no their structures at all. Thing about a
database record accessible by record.<fieldname>.

Apart of that I'd also think about placing javascript bindings on the
(headless) server side too, think of extensions to PostgreSQL, SQLite.
The goal is to have the very same user-defined functions available at
both client and server side.

As said before I also need an API to implement a full visual debugger.

>
> Simon
>
> Original Message
> From: Jaroslaw Staniek
> Sent: Tuesday, February 3, 2015 09:36
> To: Knoll Lars
> Cc: ***@qt-project.org
> Subject: Re: [Development] Deprecating modules with 5.5
>
>
> On 3 February 2015 at 09:29, Knoll Lars <***@theqtcompany.com> wrote:
>> On 03/02/15 09:24, "Jaroslaw Staniek" <***@kde.org> wrote:
>>
>>>On 3 February 2015 at 08:33, Knoll Lars <***@theqtcompany.com>
>>>wrote:
>>>> Hi,
>>>>
>>>> I’d like to mark a few modules as deprecated with 5.5, and most likely
>>>> remove them from the binary packages with 5.6. These modules are:
>>>>
>>>> * Qt WebKit
>>>> * Qt Declarative (Qt Quick 1)
>>>> * Qt Script
>>>>
>>>> All of these modules are by now a couple of years old, don’t receive
>>>> updates above the bare minimum and have a replacement that is actively
>>>> being developed in Qt 5.
>>>
>>>Thanks for the update.
>>>Is there a replacement for, say, 90% of Qt Script features, including
>>>these where performance counts?
>>
>> QtQml should with 5.5 have most of the required API and the performance
>> should not be a whole lot worse than QtScript (as the JS engine in there
>> is by now ~5 years old). Please let Simon and myself know if you’re
>> missing some functionality or find some larger performance gap.
>
> Thanks for the info. As for performance, I'd mention I am looking for
> equivalents of QScriptClass which is a handy and light tool.
>
> Other than that - QScriptEngineDebugger equivalents?
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Simon Hausmann
2015-02-05 15:44:53 UTC
Permalink
On Thursday 5. February 2015 16.32.08 Jaroslaw Staniek wrote:
> On 3 February 2015 at 09:50, Hausmann Simon
>
> <***@theqtcompany.com> wrote:
> > Hi,
> >
> > Functionality wise, what type of "class" do you wrap with QScriptClass?
>
> Examples (you can guess from what project by looking at my footer):
> - Light data types (anything you see in databases and isn't mapping to
> javascript types). Long long?
> - Any very numerious non-QObject objects or calculated entities and/or
> properties that have no their structures at all. Thing about a
> database record accessible by record.<fieldname>.

For those, would the new value type bindings be a sufficient replacement?
See also

http://doc-snapshot.qt-project.org/qt5-dev/qtqml-cppintegration-data.html#value-types

Once your type is a Q_GADGET you should be able to make a copy of it visible in JavaScript as easy as

QJSValue value = engine.toScriptValue(myValueType);

> Apart of that I'd also think about placing javascript bindings on the
> (headless) server side too, think of extensions to PostgreSQL, SQLite.
> The goal is to have the very same user-defined functions available at
> both client and server side.
>
> As said before I also need an API to implement a full visual debugger.

I'm afraid the debugging isn't quite on the table yet as we're still exploring different
implementations. The approach chosen in QtScript is too limiting for the engine
overall, but Andre has done some amazing work on trying out a new approach that
combines with the native debugger. But we're not talking API at this point though.

Simon
Jaroslaw Staniek
2015-02-05 22:08:03 UTC
Permalink
On 5 February 2015 at 16:44, Simon Hausmann
<***@theqtcompany.com> wrote:
> On Thursday 5. February 2015 16.32.08 Jaroslaw Staniek wrote:
>> On 3 February 2015 at 09:50, Hausmann Simon
>>
>> <***@theqtcompany.com> wrote:
>> > Hi,
>> >
>> > Functionality wise, what type of "class" do you wrap with QScriptClass?
>>
>> Examples (you can guess from what project by looking at my footer):
>> - Light data types (anything you see in databases and isn't mapping to
>> javascript types). Long long?
>> - Any very numerious non-QObject objects or calculated entities and/or
>> properties that have no their structures at all. Thing about a
>> database record accessible by record.<fieldname>.
>
> For those, would the new value type bindings be a sufficient replacement?
> See also
>
> http://doc-snapshot.qt-project.org/qt5-dev/qtqml-cppintegration-data.html#value-types
>
> Once your type is a Q_GADGET you should be able to make a copy of it visible in JavaScript as easy as
>
> QJSValue value = engine.toScriptValue(myValueType);
>

Thanks, I'll analyze that. Quick look make me unsure about one thing,
Q_PROPERTY is a compile-time declaration. I'd like to add
properties/members dynamically at run time and I'd like to of course
avoid calling eval() for that.

>> Apart of that I'd also think about placing javascript bindings on the
>> (headless) server side too, think of extensions to PostgreSQL, SQLite.
>> The goal is to have the very same user-defined functions available at
>> both client and server side.
>>
>> As said before I also need an API to implement a full visual debugger.
>
> I'm afraid the debugging isn't quite on the table yet as we're still exploring different
> implementations. The approach chosen in QtScript is too limiting for the engine
> overall, but Andre has done some amazing work on trying out a new approach that
> combines with the native debugger. But we're not talking API at this point though.

If something appears within one year, I am fine with that. If not,
native debugger integration developed externally, oh...


--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Simon Hausmann
2015-02-06 07:52:01 UTC
Permalink
On Thursday 5. February 2015 23.08.03 Jaroslaw Staniek wrote:
> On 5 February 2015 at 16:44, Simon Hausmann
>
> <***@theqtcompany.com> wrote:
> > On Thursday 5. February 2015 16.32.08 Jaroslaw Staniek wrote:
> >> On 3 February 2015 at 09:50, Hausmann Simon
> >>
> >> <***@theqtcompany.com> wrote:
> >> > Hi,
> >> >
> >> > Functionality wise, what type of "class" do you wrap with QScriptClass?
> >>
> >> Examples (you can guess from what project by looking at my footer):
> >> - Light data types (anything you see in databases and isn't mapping to
> >> javascript types). Long long?
> >> - Any very numerious non-QObject objects or calculated entities and/or
> >> properties that have no their structures at all. Thing about a
> >> database record accessible by record.<fieldname>.
> >
> > For those, would the new value type bindings be a sufficient replacement?
> > See also
> >
> > http://doc-snapshot.qt-project.org/qt5-dev/qtqml-cppintegration-data.html#
> > value-types
> >
> > Once your type is a Q_GADGET you should be able to make a copy of it
> > visible in JavaScript as easy as
> >
> > QJSValue value = engine.toScriptValue(myValueType);
>
> Thanks, I'll analyze that. Quick look make me unsure about one thing,
> Q_PROPERTY is a compile-time declaration. I'd like to add
> properties/members dynamically at run time and I'd like to of course
> avoid calling eval() for that.

Hmm, we currently only allow that for QObject bindings. So if you do

QJSValue wrapper = engine.newQObject(someQObject);

then you can add arbitrary properties to that JS object simply via

wrapper.setProperty("myExtraProperty", 42);

and it will be a dynamically added property if there exists no Q_PROPERTY.

The value of that property is accessible from C++ via the QJSValue API, i.e.
if you have a pointer to the QObject you can do

QObject *thatObject = ...
QJSEngine *engine = qjsEngine(thatObject);
QJSValue blah = engine->newQObject(thatObject).property("myExtraProperty");


In theory we could add the same feature to the value types, but I'm hesitant
about it. With QObject the ownership semantics are explicitly shared, so it's
clear (after learning the API) that you're operating on an object shared
between C++ and JavaScript. With value types the engine will take a copy of
the data when you do engine->toScriptValue(something) so it's not clear what
should happen with those "dynamically" added properties when going back to
C++.

So if you can apply the use of dynamic properties to QObject based types, then
I think you should be good to go.


Simon
Alexey Pavlov
2015-02-03 08:35:07 UTC
Permalink
2015-02-03 10:33 GMT+03:00 Knoll Lars <***@theqtcompany.com>:

> Hi,
>
> I’d like to mark a few modules as deprecated with 5.5, and most likely
> remove them from the binary packages with 5.6. These modules are:
>
> * Qt WebKit
> * Qt Declarative (Qt Quick 1)
> * Qt Script
>
> All of these modules are by now a couple of years old, don’t receive
> updates above the bare minimum and have a replacement that is actively
> being developed in Qt 5.
>
>
Does this mean that QtWebEngine will be provided for Mingw targets instead
Webkit? Now Mingw can't build QWebEngine.

Regards,
Alexey.


> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Knoll Lars
2015-02-03 08:49:59 UTC
Permalink
On 03/02/15 09:35, "Alexey Pavlov" <***@gmail.com> wrote:

>
>
>2015-02-03 10:33 GMT+03:00 Knoll Lars <***@theqtcompany.com>:
>
>Hi,
>
>I’d like to mark a few modules as deprecated with 5.5, and most likely
>remove them from the binary packages with 5.6. These modules are:
>
>* Qt WebKit
>* Qt Declarative (Qt Quick 1)
>* Qt Script
>
>All of these modules are by now a couple of years old, don’t receive
>updates above the bare minimum and have a replacement that is actively
>being developed in Qt 5.
>
>
>
>
>Does this mean that QtWebEngine will be provided for Mingw targets
>instead Webkit? Now Mingw can't build QWebEngine.

It’ll probably be difficult to build WebEngine against Mingw, but I hope
that we can build it with clang on Windows when 5.6 comes. Currently you
have to use MSVC if you need WebEngine on Windows.

But we don’t really have a choice, as there is no upstream for Qt WebKit
anymore. This implies that we’d have to fully develop that fork on our own
to support is. That in turn requires a team far larger than what we have.
So it’s simply not doable.

Cheers,
Lars
Alexey Pavlov
2015-02-03 09:08:57 UTC
Permalink
2015-02-03 11:49 GMT+03:00 Knoll Lars <***@theqtcompany.com>:

> On 03/02/15 09:35, "Alexey Pavlov" <***@gmail.com> wrote:
>
> >
> >
> >2015-02-03 10:33 GMT+03:00 Knoll Lars <***@theqtcompany.com>:
> >
> >Hi,
> >
> >I’d like to mark a few modules as deprecated with 5.5, and most likely
> >remove them from the binary packages with 5.6. These modules are:
> >
> >* Qt WebKit
> >* Qt Declarative (Qt Quick 1)
> >* Qt Script
> >
> >All of these modules are by now a couple of years old, don’t receive
> >updates above the bare minimum and have a replacement that is actively
> >being developed in Qt 5.
> >
> >
> >
> >
> >Does this mean that QtWebEngine will be provided for Mingw targets
> >instead Webkit? Now Mingw can't build QWebEngine.
>
> It’ll probably be difficult to build WebEngine against Mingw, but I hope
> that we can build it with clang on Windows when 5.6 comes. Currently you
> have to use MSVC if you need WebEngine on Windows.
>
> But we don’t really have a choice, as there is no upstream for Qt WebKit
> anymore. This implies that we’d have to fully develop that fork on our own
> to support is. That in turn requires a team far larger than what we have.
> So it’s simply not doable.
>


So Qt 5.6 can drop mingw support?


> Cheers,
> Lars
>
>
Knoll Lars
2015-02-03 09:51:10 UTC
Permalink
On 03/02/15 10:08, "Alexey Pavlov" <***@gmail.com> wrote:

>
>
>2015-02-03 11:49 GMT+03:00 Knoll Lars <***@theqtcompany.com>:
>
>On 03/02/15 09:35, "Alexey Pavlov" <***@gmail.com> wrote:
>
>>
>>
>>2015-02-03 10:33 GMT+03:00 Knoll Lars <***@theqtcompany.com>:
>>
>>Hi,
>>
>>I’d like to mark a few modules as deprecated with 5.5, and most likely
>>remove them from the binary packages with 5.6. These modules are:
>>
>>* Qt WebKit
>>* Qt Declarative (Qt Quick 1)
>>* Qt Script
>>
>>All of these modules are by now a couple of years old, don’t receive
>>updates above the bare minimum and have a replacement that is actively
>>being developed in Qt 5.
>>
>>
>>
>>
>>Does this mean that QtWebEngine will be provided for Mingw targets
>>instead Webkit? Now Mingw can't build QWebEngine.
>
>It’ll probably be difficult to build WebEngine against Mingw, but I hope
>that we can build it with clang on Windows when 5.6 comes. Currently you
>have to use MSVC if you need WebEngine on Windows.
>
>But we don’t really have a choice, as there is no upstream for Qt WebKit
>anymore. This implies that we’d have to fully develop that fork on our own
>to support is. That in turn requires a team far larger than what we have.
>So it’s simply not doable.
>
>
>So Qt 5.6 can drop mingw support?

There are currently no plans in dropping mingw. But webengine is currently
not supported on that compiler.

Lars
André Somers
2015-02-03 10:59:11 UTC
Permalink
Knoll Lars schreef op 3-2-2015 om 10:51:
>
> So Qt 5.6 can drop mingw support?
> There are currently no plans in dropping mingw. But webengine is currently
> not supported on that compiler.
>
So I guess that does mean that it will no longer be Tier 1 then.

André
Frank Hemer
2015-02-05 10:57:49 UTC
Permalink
On Tuesday 03 February 2015 11:59:11 André Somers wrote:
> Knoll Lars schreef op 3-2-2015 om 10:51:
> > So Qt 5.6 can drop mingw support?
> > There are currently no plans in dropping mingw. But webengine is currently
> > not supported on that compiler.
>
> So I guess that does mean that it will no longer be Tier 1 then.

This would be a showstopper for our development (medical) as we do need:

* mingw
* webkit as there is currently no replacement for the pdf-viewer/plugin

Frank
Guido Seifert
2015-02-04 13:52:36 UTC
Permalink
If you don't have a choice, you don't have a choice, but just saying:
In one of my projects I needed the x264 libs:
http://www.videolan.org/developers/x264.html
and the webkit. I was unable to compile x264 with MSVC. Dropping webkit
would leave me in the inconvenient situation that either I cannot
build x264 or the webkit replacement.

IMHO not being able to build 100% of Qt with the Mingw is not a minor problem.

Guido

> It’ll probably be difficult to build WebEngine against Mingw, but I
> hope that we can build it with clang on Windows when 5.6 comes.
> Currently you have to use MSVC if you need WebEngine on Windows.
>
> But we don’t really have a choice, as there is no upstream for Qt
> WebKit anymore. This implies that we’d have to fully develop that
> fork on our own to support is. That in turn requires a team far
> larger than what we have. So it’s simply not doable.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Joseph Crowell
2015-02-04 14:13:32 UTC
Permalink
It's relatively simple to compile x264 with visual studio 2013+. I was just
reading about it.
On 4 Feb 2015 11:52 pm, "Guido Seifert" <***@gmx.de> wrote:

> If you don't have a choice, you don't have a choice, but just saying:
> In one of my projects I needed the x264 libs:
> http://www.videolan.org/developers/x264.html
> and the webkit. I was unable to compile x264 with MSVC. Dropping webkit
> would leave me in the inconvenient situation that either I cannot
> build x264 or the webkit replacement.
>
> IMHO not being able to build 100% of Qt with the Mingw is not a minor
> problem.
>
> Guido
>
> > It’ll probably be difficult to build WebEngine against Mingw, but I
> > hope that we can build it with clang on Windows when 5.6 comes.
> > Currently you have to use MSVC if you need WebEngine on Windows.
> >
> > But we don’t really have a choice, as there is no upstream for Qt
> > WebKit anymore. This implies that we’d have to fully develop that
> > fork on our own to support is. That in turn requires a team far
> > larger than what we have. So it’s simply not doable.
> >
> > Cheers,
> > Lars
> >
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Kevin Kofler
2015-02-05 14:19:08 UTC
Permalink
Knoll Lars wrote:
> But we don’t really have a choice, as there is no upstream for Qt WebKit
> anymore. This implies that we’d have to fully develop that fork on our own
> to support is. That in turn requires a team far larger than what we have.
> So it’s simply not doable.

The thing is, QtWebEngine is also a problem for Fedora, because we do not
even have Chromium in Fedora because it bundles so many libraries, and in
QtWebEngine, you bundle Chromium! Bundled libraries are not allowed in
Fedora (nor Debian, for that matter). So we do not currently have
QtWebEngine packaged in Fedora and I'm not convinced that we will ever have
it. (We have a specfile, but it does not comply with the project-wide
bundling policies and as such will likely not pass review.) Both QtWebEngine
bundling Chromium, and Chromium itself bundling lots of other stuff are
blockers.

QtWebEngine also has some additional regressions compared to QtWebKit:
* no GStreamer support, instead relying on a custom FFmpeg that is hard to
add additional codecs to (whereas for GStreamer, the user just needs to
install the plugin packages that are used by all GStreamer applications),
* no QNetworkAccess support, and thus no way to plug in KIO support. So it
is hardcoded to support only the protocols Chromium supports out of the
box, no way to add additional ones (man:, info:, gopher:, etc.),
* no support for our secondary architectures, due to the V8 dependency.

Relying on Chromium is a horrible idea. If we had been asked beforehand (we
only learned of it when the big, secretively developed code drop was
unveiled), we would have told you immediately that Chromium is a no go.

For the "no upstream" issue, is it not possible to work together with
WebKitGTK+? They are sticking to WebKit, aren't they?

Kevin Kofler
Knoll Lars
2015-02-05 15:28:23 UTC
Permalink
On 05/02/15 15:19, "Kevin Kofler" <***@chello.at> wrote:

>Knoll Lars wrote:
>> But we don’t really have a choice, as there is no upstream for Qt WebKit
>> anymore. This implies that we’d have to fully develop that fork on our
>>own
>> to support is. That in turn requires a team far larger than what we
>>have.
>> So it’s simply not doable.
>
>The thing is, QtWebEngine is also a problem for Fedora, because we do not
>even have Chromium in Fedora because it bundles so many libraries, and in
>QtWebEngine, you bundle Chromium! Bundled libraries are not allowed in
>Fedora (nor Debian, for that matter). So we do not currently have
>QtWebEngine packaged in Fedora and I'm not convinced that we will ever
>have
>it. (We have a specfile, but it does not comply with the project-wide
>bundling policies and as such will likely not pass review.) Both
>QtWebEngine
>bundling Chromium, and Chromium itself bundling lots of other stuff are
>blockers.
>
>QtWebEngine also has some additional regressions compared to QtWebKit:
>* no GStreamer support, instead relying on a custom FFmpeg that is hard to
> add additional codecs to (whereas for GStreamer, the user just needs to
> install the plugin packages that are used by all GStreamer
>applications),
>* no QNetworkAccess support, and thus no way to plug in KIO support. So it
> is hardcoded to support only the protocols Chromium supports out of the
> box, no way to add additional ones (man:, info:, gopher:, etc.),
>* no support for our secondary architectures, due to the V8 dependency.
>
>Relying on Chromium is a horrible idea. If we had been asked beforehand
>(we
>only learned of it when the big, secretively developed code drop was
>unveiled), we would have told you immediately that Chromium is a no go.

It wasn’t secret at all. We blog’ed about it before we started, and did
the development in the open.

But we don’t have much of a choice, if we want to deliver an up to date
web engine. With Qt WebKit we would have needed around 5 times the people
to keep it working and in a state that is competitive. This was pretty
much the only way we could keep an up to date engine going with the amount
of people we have.

I understand that you have certain policies, but the reality out there is
that a certain level of pragmatism is required if you want to get a usable
and competitive product.


>For the "no upstream" issue, is it not possible to work together with
>WebKitGTK+? They are sticking to WebKit, aren't they?

Yes, and I am sure, they have huge issues keeping up with the development
of competing web technologies. I’ve been there and done that with first
KHTML, then Qt WebKit for many years. The fact is that HTML5 these days is
a huge pig, and supporting all of it using WebKit and supporting 10
different platforms is simply not possible with a team that’s smaller than
~50 people. We have tried for many years.

Cheers,
Lars
Kevin Kofler
2015-02-05 16:08:12 UTC
Permalink
Knoll Lars wrote:
> Yes, and I am sure, they have huge issues keeping up with the development
> of competing web technologies. I’ve been there and done that with first
> KHTML, then Qt WebKit for many years. The fact is that HTML5 these days is
> a huge pig, and supporting all of it using WebKit and supporting 10
> different platforms is simply not possible with a team that’s smaller than
> ~50 people. We have tried for many years.

The thing is, if you want to deliver something that is suitable for
distributions (which the current QtWebEngine is NOT!), you will need to fork
Chromium, because upstream does not care about the issues.

Distributions such as Debian support many architectures. The Debian
maintainers I've been in contact with over IRC were really unhappy to learn
that QtWebEngine depends on V8. (They had not realized the implications of
the announcement that it would use Chromium.) A JIT-only JavaScript engine,
and browser code hardcoded to use only that engine (they removed the JS
engine abstraction layer from WebKit and hardcoded V8 all over the place!)
is horrible for portability. In Fedora, our primary architectures happen to
be the ones V8 is targeting, but we do have secondary architectures on which
we do not want to desupport large parts of Qt (such as Qt Assistant) and
KDE.

The bundling thing also really MUST be resolved. (At least the bundling of
the many system libraries by Chromium. If you communicate that you have to
bundle Chromium because you have to fork it to remove all the other bundled
libraries, that will likely be a convincing enough argument to justify
bundling Chromium.) It is just not practical to ship a second copy of dozens
of system libraries, all built as part of QtWebEngine. This is a nightmare
in terms of disk space, RAM use, potential for symbol conflicts and delivery
of security updates.

We distributions also very much want the web browser to use our shared
multimedia stack, i.e. GStreamer.

Then, the advantages of going with Chromium quickly start to vanish. IMHO,
QtWebEngine is the one that should be deprecated.

Kevin Kofler
Robert Knight
2015-02-06 14:22:33 UTC
Permalink
> It is just not practical to ship a second copy of dozens
> of system libraries, all built as part of QtWebEngine. This is a nightmare
> in terms of disk space, RAM use, potential for symbol conflicts and
delivery
> of security updates.

These are all valid concerns but ultimately of secondary importance to most
app developers
who care most about delivering working software to their end users and for
them the OS X / Windows
model of bundling anything not guaranteed to be part of the base platform
works quite nicely.

We ship a complete copy of Qt in our non-open source app for Linux and a
runtime wrapper that will
choose on the fly whether to use it or not. Because of that we are able to
offer a _better_ experience
for our users than packaged open source software, which sucks.

I'm not super enthused about shipping what is effectively a big chunk of an
operating system as part of an
app, but I can't disagree with Lars' comments about the effort required to
maintain a modern browser engine.

On 5 February 2015 at 16:08, Kevin Kofler <***@chello.at> wrote:

> Knoll Lars wrote:
> > Yes, and I am sure, they have huge issues keeping up with the development
> > of competing web technologies. I’ve been there and done that with first
> > KHTML, then Qt WebKit for many years. The fact is that HTML5 these days
> is
> > a huge pig, and supporting all of it using WebKit and supporting 10
> > different platforms is simply not possible with a team that’s smaller
> than
> > ~50 people. We have tried for many years.
>
> The thing is, if you want to deliver something that is suitable for
> distributions (which the current QtWebEngine is NOT!), you will need to
> fork
> Chromium, because upstream does not care about the issues.
>
> Distributions such as Debian support many architectures. The Debian
> maintainers I've been in contact with over IRC were really unhappy to learn
> that QtWebEngine depends on V8. (They had not realized the implications of
> the announcement that it would use Chromium.) A JIT-only JavaScript engine,
> and browser code hardcoded to use only that engine (they removed the JS
> engine abstraction layer from WebKit and hardcoded V8 all over the place!)
> is horrible for portability. In Fedora, our primary architectures happen to
> be the ones V8 is targeting, but we do have secondary architectures on
> which
> we do not want to desupport large parts of Qt (such as Qt Assistant) and
> KDE.
>
> The bundling thing also really MUST be resolved. (At least the bundling of
> the many system libraries by Chromium. If you communicate that you have to
> bundle Chromium because you have to fork it to remove all the other bundled
> libraries, that will likely be a convincing enough argument to justify
> bundling Chromium.) It is just not practical to ship a second copy of
> dozens
> of system libraries, all built as part of QtWebEngine. This is a nightmare
> in terms of disk space, RAM use, potential for symbol conflicts and
> delivery
> of security updates.
>
> We distributions also very much want the web browser to use our shared
> multimedia stack, i.e. GStreamer.
>
> Then, the advantages of going with Chromium quickly start to vanish. IMHO,
> QtWebEngine is the one that should be deprecated.
>
> Kevin Kofler
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Matthew Woehlke
2015-02-06 18:45:05 UTC
Permalink
On 2015-02-06 09:22, Robert Knight wrote:
>> It is just not practical to ship a second copy of dozens
>> of system libraries, all built as part of QtWebEngine. This is a nightmare
>> in terms of disk space, RAM use, potential for symbol conflicts and
>> delivery of security updates.
>
> These are all valid concerns but ultimately of secondary importance to most
> app developers
> who care most about delivering working software to their end users and for
> them the OS X / Windows
> model of bundling anything not guaranteed to be part of the base platform
> works quite nicely.
>
> We ship a complete copy of Qt in our non-open source app for Linux and a
> runtime wrapper that will
> choose on the fly whether to use it or not. Because of that we are able to
> offer a _better_ experience
> for our users than packaged open source software, which sucks.

...and you're keeping up to date with all the security patches to Qt,
Chromium, etc.? If not, your "better experience" is leaving your
application's users vulnerable.

Bad enough for individual applications to shoulder that burden. When you
talk about the cost of maintaining a web engine, don't forget that by
bundling Chromium, *you* (i.e. the Qt project) are taking on
responsibility for the security of that entire stack. This means
releasing a new version *of Qt* whenever a security issue is found in
Chromium. Or in anything that Chromium bundles.

Putting myself in the library/framework developer role, I would strongly
want to punt that burden to upstream / the distro.

--
Matthew
Robert Knight
2015-02-08 12:03:32 UTC
Permalink
> ...and you're keeping up to date with all the security patches
> to Qt, Chromium, etc.? If not, your "better experience" is leaving
> your application's users vulnerable.

We have the capability to turn around an update quickly if necessary and
try to use system libraries where possible, especially for things like
networking, but this misses the point. The majority of desktop users, even
technically knowledgeable ones, care first and foremost about having
working tools.

The trade-offs look different if you're talking about a piece of
infrastructure (eg. a web server) and for that domain, distro policies
around bundling make a lot of sense.

On Fri Feb 06 2015 at 18:45:27 Matthew Woehlke <
***@users.sourceforge.net> wrote:

> On 2015-02-06 09:22, Robert Knight wrote:
> >> It is just not practical to ship a second copy of dozens
> >> of system libraries, all built as part of QtWebEngine. This is a
> nightmare
> >> in terms of disk space, RAM use, potential for symbol conflicts and
> >> delivery of security updates.
> >
> > These are all valid concerns but ultimately of secondary importance to
> most
> > app developers
> > who care most about delivering working software to their end users and
> for
> > them the OS X / Windows
> > model of bundling anything not guaranteed to be part of the base platform
> > works quite nicely.
> >
> > We ship a complete copy of Qt in our non-open source app for Linux and a
> > runtime wrapper that will
> > choose on the fly whether to use it or not. Because of that we are able
> to
> > offer a _better_ experience
> > for our users than packaged open source software, which sucks.
>
> ...and you're keeping up to date with all the security patches to Qt,
> Chromium, etc.? If not, your "better experience" is leaving your
> application's users vulnerable.
>
> Bad enough for individual applications to shoulder that burden. When you
> talk about the cost of maintaining a web engine, don't forget that by
> bundling Chromium, *you* (i.e. the Qt project) are taking on
> responsibility for the security of that entire stack. This means
> releasing a new version *of Qt* whenever a security issue is found in
> Chromium. Or in anything that Chromium bundles.
>
> Putting myself in the library/framework developer role, I would strongly
> want to punt that burden to upstream / the distro.
>
> --
> Matthew
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Lisandro Damián Nicanor Pérez Meyer
2015-02-05 18:55:52 UTC
Permalink
I'll try to summarize my POV on this issue in this mail:

- I agree with Lars that HTML5 is a huge pig ;)

- Bundling so many stuff in that package is definitely a non go for Debian.

- I do also understand they require a competitive product. But on the same
line I do also think the level of pragmatism needed for shipping QtWebEngine
*as it currently is* is simply too much for Debian.

- Having yet another copy of chromium in the archive really doesn't sounds
great, as far as I understand we don't even give security support in Debian
stable :-/ [0]

- Unbundling all that stuff and making it work with system stuff **might** be
doable, but I *personally* won't put my time on this. I have communicated this
decision to my fellow comaintainers and so far no one has stood up for the
challenge. So chances are that we aren't going to ship it (and this might mean
the same for Ubuntu). Yes, things might break, but with no man power there is
really nothing to do.

- I won't stop anybody trying to unbundle all the required stuff and trying to
get it to work with system libs, I will simply not put my time on that.

- Using V8 means we need to drop support for arm64 (aka AArch64), powerpc,
powerpc64 and s390x. I understand this *might* be a minor side effect for the
Qt project, but still important for us.


[0] <https://www.debian.org/security/2015/dsa-3148>

Happy hacking! :)

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Thiago Macieira
2015-02-05 19:24:01 UTC
Permalink
On Thursday 05 February 2015 15:55:52 Lisandro Damián Nicanor Pérez Meyer
wrote:
> - Using V8 means we need to drop support for arm64 (aka AArch64), powerpc,
> powerpc64 and s390x. I understand this *might* be a minor side effect for
> the Qt project, but still important for us.

I'm pretty sure that there is or will soon be an arm64 port of V8, since
Android is coming to that. But that won't change PPC and other targets, since
I doubt there is any activity in those.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Allan Sandfeld Jensen
2015-02-05 20:39:16 UTC
Permalink
On Thursday 05 February 2015, Lisandro Damián Nicanor Pérez Meyer wrote:
> I'll try to summarize my POV on this issue in this mail:
>
> - I agree with Lars that HTML5 is a huge pig ;)
>
> - Bundling so many stuff in that package is definitely a non go for Debian.
>
> - I do also understand they require a competitive product. But on the same
> line I do also think the level of pragmatism needed for shipping
> QtWebEngine *as it currently is* is simply too much for Debian.
>
> - Having yet another copy of chromium in the archive really doesn't sounds
> great, as far as I understand we don't even give security support in Debian
> stable :-/ [0]
>
> - Unbundling all that stuff and making it work with system stuff **might**
> be doable, but I *personally* won't put my time on this. I have
> communicated this decision to my fellow comaintainers and so far no one
> has stood up for the challenge. So chances are that we aren't going to
> ship it (and this might mean the same for Ubuntu). Yes, things might
> break, but with no man power there is really nothing to do.
>
> - I won't stop anybody trying to unbundle all the required stuff and trying
> to get it to work with system libs, I will simply not put my time on that.
>
> - Using V8 means we need to drop support for arm64 (aka AArch64), powerpc,
> powerpc64 and s390x. I understand this *might* be a minor side effect for
> the Qt project, but still important for us.
>
>
> [0] <https://www.debian.org/security/2015/dsa-3148>
>
It would have been the same problem with WebKit. Neither Google nor Apple
cares about supporting any build environment more than 1-2 years old. When we
still was part of WebKit, Digia were the ones supporting the at the time most
widely used OS X release 10.6 because Apple did not, and that on top of
support all Windows versions which Apple doesn't care about those either.

And as you might remember PowerPC turned out to have been broken in QtWebKit's
JavaScriptCore 5.0 to 5.3, and no one noticed, and those changes are not even
upstreamable because Apple doesn't care.

That said. I would prefer to deprecate QtWebKitWidgets in a later release, but
the actual difference would be minimal, we are not going to invest any more or
any less resources depending on what we call it.

`Allan
Lisandro Damián Nicanor Pérez Meyer
2015-02-05 23:06:30 UTC
Permalink
On Thursday 05 February 2015 21:39:16 Allan Sandfeld Jensen wrote:
[snip]
> > [0] <https://www.debian.org/security/2015/dsa-3148>
>
> It would have been the same problem with WebKit. Neither Google nor Apple
> cares about supporting any build environment more than 1-2 years old. When
> we still was part of WebKit, Digia were the ones supporting the at the time
> most widely used OS X release 10.6 because Apple did not, and that on top
> of support all Windows versions which Apple doesn't care about those
> either.

Yes, this is true, and actually one of the reason I don't want to spend my
time in packaging this web stuff :)

> And as you might remember PowerPC turned out to have been broken in
> QtWebKit's JavaScriptCore 5.0 to 5.3, and no one noticed, and those changes
> are not even upstreamable because Apple doesn't care.

But at least there we could just disable JIT, which is what we did. When we
had V8 around (if I remember correctly it was used for QML, but my memory
might be failing me) we couldn't.

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Allan Sandfeld Jensen
2015-02-05 23:15:48 UTC
Permalink
On Friday 06 February 2015, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Thursday 05 February 2015 21:39:16 Allan Sandfeld Jensen wrote:
> [snip]
>
> > > [0] <https://www.debian.org/security/2015/dsa-3148>
> >
> > It would have been the same problem with WebKit. Neither Google nor Apple
> > cares about supporting any build environment more than 1-2 years old.
> > When we still was part of WebKit, Digia were the ones supporting the at
> > the time most widely used OS X release 10.6 because Apple did not, and
> > that on top of support all Windows versions which Apple doesn't care
> > about those either.
>
> Yes, this is true, and actually one of the reason I don't want to spend my
> time in packaging this web stuff :)
>
> > And as you might remember PowerPC turned out to have been broken in
> > QtWebKit's JavaScriptCore 5.0 to 5.3, and no one noticed, and those
> > changes are not even upstreamable because Apple doesn't care.
>
> But at least there we could just disable JIT, which is what we did. When we
> had V8 around (if I remember correctly it was used for QML, but my memory
> might be failing me) we couldn't.

The problem with PowerPC was that the non-JIT fallback was not working on big
endian machines, which was not discovered by any of the regularly tested
platforms and configurations. I meant it as an example that having a non-JIT
fallback doesn't seem to help much because so few people use it that it is not
even discovered when it compiles but crashes on run.

About QtWebEngine, do you know what system libraries you have problems with it
duplicating? I think we can configure most of it in the build system and
already follow the Qt build settings for some that are usually shipped with
Chromium.

`Allan
Lisandro Damián Nicanor Pérez Meyer
2015-02-06 01:21:26 UTC
Permalink
(Resending as I replied to Allan in private by mistake))

On Friday 06 February 2015 00:15:48 you wrote:
[snip]
> > But at least there we could just disable JIT, which is what we did. When
> > we
> > had V8 around (if I remember correctly it was used for QML, but my memory
> > might be failing me) we couldn't.
>
> The problem with PowerPC was that the non-JIT fallback was not working on
> big endian machines, which was not discovered by any of the regularly
> tested platforms and configurations. I meant it as an example that having a
> non-JIT fallback doesn't seem to help much because so few people use it
> that it is not even discovered when it compiles but crashes on run.

Again, true. The good thing here is that, thanks a lot to your help, it was
traced down and fixed. With V8 we don't have that chance (as far as I
understand).

> About QtWebEngine, do you know what system libraries you have problems with
> it duplicating? I think we can configure most of it in the build system and
> already follow the Qt build settings for some that are usually shipped with
> Chromium.

The real answer is simple: all of them. We do our best to avoid embedded
libraries (and yes, we sometimes fail to do it, and that's a bug for us).

If I where to start at some place I would choose V8 and ffmpeg, but the real
thing is simply all of them.

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Kevin Kofler
2015-02-09 21:40:00 UTC
Permalink
Lisandro Damián Nicanor Pérez Meyer wrote:
> The real answer is simple: all of them. We do our best to avoid embedded
> libraries (and yes, we sometimes fail to do it, and that's a bug for us).

+1, same here (Fedora).

> If I where to start at some place I would choose V8 and ffmpeg, but the
> real thing is simply all of them.

Those 2 would better be replaced altogether than just unbundled… (V8 because
it is not portable, FFmpeg because it is monolithic and so we cannot ship it
in a way where the patent-encumbered codecs can be added from a third-party
repository, the codecs to include are a compile-time decision.)

Kevin Kofler
André Somers
2015-02-06 07:42:53 UTC
Permalink
Knoll Lars schreef op 5-2-2015 om 16:28:
> But we don’t have much of a choice, if we want to deliver an up to date
> web engine.
Perhaps it is time to ask the question then: do we want to do that? Do
we really need to?

It seems to me, that it isn't really possible to do. Not in a way that
doesn't require huge effort in support or pissing off everybody not on
one of the large main stream platforms. And the question might be: why
should Qt deliver an up-to-date web engine exactly? Do we really think
that people are going to use Qt to build advanced browsers? Sure, some
might (KDE comes to mind...), but you are right in your observation that
the technology is moving too fast and is developed between giants like
Google, Apple and Microsoft who could not care less about other uses or
other platforms than their own.

All the while Qt is spending effort to catch up, deprecating compilers
and platforms because they can't take the latest Javascript engine to
it, users are hapily using browers like Firefox and Chrome.

Perhaps it is time to conclude that Qt just can't compete in this race
if it doesn't want to be crushed between the giants playing this field.
Perhaps it is just time to settle for indeed a simpler goal: don't try
to provide a fully integrated full-fledged web engine, but instead
settle once again for a simpler alternative that we _can_ support and
that can be used for things like showing embedded help or showing simple
sites, and perhaps an API to wrap and embed the native web view provided
by the platform but with limited integration.

André
Knoll Lars
2015-02-06 08:14:07 UTC
Permalink
On 06/02/15 08:42, "André Somers" <***@familiesomers.nl> wrote:

>Knoll Lars schreef op 5-2-2015 om 16:28:
>> But we don’t have much of a choice, if we want to deliver an up to date
>> web engine.
>Perhaps it is time to ask the question then: do we want to do that? Do
>we really need to?

If you ask me as a Chief Maintainer of the Qt project, I’d say: Why not as
long as someone makes it happen. If you ask me as the CTO of TQtC, I’ll
answer: Hell yes, we need it in the product to be competitive, especially
on embedded.

>It seems to me, that it isn't really possible to do. Not in a way that
>doesn't require huge effort in support or pissing off everybody not on
>one of the large main stream platforms. And the question might be: why
>should Qt deliver an up-to-date web engine exactly? Do we really think
>that people are going to use Qt to build advanced browsers? Sure, some
>might (KDE comes to mind...), but you are right in your observation that
>the technology is moving too fast and is developed between giants like
>Google, Apple and Microsoft who could not care less about other uses or
>other platforms than their own.
>
>All the while Qt is spending effort to catch up, deprecating compilers
>and platforms because they can't take the latest Javascript engine to
>it, users are hapily using browers like Firefox and Chrome.

Well, with Qt WebEngine we can actually keep up. That was the whole point
of doing that change from WebKit. But yes, we can’t support it on a 10
year old compiler. But Qt is not about a least common denominator
solution. We can and have to offer up to date things on newer OSes.

>Perhaps it is time to conclude that Qt just can't compete in this race
>if it doesn't want to be crushed between the giants playing this field.
>Perhaps it is just time to settle for indeed a simpler goal: don't try
>to provide a fully integrated full-fledged web engine, but instead
>settle once again for a simpler alternative that we _can_ support and
>that can be used for things like showing embedded help or showing simple
>sites, and perhaps an API to wrap and embed the native web view provided
>by the platform but with limited integration.

We are currently developing that simpler solution as well. It’s called Qt
WebView and embeds the native web engine of the underlying platform.
Unfortunately most OSes have different limitations as to how you can
embed, making something that works well on all platforms very hard. Not to
even mention that there is no native component to embed available on
Linux. So far *we* have been that component.

We will continue to need a web engine, and there is a huge amount of
customer interest and need for it. Especially on the embedded side.

I understand the concern of the Linux distributions. But they are only one
part of the picture. Even though Qt has a very special position inside the
Linux stack, it is used much more broadly.

We can try to find solutions that work for the Linux distributions, but
we’ve always had this kind of problems (even though there probably weren’t
as extreme as with chromium).

Cheers,
Lars
Simon Hausmann
2015-02-06 08:21:51 UTC
Permalink
On Friday 6. February 2015 08.42.53 André Somers wrote:
> Knoll Lars schreef op 5-2-2015 om 16:28:
> > But we don’t have much of a choice, if we want to deliver an up to date
> > web engine.
>
> Perhaps it is time to ask the question then: do we want to do that? Do
> we really need to?
>
> It seems to me, that it isn't really possible to do. Not in a way that
> doesn't require huge effort in support or pissing off everybody not on
> one of the large main stream platforms. And the question might be: why
> should Qt deliver an up-to-date web engine exactly? Do we really think
> that people are going to use Qt to build advanced browsers? Sure, some
> might (KDE comes to mind...), but you are right in your observation that
> the technology is moving too fast and is developed between giants like
> Google, Apple and Microsoft who could not care less about other uses or
> other platforms than their own.
>
> All the while Qt is spending effort to catch up, deprecating compilers
> and platforms because they can't take the latest Javascript engine to
> it, users are hapily using browers like Firefox and Chrome.
>
> Perhaps it is time to conclude that Qt just can't compete in this race
> if it doesn't want to be crushed between the giants playing this field.
> Perhaps it is just time to settle for indeed a simpler goal: don't try
> to provide a fully integrated full-fledged web engine, but instead
> settle once again for a simpler alternative that we _can_ support and
> that can be used for things like showing embedded help or showing simple
> sites, and perhaps an API to wrap and embed the native web view provided
> by the platform but with limited integration.

What simpler alternative do you have in mind?

This "catch up" race is _exactly_ the reason why we decided to build on top of
Chromium and don't look at it as just a "HTML/CSS renderer" anymore but as an
entire platform. Unfortunately that means the platform is wide and comes with
a lot of code, fortunately it almost entirely eliminates the "catch up" race.

And yes, there is a surprising interest among the users of Qt to use an up-to-
date implementation of the web platform in their Qt application. Not
necessarily to build a web browser that competes with Chrome, Safari and the
lot.


Simon
Ziller Eike
2015-02-06 08:32:38 UTC
Permalink
> On Feb 6, 2015, at 09:21, Simon Hausmann <***@theqtcompany.com> wrote:
>
> On Friday 6. February 2015 08.42.53 André Somers wrote:
>> Knoll Lars schreef op 5-2-2015 om 16:28:
>>> But we don’t have much of a choice, if we want to deliver an up to date
>>> web engine.
>>
>> Perhaps it is time to ask the question then: do we want to do that? Do
>> we really need to?
>>
>> It seems to me, that it isn't really possible to do. Not in a way that
>> doesn't require huge effort in support or pissing off everybody not on
>> one of the large main stream platforms. And the question might be: why
>> should Qt deliver an up-to-date web engine exactly? Do we really think
>> that people are going to use Qt to build advanced browsers? Sure, some
>> might (KDE comes to mind...), but you are right in your observation that
>> the technology is moving too fast and is developed between giants like
>> Google, Apple and Microsoft who could not care less about other uses or
>> other platforms than their own.
>>
>> All the while Qt is spending effort to catch up, deprecating compilers
>> and platforms because they can't take the latest Javascript engine to
>> it, users are hapily using browers like Firefox and Chrome.
>>
>> Perhaps it is time to conclude that Qt just can't compete in this race
>> if it doesn't want to be crushed between the giants playing this field.
>> Perhaps it is just time to settle for indeed a simpler goal: don't try
>> to provide a fully integrated full-fledged web engine, but instead
>> settle once again for a simpler alternative that we _can_ support and
>> that can be used for things like showing embedded help or showing simple
>> sites, and perhaps an API to wrap and embed the native web view provided
>> by the platform but with limited integration.
>
> What simpler alternative do you have in mind?

One possibility that would cover the use case of “show some simple styled html without javascript” case (e.g. documentation browsers) would be to give QTextBrowser some love again, fix some bugs there, and extend some of the css and html features in it. That definitely would be “offline first”, except that anyone who cares could of course fetch content from the web for it (the text browser based help viewer backend in Qt Creator also fetches content from the help database, so that already works fine ;) )

> This "catch up" race is _exactly_ the reason why we decided to build on top of
> Chromium and don't look at it as just a "HTML/CSS renderer" anymore but as an
> entire platform. Unfortunately that means the platform is wide and comes with
> a lot of code, fortunately it almost entirely eliminates the "catch up" race.
>
> And yes, there is a surprising interest among the users of Qt to use an up-to-
> date implementation of the web platform in their Qt application. Not
> necessarily to build a web browser that competes with Chrome, Safari and the
> lot.
>
>
> Simon
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Eike Ziller, Senior Software Engineer | The Qt Company
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
Sorvig Morten
2015-02-06 09:38:22 UTC
Permalink
> On 06 Feb 2015, at 09:32, Ziller Eike <***@theqtcompany.com> wrote:
>
>>
>> What simpler alternative do you have in mind?
>
> One possibility that would cover the use case of “show some simple styled html without javascript” case (e.g. documentation browsers) would be to give QTextBrowser some love again, fix some bugs there, and extend some of the css and html features in it. That definitely would be “offline first”, except that anyone who cares could of course fetch content from the web for it (the text browser based help viewer backend in Qt Creator also fetches content from the help database, so that already works fine ;) )

Another alternative in the “documentation browser” space is to develop a Qt backend for a project like litehtml.

Morten

litehtml: https://github.com/litehtml/litehtml
Alejandro Exojo
2015-02-06 08:28:15 UTC
Permalink
El Friday 06 February 2015, André Somers escribió:
> All the while Qt is spending effort to catch up, deprecating compilers
> and platforms because they can't take the latest Javascript engine to
> it, users are hapily using browers like Firefox and Chrome.
>
> Perhaps it is time to conclude that Qt just can't compete in this race
> if it doesn't want to be crushed between the giants playing this field.
> Perhaps it is just time to settle for indeed a simpler goal: don't try
> to provide a fully integrated full-fledged web engine, but instead
> settle once again for a simpler alternative that we can support and
> that can be used for things like showing embedded help or showing simple
> sites, and perhaps an API to wrap and embed the native web view provided
> by the platform but with limited integration.

This is a thought that I had several times when reading about the QtWebEngine.
I understand, though, that the customers that The Qt Company is trying to
appeal might not have a problem with bundling lots of libraries. Deploying to
Windows, Mac (or mobile, even though here WebEngine not applies there) already
means bundling lots of libraries with your application.

We all know how web browsers have changed. From reasonable applications
capable of fetching a file through a simple one way protocol, and displaying a
mostly static multimedia content, to huge beasts that require lots of complex
network (websockets, WebRTC), multimedia, graphics, devices, storage, etc.

Kevin said "Relying on Chromium is a horrible idea", but non-horrible
solutions probably won't exist anymore if you add a web browser into the mix.
You probably will have to surrender to what the upstream team that developed
the browser left you. And there aren't that many upstreams.

Speaking of that...

What about Gecko? Is the license a problem? Or is still a technical reason?

Because a long term possibility would be to team up with people in GNOME or
KDE who might need a web browser engine, and speak with Mozilla to help. After
all they are supposed to be a non-profit, so collaborating with other open
source projects should be in their DNA. It's not like their XUL has much use
outside their projects, so having some Qt and GTK+ integration and more users
of their technologies should be good for their mindshare.

Here are some notes on the patches that Sailfish Browser needs to embed Gecko:

http://blog.idempotent.info/posts/whats-behind-sailfish-browser.html

--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net
Bernhard
2015-02-06 11:37:13 UTC
Permalink
I consider a fully functional web engine component a very important piece of Qt.
Easily embedding a website into a desktop application is extremely useful. Example applications are scrapers and website analysis tools. But there are a LOT more applications. Also more common ones.

If the choice is dropping the web engine component or dropping old compilers I wouldn't need to think a second about the decision.

--
Kind Regards
Bernhard Lindner

> -----Ursprüngliche Nachricht-----
> Von: development-bounces+private=bernhard-***@qt-project.org
> [mailto:development-bounces+private=bernhard-***@qt-
> project.org] Im Auftrag von André Somers
> Gesendet: Freitag, 6. Februar 2015 08:43
> An: ***@qt-project.org
> Betreff: Re: [Development] Deprecating modules with 5.5
>
> Knoll Lars schreef op 5-2-2015 om 16:28:
> > But we don’t have much of a choice, if we want to deliver an up to
> > date web engine.
> Perhaps it is time to ask the question then: do we want to do that? Do we
> really need to?
>
> It seems to me, that it isn't really possible to do. Not in a way that doesn't
> require huge effort in support or pissing off everybody not on one of the
> large main stream platforms. And the question might be: why should Qt
> deliver an up-to-date web engine exactly? Do we really think that people are
> going to use Qt to build advanced browsers? Sure, some might (KDE comes
> to mind...), but you are right in your observation that the technology is
> moving too fast and is developed between giants like Google, Apple and
> Microsoft who could not care less about other uses or other platforms than
> their own.
>
> All the while Qt is spending effort to catch up, deprecating compilers and
> platforms because they can't take the latest Javascript engine to it, users are
> hapily using browers like Firefox and Chrome.
>
> Perhaps it is time to conclude that Qt just can't compete in this race if it
> doesn't want to be crushed between the giants playing this field.
> Perhaps it is just time to settle for indeed a simpler goal: don't try to provide
> a fully integrated full-fledged web engine, but instead settle once again for a
> simpler alternative that we _can_ support and that can be used for things like
> showing embedded help or showing simple sites, and perhaps an API to
> wrap and embed the native web view provided by the platform but with
> limited integration.
>
> André
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Olivier Goffart
2015-02-04 09:20:43 UTC
Permalink
On Tuesday 03 February 2015 07:33:46 Knoll Lars wrote:
> Hi,
>
> I’d like to mark a few modules as deprecated with 5.5, and most likely
> remove them from the binary packages with 5.6. These modules are:
>
> * Qt WebKit
> * Qt Declarative (Qt Quick 1)
> * Qt Script
>
> All of these modules are by now a couple of years old, don’t receive
> updates above the bare minimum and have a replacement that is actively
> being developed in Qt 5.


Also, is it not time to decide which platform are we going to stop supporting
in Qt 5.6?

For example, if we were to decide to start using some of the C++11, we should
drop MSVC 2008 which would allow us to already use things like auto and
decltype.
We could also drop gcc 4.4 which would let us lambda function.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
Knoll Lars
2015-02-04 09:23:12 UTC
Permalink
On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:

>On Tuesday 03 February 2015 07:33:46 Knoll Lars wrote:
>> Hi,
>>
>> I’d like to mark a few modules as deprecated with 5.5, and most likely
>> remove them from the binary packages with 5.6. These modules are:
>>
>> * Qt WebKit
>> * Qt Declarative (Qt Quick 1)
>> * Qt Script
>>
>> All of these modules are by now a couple of years old, don’t receive
>> updates above the bare minimum and have a replacement that is actively
>> being developed in Qt 5.
>
>
>Also, is it not time to decide which platform are we going to stop
>supporting
>in Qt 5.6?
>
>For example, if we were to decide to start using some of the C++11, we
>should
>drop MSVC 2008 which would allow us to already use things like auto and
>decltype.
>We could also drop gcc 4.4 which would let us lambda function.

In principle I agree. The problem with 2008 is that this is currently the
only compiler supporting Windows Embedded 7, so we can’t easily get rid of
it. Dropping gcc 4.4 is afaik not a big problem.

Cheers,
Lars
Olivier Goffart
2015-02-04 14:56:41 UTC
Permalink
On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:

> >Also, is it not time to decide which platform are we going to stop
> >supporting in Qt 5.6?
> >
> >For example, if we were to decide to start using some of the C++11, we
> >should drop MSVC 2008 which would allow us to already use things like auto
> >and decltype.
> >We could also drop gcc 4.4 which would let us lambda function.
>
>
> In principle I agree. The problem with 2008 is that this is currently the
> only compiler supporting Windows Embedded 7, so we can’t easily get rid of
> it. Dropping gcc 4.4 is afaik not a big problem.

The question then is how relevant will Windows Embedded 7 be in 2016 when Qt
5.6 will be there. And if it is worth to limit ourselves because of it.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
Bo Thorsen
2015-02-05 07:31:24 UTC
Permalink
Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
>> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:
>>> Also, is it not time to decide which platform are we going to stop
>>> supporting in Qt 5.6?
>>>
>>> For example, if we were to decide to start using some of the C++11, we
>>> should drop MSVC 2008 which would allow us to already use things like auto
>>> and decltype.
>>> We could also drop gcc 4.4 which would let us lambda function.
>>
>> In principle I agree. The problem with 2008 is that this is currently the
>> only compiler supporting Windows Embedded 7, so we can’t easily get rid of
>> it. Dropping gcc 4.4 is afaik not a big problem.
> The question then is how relevant will Windows Embedded 7 be in 2016 when Qt
> 5.6 will be there. And if it is worth to limit ourselves because of it.

Sounds to me like 5.5 will be a release that will be around for a while
then. This could be the one where those who need webkit, VS 2008 og Qt
Quick 1 would use. So declaring support for this will continue for a
while could make it easier to remove those parts.

If this could be the case, it could even be considered to go even
further and get rid of more stuff. VS 2010 would be one possibility. I'm
writing this with VS 2010 open for the project I'm currently on, so I
know it's still in use :) But getting rid of this opens for a lot more
C++11 features.

What I'm suggesting here is sort of a mini major release. It doesn't
feel like a 6.0 is necessary yet, but as the 5 line is mayby around half
through it's life, it might not be a bad idea to make a longer term release.

Bo.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
Turunen Tuukka
2015-02-05 08:04:38 UTC
Permalink
On 05/02/15 09:31, "Bo Thorsen" <***@vikingsoft.eu> wrote:

>Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
>> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
>>> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:
>>>> Also, is it not time to decide which platform are we going to stop
>>>> supporting in Qt 5.6?
>>>>
>>>> For example, if we were to decide to start using some of the C++11, we
>>>> should drop MSVC 2008 which would allow us to already use things like
>>>>auto
>>>> and decltype.
>>>> We could also drop gcc 4.4 which would let us lambda function.
>>>
>>> In principle I agree. The problem with 2008 is that this is currently
>>>the
>>> only compiler supporting Windows Embedded 7, so we can¹t easily get
>>>rid of
>>> it. Dropping gcc 4.4 is afaik not a big problem.
>> The question then is how relevant will Windows Embedded 7 be in 2016
>>when Qt
>> 5.6 will be there. And if it is worth to limit ourselves because of it.
>
>Sounds to me like 5.5 will be a release that will be around for a while
>then. This could be the one where those who need webkit, VS 2008 og Qt
>Quick 1 would use. So declaring support for this will continue for a
>while could make it easier to remove those parts.
>
>If this could be the case, it could even be considered to go even
>further and get rid of more stuff. VS 2010 would be one possibility. I'm
>writing this with VS 2010 open for the project I'm currently on, so I
>know it's still in use :) But getting rid of this opens for a lot more
>C++11 features.
>
>What I'm suggesting here is sort of a mini major release. It doesn't
>feel like a 6.0 is necessary yet, but as the 5 line is mayby around half
>through it's life, it might not be a bad idea to make a longer term
>release.

This has been discussed also earlier and as such Qt 5.5 would probably be
a good candidate for being supported longer than previous Qt 5 releases.

In a way Qt 4.8 is a LTS as it has received many patch level releases
during it¹s lifetime and we have also extended the standard support of it.

Even if Qt 5.5 would not be around as long as Qt 4.8 will, we are
preparing to be better able to provide patch releases for it also after Qt
5.6 is available. These mainly include modifications and improvements to
the CI system and virtualization platform.

That said, there are many things to define, decide and business wise plan
related to LTS releases. But preparation to enable are proceeding well and
thus it is technically more feasible for Qt 5.5 than before.

Yours,

Tuukka


>
>Bo.
>
>--
>Viking Software
>Qt and C++ developers for hire
>http://www.vikingsoft.eu
>
>_______________________________________________
>Development mailing list
>***@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
Henry Skoglund
2015-02-05 08:07:12 UTC
Permalink
+1 for dropping VS2008. For those with thin wallets it's easier to
upgrade nowadays anyway to the VS2013 Community Edition.

/Rgrds Henry


On 2015-02-05 08:31, Bo Thorsen wrote:
> Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
>> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
>>> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:
>>>> Also, is it not time to decide which platform are we going to stop
>>>> supporting in Qt 5.6?
>>>>
>>>> For example, if we were to decide to start using some of the C++11, we
>>>> should drop MSVC 2008 which would allow us to already use things like auto
>>>> and decltype.
>>>> We could also drop gcc 4.4 which would let us lambda function.
>>>
>>> In principle I agree. The problem with 2008 is that this is currently the
>>> only compiler supporting Windows Embedded 7, so we can’t easily get rid of
>>> it. Dropping gcc 4.4 is afaik not a big problem.
>> The question then is how relevant will Windows Embedded 7 be in 2016 when Qt
>> 5.6 will be there. And if it is worth to limit ourselves because of it.
>
> Sounds to me like 5.5 will be a release that will be around for a while
> then. This could be the one where those who need webkit, VS 2008 og Qt
> Quick 1 would use. So declaring support for this will continue for a
> while could make it easier to remove those parts.
>
> If this could be the case, it could even be considered to go even
> further and get rid of more stuff. VS 2010 would be one possibility. I'm
> writing this with VS 2010 open for the project I'm currently on, so I
> know it's still in use :) But getting rid of this opens for a lot more
> C++11 features.
>
> What I'm suggesting here is sort of a mini major release. It doesn't
> feel like a 6.0 is necessary yet, but as the 5 line is mayby around half
> through it's life, it might not be a bad idea to make a longer term release.
>
> Bo.
>
Dr. Nico Wallmeier
2015-02-05 08:29:02 UTC
Permalink
Hello,

please keep in mind that in the enterprise environment Windows CE /
Windows Embedded Compact is still an important platform!

Kind regards,
Nico Wallmeier

> +1 for dropping VS2008. For those with thin wallets it's easier to
> upgrade nowadays anyway to the VS2013 Community Edition.
>
> /Rgrds Henry
>
>
> On 2015-02-05 08:31, Bo Thorsen wrote:
>> Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
>>> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
>>>> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:
>>>>> Also, is it not time to decide which platform are we going to stop
>>>>> supporting in Qt 5.6?
>>>>>
>>>>> For example, if we were to decide to start using some of the C++11, we
>>>>> should drop MSVC 2008 which would allow us to already use things like auto
>>>>> and decltype.
>>>>> We could also drop gcc 4.4 which would let us lambda function.
>>>>
>>>> In principle I agree. The problem with 2008 is that this is currently the
>>>> only compiler supporting Windows Embedded 7, so we can’t easily get rid of
>>>> it. Dropping gcc 4.4 is afaik not a big problem.
>>> The question then is how relevant will Windows Embedded 7 be in 2016 when Qt
>>> 5.6 will be there. And if it is worth to limit ourselves because of it.
>>
>> Sounds to me like 5.5 will be a release that will be around for a while
>> then. This could be the one where those who need webkit, VS 2008 og Qt
>> Quick 1 would use. So declaring support for this will continue for a
>> while could make it easier to remove those parts.
>>
>> If this could be the case, it could even be considered to go even
>> further and get rid of more stuff. VS 2010 would be one possibility. I'm
>> writing this with VS 2010 open for the project I'm currently on, so I
>> know it's still in use :) But getting rid of this opens for a lot more
>> C++11 features.
>>
>> What I'm suggesting here is sort of a mini major release. It doesn't
>> feel like a 6.0 is necessary yet, but as the 5 line is mayby around half
>> through it's life, it might not be a bad idea to make a longer term release.
>>
>> Bo.
>>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Olivier Goffart
2015-02-08 08:57:21 UTC
Permalink
On Thursday 05 February 2015 09:29:02 Dr. Nico Wallmeier wrote:
> Hello,
>
> please keep in mind that in the enterprise environment Windows CE /
> Windows Embedded Compact is still an important platform!

I understand that, but to which point?
Mac OS X 10.6 was also an important platform used by about 10% of the mac
users. Yet, we decided to drop support for it.

The question is how relevant it will be in 2016? Will there be so many users
that really can't upgrade to the next windows, and that are not willing to
stay with Qt 5.5? Are those buying enough licenses to compensate for the
effort of supporting them.

It would be nice to have some data to help to take a decision.

Personally, I know that MSVC 2008 causes me troubles with
https://codereview.qt-project.org/98658/ , it does not pass CI with 2008 and i
have not idea why.
Having the possibility to use decltype would simplify some the
QObject::connect code.
Some upstream projects such as chromium does not support this platform
anymore.

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
Dr. Nico Wallmeier
2015-02-08 12:41:59 UTC
Permalink
>> please keep in mind that in the enterprise environment Windows CE /
>> Windows Embedded Compact is still an important platform!
>
> I understand that, but to which point?
> Mac OS X 10.6 was also an important platform used by about 10% of the mac
> users. Yet, we decided to drop support for it.
>
> The question is how relevant it will be in 2016? Will there be so many users
> that really can't upgrade to the next windows, and that are not willing to
> stay with Qt 5.5? Are those buying enough licenses to compensate for the
> effort of supporting them.

In the enterprise environment these devices are shipped with a specific
Windows CE / Embedded Compact and stay on this version up to EOL.
Normally it is not possible update these units to newer OS versions
(only patch updates may be available) - the situation there is not
comparable with a desktop environment. Windows Embedded Compact 7 can
still be found e.g. on Motorola devices, which are introduced in the
last year, like the MC3290 or MC9290...

Kind regards,
Nico Wallmeier
Thiago Macieira
2015-02-08 16:58:11 UTC
Permalink
On Sunday 08 February 2015 13:41:59 Dr. Nico Wallmeier wrote:
> In the enterprise environment these devices are shipped with a specific
> Windows CE / Embedded Compact and stay on this version up to EOL.
> Normally it is not possible update these units to newer OS versions
> (only patch updates may be available) - the situation there is not
> comparable with a desktop environment. Windows Embedded Compact 7 can
> still be found e.g. on Motorola devices, which are introduced in the
> last year, like the MC3290 or MC9290...

So we come back to this question again and again: if you can't upgrade the OS
and upgrade the compiler, why do you want to upgrade Qt?

Let's make one LTS release of Qt and then drop those old compilers.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Giuseppe D'Angelo
2015-02-08 18:15:18 UTC
Permalink
Il 08/02/2015 17:58, Thiago Macieira ha scritto:
> So we come back to this question again and again: if you can't upgrade the OS
> and upgrade the compiler, why do you want to upgrade Qt?

Because people want to use the latest features / bugfixes for developing
their product, and yet they need to target such platforms...

--
Giuseppe D'Angelo | ***@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Thiago Macieira
2015-02-08 18:25:51 UTC
Permalink
On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote:
> Il 08/02/2015 17:58, Thiago Macieira ha scritto:
> > So we come back to this question again and again: if you can't upgrade the
> > OS and upgrade the compiler, why do you want to upgrade Qt?
>
> Because people want to use the latest features / bugfixes for developing
> their product, and yet they need to target such platforms...

Indeed, but that is putting the burden on us. They should instead insist with
their vendors to get a newer platform and put the burden on them. Or next
time, make sure you use a device that can run Linux so you can easily rebuild
with Yocto -- every 6 months you get a new toolchain and sysroot with the
latest updates. I'm going to say that if you chose a vendor that won't
upgrade, it's your fault and you should live with the consequences.

Anyway, every time this comes up, the answer is the same: we will drop those
platforms once they become too much of a burden to support and prevent us from
doing new things. That's why OS X 10.6 went away.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Björn Breitmeyer
2015-02-09 08:26:53 UTC
Permalink
Well start with the easiest understanable reasons. People come from old
platforms whith old applications and they don't know what their upcoming
hardware platforms will be, so they decide why not go to Qt first and then
decide, which platform is usable for us. Thats a pretty common theme and if
you stop supporting the old platforms you likely won't get those customers.
Besides its something were you can earn money.

Putting pressure on a vendor is in most cases not achieving much. Even really
really big companies are screwed if some important vendor in their stack isn't
getting their job done, its one of the reasons why the chosen hardware is most
likely not bleeding edge, as there are timeframes to meet until product
release.

Then there are industries which need certified operating systems for their
field, they don't have the option to use the newest yocto and if they decided
to use one kind of os the certification process most likely binds them to this
os for the complete product lifetime.

So yes they are putting the burden on us, because they can't reliably put them
somewhere else. You might ask why should we take the burden, because those
companies are paying quite a bit of money too get what they need if it
actually helps.

And yes of course we would like to use newer compiler versions, but in most
cases with the option c++11 support how much extra pain do we have? Embedded
is just not like desktop that even goes for gcc on linux.

--
Björn Breitmeyer | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Am Sonntag, 8. Februar 2015, 10:25:51 schrieb Thiago Macieira:
> On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote:
> > Il 08/02/2015 17:58, Thiago Macieira ha scritto:
> > > So we come back to this question again and again: if you can't upgrade
> > > the
> > > OS and upgrade the compiler, why do you want to upgrade Qt?
> >
> > Because people want to use the latest features / bugfixes for developing
> > their product, and yet they need to target such platforms...
>
> Indeed, but that is putting the burden on us. They should instead insist
> with their vendors to get a newer platform and put the burden on them. Or
> next time, make sure you use a device that can run Linux so you can easily
> rebuild with Yocto -- every 6 months you get a new toolchain and sysroot
> with the latest updates. I'm going to say that if you chose a vendor that
> won't upgrade, it's your fault and you should live with the consequences.
>
> Anyway, every time this comes up, the answer is the same: we will drop those
> platforms once they become too much of a burden to support and prevent us
> from doing new things. That's why OS X 10.6 went away.
Olivier Goffart
2015-02-08 20:25:31 UTC
Permalink
On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote:
> Il 08/02/2015 17:58, Thiago Macieira ha scritto:
> > So we come back to this question again and again: if you can't upgrade the
> > OS and upgrade the compiler, why do you want to upgrade Qt?
>
> Because people want to use the latest features / bugfixes for developing
> their product, and yet they need to target such platforms...

If Qt 5.5 is LTS, some bugs fixes could be backported.
As for the new feature, if they can cope with an old system and compiler, they
can also cope with old Qt. Even if that implies re-inventing a few wheels.

So the question is:
If we were to drop MSVC2008, about how many companies or developers do you
think will choose not to use Qt because of that instead of using it?

Is there perhaps a lot of paying customer using it who would stop paying
licenses?

When is the end of life of Windows CE?

--
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
Gunnar Roth
2015-02-08 20:51:50 UTC
Permalink
> Am 08.02.2015 um 21:25 schrieb Olivier Goffart <***@woboq.com>:
>
> On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote:
>> Il 08/02/2015 17:58, Thiago Macieira ha scritto:
>>> So we come back to this question again and again: if you can't upgrade the
>>> OS and upgrade the compiler, why do you want to upgrade Qt?
>>
>> Because people want to use the latest features / bugfixes for developing
>> their product, and yet they need to target such platforms...
>
> If Qt 5.5 is LTS, some bugs fixes could be backported.
> As for the new feature, if they can cope with an old system and compiler, they
> can also cope with old Qt. Even if that implies re-inventing a few wheels.
>
> So the question is:
> If we were to drop MSVC2008, about how many companies or developers do you
> think will choose not to use Qt because of that instead of using it?
>
> Is there perhaps a lot of paying customer using it who would stop paying
> licenses?
>
> When is the end of life of Windows CE?

Hi all,

According to http://www.microsoft.com/windowsembedded/en-us/product-lifecycles.aspx
MS does support WEC 7 until April 13, 2021, which is more than 6 six years.
But dropping wec 7 support would mean dropping complete ce support as the successor wec2013 is not supported by qt and qt 5.x needs quite some patches to build ( and building things like quick controls need some hacky patches, as it depends on accessibility.)

Wec2013 is using a prerelease forked version of 17.00 Compiler (as used in vs 2012) compile OS and applications.
The support runs till October 10, 2023.
MS is actually fixing bugs in this compiler (which is delivered with wec 2013) and has done so on our request ( i remember some optimisation internal compiler error when building qtwebkit from qt 4.8.5)

We are using qt 4.8.x on ce 6 and wec 2013 and we use qt 5.4 on wec2013. We skipped wec 7 so being able to use newer c++ compiler features but in hindsight it was a pain, so i understand that many people stick with wec 7.


Regards,
Gunnar
Bo Thorsen
2015-02-09 07:24:49 UTC
Permalink
Den 08-02-2015 kl. 21:25 skrev Olivier Goffart:
> On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote:
>> Il 08/02/2015 17:58, Thiago Macieira ha scritto:
>>> So we come back to this question again and again: if you can't upgrade the
>>> OS and upgrade the compiler, why do you want to upgrade Qt?
>>
>> Because people want to use the latest features / bugfixes for developing
>> their product, and yet they need to target such platforms...
>
> If Qt 5.5 is LTS, some bugs fixes could be backported.
> As for the new feature, if they can cope with an old system and compiler, they
> can also cope with old Qt. Even if that implies re-inventing a few wheels.
>
> So the question is:
> If we were to drop MSVC2008, about how many companies or developers do you
> think will choose not to use Qt because of that instead of using it?
>
> Is there perhaps a lot of paying customer using it who would stop paying
> licenses?

With a 5.5, LTS TQtC could have a reason for potential customers to
start buying licenses. WinCE, MSVC2008, maybe a couple of others. If
customers need this for a bugfixed Qt, buy the licenses.

I think it would be perfect, if we could find a way to proceed that
could support the business of TQtC.

Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
Björn Breitmeyer
2015-02-05 08:32:24 UTC
Permalink
This would be the same as dropping the Windows Embedded Compact support.
So its a clear no from my side.

--
Björn Breitmeyer | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Am Donnerstag, 5. Februar 2015, 09:07:12 schrieb Henry Skoglund:
> +1 for dropping VS2008. For those with thin wallets it's easier to
> upgrade nowadays anyway to the VS2013 Community Edition.
>
> /Rgrds Henry
>
> On 2015-02-05 08:31, Bo Thorsen wrote:
> > Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
> >> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
> >>> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:
> >>>> Also, is it not time to decide which platform are we going to stop
> >>>> supporting in Qt 5.6?
> >>>>
> >>>> For example, if we were to decide to start using some of the C++11, we
> >>>> should drop MSVC 2008 which would allow us to already use things like
> >>>> auto
> >>>> and decltype.
> >>>> We could also drop gcc 4.4 which would let us lambda function.
> >>>
> >>> In principle I agree. The problem with 2008 is that this is currently
> >>> the
> >>> only compiler supporting Windows Embedded 7, so we can’t easily get rid
> >>> of
> >>> it. Dropping gcc 4.4 is afaik not a big problem.
> >>
> >> The question then is how relevant will Windows Embedded 7 be in 2016 when
> >> Qt 5.6 will be there. And if it is worth to limit ourselves because of
> >> it.>
> > Sounds to me like 5.5 will be a release that will be around for a while
> > then. This could be the one where those who need webkit, VS 2008 og Qt
> > Quick 1 would use. So declaring support for this will continue for a
> > while could make it easier to remove those parts.
> >
> > If this could be the case, it could even be considered to go even
> > further and get rid of more stuff. VS 2010 would be one possibility. I'm
> > writing this with VS 2010 open for the project I'm currently on, so I
> > know it's still in use :) But getting rid of this opens for a lot more
> > C++11 features.
> >
> > What I'm suggesting here is sort of a mini major release. It doesn't
> > feel like a 6.0 is necessary yet, but as the 5 line is mayby around half
> > through it's life, it might not be a bad idea to make a longer term
> > release.
> >
> > Bo.
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Knoll Lars
2015-02-05 08:48:20 UTC
Permalink
Yes, it’s not possible to drop 2008 currently without dropping Windows
Embedded support. So not something we can do until we have a solution for
Windows Embedded.

Cheers,
Lars

On 05/02/15 09:32, "Björn Breitmeyer" <***@kdab.com> wrote:

>This would be the same as dropping the Windows Embedded Compact support.
>So its a clear no from my side.
>
>--
>Björn Breitmeyer | ***@kdab.com | Software Engineer
>KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
>Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
>KDAB - Qt Experts - Platform-independent software solutions
>Am Donnerstag, 5. Februar 2015, 09:07:12 schrieb Henry Skoglund:
>> +1 for dropping VS2008. For those with thin wallets it's easier to
>> upgrade nowadays anyway to the VS2013 Community Edition.
>>
>> /Rgrds Henry
>>
>> On 2015-02-05 08:31, Bo Thorsen wrote:
>> > Den 04-02-2015 kl. 15:56 skrev Olivier Goffart:
>> >> On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote:
>> >>> On 04/02/15 10:20, "Olivier Goffart" <***@woboq.com> wrote:
>> >>>> Also, is it not time to decide which platform are we going to stop
>> >>>> supporting in Qt 5.6?
>> >>>>
>> >>>> For example, if we were to decide to start using some of the
>>C++11, we
>> >>>> should drop MSVC 2008 which would allow us to already use things
>>like
>> >>>> auto
>> >>>> and decltype.
>> >>>> We could also drop gcc 4.4 which would let us lambda function.
>> >>>
>> >>> In principle I agree. The problem with 2008 is that this is
>>currently
>> >>> the
>> >>> only compiler supporting Windows Embedded 7, so we can’t easily get
>>rid
>> >>> of
>> >>> it. Dropping gcc 4.4 is afaik not a big problem.
>> >>
>> >> The question then is how relevant will Windows Embedded 7 be in 2016
>>when
>> >> Qt 5.6 will be there. And if it is worth to limit ourselves because
>>of
>> >> it.>
>> > Sounds to me like 5.5 will be a release that will be around for a
>>while
>> > then. This could be the one where those who need webkit, VS 2008 og Qt
>> > Quick 1 would use. So declaring support for this will continue for a
>> > while could make it easier to remove those parts.
>> >
>> > If this could be the case, it could even be considered to go even
>> > further and get rid of more stuff. VS 2010 would be one possibility.
>>I'm
>> > writing this with VS 2010 open for the project I'm currently on, so I
>> > know it's still in use :) But getting rid of this opens for a lot more
>> > C++11 features.
>> >
>> > What I'm suggesting here is sort of a mini major release. It doesn't
>> > feel like a 6.0 is necessary yet, but as the 5 line is mayby around
>>half
>> > through it's life, it might not be a bad idea to make a longer term
>> > release.
>> >
>> > Bo.
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
Thiago Macieira
2015-02-05 16:08:59 UTC
Permalink
On Thursday 05 February 2015 08:48:20 Knoll Lars wrote:
> Yes, it’s not possible to drop 2008 currently without dropping Windows
> Embedded support. So not something we can do until we have a solution for
> Windows Embedded.

Microsoft will not add support to an old Windows Embedded to a new VS. The
only way we'll drop VS2008 here is if we also drop those Windows Embedded
versions that VS 2008 is required for.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Cristian Adam
2015-02-04 15:51:17 UTC
Permalink
On 04.02.2015 10:23, Knoll Lars wrote:
> In principle I agree. The problem with 2008 is that this is currently the
> only compiler supporting Windows Embedded 7, so we can’t easily get rid of
> it. Dropping gcc 4.4 is afaik not a big problem.
>

QNX 6.5.0 has GCC 4.4.2. I don't know how important QNX 6.5.0 is for Qt
Project.

Which version of QNX does Ford use for Sync3?

Cheers,
Cristian.
Andreas Holzammer
2015-02-05 08:55:33 UTC
Permalink
Am 04.02.2015 um 16:51 schrieb Cristian Adam:
> On 04.02.2015 10:23, Knoll Lars wrote:
>> In principle I agree. The problem with 2008 is that this is
>> currently the only compiler supporting Windows Embedded 7, so we
>> can’t easily get rid of it. Dropping gcc 4.4 is afaik not a big
>> problem.
>>
>
> QNX 6.5.0 has GCC 4.4.2. I don't know how important QNX 6.5.0 is
> for Qt Project.


I think we cannot really drop QNX 6.5.0 support. Many companies are
still using it even for new products. Embedded companies are not that
fast yet and most secure products cannot use newer technologies, same
applies for medical products. So if we want to support a big portion
of the embedded market we cannot drop either MSVC 2008 and gcc 4.4
support.

Thank you

Andy


- --
Andreas Holzammer | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Thiago Macieira
2015-02-05 16:13:30 UTC
Permalink
On Thursday 05 February 2015 09:55:33 Andreas Holzammer wrote:
> Am 04.02.2015 um 16:51 schrieb Cristian Adam:
> > On 04.02.2015 10:23, Knoll Lars wrote:
> >> In principle I agree. The problem with 2008 is that this is
> >> currently the only compiler supporting Windows Embedded 7, so we
> >> can’t easily get rid of it. Dropping gcc 4.4 is afaik not a big
> >> problem.
> >
> > QNX 6.5.0 has GCC 4.4.2. I don't know how important QNX 6.5.0 is
> > for Qt Project.
>
> I think we cannot really drop QNX 6.5.0 support. Many companies are
> still using it even for new products. Embedded companies are not that
> fast yet and most secure products cannot use newer technologies, same
> applies for medical products. So if we want to support a big portion
> of the embedded market we cannot drop either MSVC 2008 and gcc 4.4
> support.

No chance of people installing a new compiler against the same old sysroot?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Andreas Holzammer
2015-02-05 20:28:33 UTC
Permalink
Am 05.02.2015 um 17:13 schrieb Thiago Macieira:
> On Thursday 05 February 2015 09:55:33 Andreas Holzammer wrote:
>> Am 04.02.2015 um 16:51 schrieb Cristian Adam:
>>> On 04.02.2015 10:23, Knoll Lars wrote:
>>>> In principle I agree. The problem with 2008 is that this is
>>>> currently the only compiler supporting Windows Embedded 7, so we
>>>> can’t easily get rid of it. Dropping gcc 4.4 is afaik not a big
>>>> problem.
>>>
>>> QNX 6.5.0 has GCC 4.4.2. I don't know how important QNX 6.5.0 is
>>> for Qt Project.
>>
>> I think we cannot really drop QNX 6.5.0 support. Many companies are
>> still using it even for new products. Embedded companies are not that
>> fast yet and most secure products cannot use newer technologies, same
>> applies for medical products. So if we want to support a big portion
>> of the embedded market we cannot drop either MSVC 2008 and gcc 4.4
>> support.
>
> No chance of people installing a new compiler against the same old sysroot?

Actually there are new compilers for QNX 6.5.0 found here:
http://community.qnx.com/sf/frs/do/viewRelease/projects.toolchain/frs.gcc.gcc_4_8

The problem I had once is that I did not get a toolchain together which
worked for profiling Qt or C++ applications, but yes might be not very
relevant.

I would need to test if new gcc, binutils, new kernel and gdb will be a
valid option to go forward for QNX 6.5.0

Thank you

Andy


--
Andreas Holzammer | ***@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
Lisandro Damián Nicanor Pérez Meyer
2015-02-06 01:39:17 UTC
Permalink
On Friday 06 February 2015 01:19:17 Allan Sandfeld Jensen wrote:
> On Friday 06 February 2015, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Friday 06 February 2015 00:15:48 you wrote:
> > > About QtWebEngine, do you know what system libraries you have problems
> > > with it duplicating? I think we can configure most of it in the build
> > > system and already follow the Qt build settings for some that are
> > > usually shipped with Chromium.
> >
> > The real answer is simple: all of them. We do our best to avoid embedded
> > libraries (and yes, we sometimes fail to do it, and that's a bug for us).
> >
> > If I where to start at some place I would choose V8 and ffmpeg, but the
> > real thing is simply all of them.
>
> Those would be the last I would even think of separating. FFMpeg is a
> library that refuses to stabilize or even make releases forcing everyone to
> fork it and keep a internal copy, and V8 is tied to specific versions of
> chromium. This should also be no different from javascriptcore duplicated
> by webkit GTK and QtWebKit in Debian.

I do understand that it's a pain to maintain an app with a library that does
not has a stable API/ABI, but it's also a pain to maintain packaged code that
embeds it.

If ffmpeg can't be unbundled then sadly that's enough a reason not to ship
QtWebEngine in Debian. It's not strange to have CVEs in ffmpeg, and having
different copies (system and embedded) doesn't really helps. Not to mention
that we would be having two teams maintaining the same code...

I don't know the status of V8 with respect to security issues, but definitely
something that needs unembedding non the less.


> I was more thinking of common stable libraries like fontconfig, jpeg, zlib,
> webp and udev, which I believe we have already fixed.

I have not checked QtWebEngine that far, but those would be great news :)

--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Guido Seifert
2015-02-06 05:30:40 UTC
Permalink
Did something like that happen before? Sounds strange to me to ship only parts of a framework.
I imagine that this would also be a support nightmare... Qt5 is installed, but some other packages
don't work or are not installable because they have a dependency to QtWebEngine. In a way it
would feel more natural to me for Debian to drop Qt5 at all... but of course, this is totally
impossible. Very ugly situation.

Guido

> If ffmpeg can't be unbundled then sadly that's enough a reason not to ship
> QtWebEngine in Debian.
Kevin Kofler
2015-02-09 21:52:34 UTC
Permalink
Guido Seifert wrote:
> Did something like that happen before?

Yes, RHEL has never shipped QtWebKit, as far as I know because of support
(especially with security updates) concerns. (They're likely to also not
ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did not
exist yet when RHEL 7 was released.) They also ship kdelibs with
Plasma::WebView patched out, kdepim without KMail (because it depends on
QtWebKit), Qt Assistant built against QTextBrowser, and similar such feature
removals/degradation throughout KDE.

If all that stuff moves to QtWebEngine, we will likely end up with Fedora
and Debian getting similarly crippled. :-(

Kevin Kofler
Thiago Macieira
2015-02-10 03:30:30 UTC
Permalink
On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> Guido Seifert wrote:
> > Did something like that happen before?
>
> Yes, RHEL has never shipped QtWebKit, as far as I know because of support
> (especially with security updates) concerns. (They're likely to also not
> ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did not
> exist yet when RHEL 7 was released.) They also ship kdelibs with
> Plasma::WebView patched out, kdepim without KMail (because it depends on
> QtWebKit), Qt Assistant built against QTextBrowser, and similar such feature
> removals/degradation throughout KDE.
>
> If all that stuff moves to QtWebEngine, we will likely end up with Fedora
> and Debian getting similarly crippled. :-(

You'll probably have to provide a repository for packages supported less
thoroughly. There are just too many requirements for Web parsing.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Corentin Jabot
2015-03-17 14:04:19 UTC
Permalink
Regarding QJSEngine, some things are unclear to me.

Let's say I have a QObject-derived class. how do I create an instance of
that class from a script ?

c++ : class Foo : public QObject { Q_OBJECT }; js : var foo = new Foo()

How do I call a c++ function from a js script ? That use case seems not
supported at all, I'm I right ?

Those two features seems essential to me for QJSEngine to ever replace
QScriptEngine. They also are pretty basic.


I understand one will have to heavily modify the C++ code to port to
QJSEngine, but, I find the fact that the port will break the scripts...
worrisome


I think QJSEngine should aim to be compatible with any script that worked
with QScriptEngine (provided the C++ code is modified accordingly)



Regards,
Corentin Jabot


2015-02-10 4:30 GMT+01:00 Thiago Macieira <***@intel.com>:

> On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> > Guido Seifert wrote:
> > > Did something like that happen before?
> >
> > Yes, RHEL has never shipped QtWebKit, as far as I know because of support
> > (especially with security updates) concerns. (They're likely to also not
> > ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did
> not
> > exist yet when RHEL 7 was released.) They also ship kdelibs with
> > Plasma::WebView patched out, kdepim without KMail (because it depends on
> > QtWebKit), Qt Assistant built against QTextBrowser, and similar such
> feature
> > removals/degradation throughout KDE.
> >
> > If all that stuff moves to QtWebEngine, we will likely end up with Fedora
> > and Debian getting similarly crippled. :-(
>
> You'll probably have to provide a repository for packages supported less
> thoroughly. There are just too many requirements for Web parsing.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
Simon Hausmann
2015-03-18 10:00:19 UTC
Permalink
On Tuesday 17. March 2015 15.04.19 Corentin Jabot wrote:
> Regarding QJSEngine, some things are unclear to me.
>
> Let's say I have a QObject-derived class. how do I create an instance of
> that class from a script ?
>
> c++ : class Foo : public QObject { Q_OBJECT }; js : var foo = new Foo()

Yes, custom constructor functions are not supported at the moment. I think
it would be fairly easy to implement this, the meta-object system supports
dynamic construction. If you mark a constructor as Q_INVOKABLE, then you can
do

QObject *instance = metaObject.newInstance(parameters)

So for QObject sub-classes with invokable constructors, we could expose these
as JavaScript constructor functions. Due to the requirement to place
Q_INVOKABLE, it becomes an op-in feature.

Would you be interested in trying to implement that in QJSEngine? :)

> How do I call a c++ function from a js script ? That use case seems not
> supported at all, I'm I right ?

If it is a member function, then it is callable. It can be a member function
of a QObject or a gadget.



Simon

> Those two features seems essential to me for QJSEngine to ever replace
> QScriptEngine. They also are pretty basic.
>
>
> I understand one will have to heavily modify the C++ code to port to
> QJSEngine, but, I find the fact that the port will break the scripts...
> worrisome
>
>
> I think QJSEngine should aim to be compatible with any script that worked
> with QScriptEngine (provided the C++ code is modified accordingly)
>
>
>
> Regards,
> Corentin Jabot
>
> 2015-02-10 4:30 GMT+01:00 Thiago Macieira <***@intel.com>:
> > On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> > > Guido Seifert wrote:
> > > > Did something like that happen before?
> > >
> > > Yes, RHEL has never shipped QtWebKit, as far as I know because of
> > > support
> > > (especially with security updates) concerns. (They're likely to also not
> > > ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did
> >
> > not
> >
> > > exist yet when RHEL 7 was released.) They also ship kdelibs with
> > > Plasma::WebView patched out, kdepim without KMail (because it depends on
> > > QtWebKit), Qt Assistant built against QTextBrowser, and similar such
> >
> > feature
> >
> > > removals/degradation throughout KDE.
> > >
> > > If all that stuff moves to QtWebEngine, we will likely end up with
> > > Fedora
> > > and Debian getting similarly crippled. :-(
> >
> > You'll probably have to provide a repository for packages supported less
> > thoroughly. There are just too many requirements for Web parsing.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >
> > Software Architect - Intel Open Source Technology Center
> >
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
Corentin Jabot
2015-03-18 13:25:46 UTC
Permalink
2015-03-18 11:00 GMT+01:00 Simon Hausmann <***@theqtcompany.com>:

> On Tuesday 17. March 2015 15.04.19 Corentin Jabot wrote:
> > Regarding QJSEngine, some things are unclear to me.
> >
> > Let's say I have a QObject-derived class. how do I create an instance of
> > that class from a script ?
> >
> > c++ : class Foo : public QObject { Q_OBJECT }; js : var foo = new
> Foo()
>
> Yes, custom constructor functions are not supported at the moment. I think
> it would be fairly easy to implement this, the meta-object system supports
> dynamic construction. If you mark a constructor as Q_INVOKABLE, then you
> can
> do
>
> QObject *instance = metaObject.newInstance(parameters)
>
> So for QObject sub-classes with invokable constructors, we could expose
> these
> as JavaScript constructor functions. Due to the requirement to place
> Q_INVOKABLE, it becomes an op-in feature.
>

That's a fair requirement.

>
> Would you be interested in trying to implement that in QJSEngine? :)
>

Sorry, I already taken too many engagements for the time being. I home
someone else do it though !

>
> > How do I call a c++ function from a js script ? That use case seems not
> > supported at all, I'm I right ?
>
> If it is a member function, then it is callable. It can be a member
> function
> of a QObject or a gadget


I was specifically speaking about free functions. Skimming my code, I use
them to define utilities like print,
as well as supporting the PAC specification.
For some use case, I guess you could do something like : var foo =
object.foo (where foo is a function), but it doesn't solve
every use case, notably, functions like print can take an arbitrary number
of arguments. QtScript solves that by registering functions
taking a "context" object, holding the parameters as well as other useful
info, like the value of this.

Will that sort of thing be supported in the future ?


>

> Simon
>
> > Those two features seems essential to me for QJSEngine to ever replace
> > QScriptEngine. They also are pretty basic.
> >
> >
> > I understand one will have to heavily modify the C++ code to port to
> > QJSEngine, but, I find the fact that the port will break the scripts...
> > worrisome
> >
> >
> > I think QJSEngine should aim to be compatible with any script that worked
> > with QScriptEngine (provided the C++ code is modified accordingly)
> >
> >
> >
> > Regards,
> > Corentin Jabot
> >
> > 2015-02-10 4:30 GMT+01:00 Thiago Macieira <***@intel.com>:
> > > On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> > > > Guido Seifert wrote:
> > > > > Did something like that happen before?
> > > >
> > > > Yes, RHEL has never shipped QtWebKit, as far as I know because of
> > > > support
> > > > (especially with security updates) concerns. (They're likely to also
> not
> > > > ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine
> did
> > >
> > > not
> > >
> > > > exist yet when RHEL 7 was released.) They also ship kdelibs with
> > > > Plasma::WebView patched out, kdepim without KMail (because it
> depends on
> > > > QtWebKit), Qt Assistant built against QTextBrowser, and similar such
> > >
> > > feature
> > >
> > > > removals/degradation throughout KDE.
> > > >
> > > > If all that stuff moves to QtWebEngine, we will likely end up with
> > > > Fedora
> > > > and Debian getting similarly crippled. :-(
> > >
> > > You'll probably have to provide a repository for packages supported
> less
> > > thoroughly. There are just too many requirements for Web parsing.
> > >
> > > --
> > > Thiago Macieira - thiago.macieira (AT) intel.com
> > >
> > > Software Architect - Intel Open Source Technology Center
> > >
> > > _______________________________________________
> > > Development mailing list
> > > ***@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
>
>
Jan Kundrát
2015-03-17 16:14:38 UTC
Permalink
On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
> * Qt WebKit

While I understand the reasons on why you want to remove this one, I think
that this goes against the promise of compatibility at [1]:

"Qt essentials define the foundation of Qt on all platforms. They are
available on all supported development platforms and on the tested target
platforms. They will remain source and binary compatible during Qt 5."

Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
QtScript and QtDeclarative are listed as Addons, and "could probably go".

You're of course free to do whatever you want to do -- it's just that the
project has promised that this won't happen.

Cheers,
Jan

[1] http://doc.qt.io/qt-5/qtmodules.html

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Thiago Macieira
2015-03-17 22:45:24 UTC
Permalink
On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
> > * Qt WebKit
>
> While I understand the reasons on why you want to remove this one, I think
> that this goes against the promise of compatibility at [1]:
>
> "Qt essentials define the foundation of Qt on all platforms. They are
> available on all supported development platforms and on the tested target
> platforms. They will remain source and binary compatible during Qt 5."
>
> Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
> QtScript and QtDeclarative are listed as Addons, and "could probably go".
>
> You're of course free to do whatever you want to do -- it's just that the
> project has promised that this won't happen.

We promised not to break source or binary compatibility. Where are we doing
that?

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Bo Thorsen
2015-03-18 06:44:12 UTC
Permalink
Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
> On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
>> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
>>> * Qt WebKit
>> While I understand the reasons on why you want to remove this one, I think
>> that this goes against the promise of compatibility at [1]:
>>
>> "Qt essentials define the foundation of Qt on all platforms. They are
>> available on all supported development platforms and on the tested target
>> platforms. They will remain source and binary compatible during Qt 5."
>>
>> Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
>> QtScript and QtDeclarative are listed as Addons, and "could probably go".
>>
>> You're of course free to do whatever you want to do -- it's just that the
>> project has promised that this won't happen.
> We promised not to break source or binary compatibility. Where are we doing
> that?

Removing classes is as binary incompatible as you can possibly make it.

Bo.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
Knoll Lars
2015-03-18 07:31:00 UTC
Permalink
On 18/03/15 07:44, "Bo Thorsen" <***@vikingsoft.eu> wrote:

>Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
>> On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
>>> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
>>>> * Qt WebKit
>>> While I understand the reasons on why you want to remove this one, I
>>>think
>>> that this goes against the promise of compatibility at [1]:
>>>
>>> "Qt essentials define the foundation of Qt on all platforms. They are
>>> available on all supported development platforms and on the tested
>>>target
>>> platforms. They will remain source and binary compatible during Qt 5."
>>>
>>> Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
>>> QtScript and QtDeclarative are listed as Addons, and "could probably
>>>go".

Yes, they are listed under Essentials, and we’ll need to move them over to
add-ons. Unfortunately, we rely on a lot of 3rd party code (ie. WebKit)
with the module, and as you probably know there were major changes in the
landscape happening there when Google decided to for the whole thing and
go their own way.

Unfortunately this simply made it impossible for us to continue with Qt
WebKit as before. We had to make some hard decisions, and the result was
to focus on the new Webengine module, as we didn’t see a way to continue
to support WebKit properly.

>>>
>>> You're of course free to do whatever you want to do -- it's just that
>>>the
>>> project has promised that this won't happen.
>> We promised not to break source or binary compatibility. Where are we
>>doing
>> that?
>
>Removing classes is as binary incompatible as you can possibly make it.

Deprecating an API is different from removing it. Deprecating is about
asking people not to use this for new code/projects anymore.

Cheers,
Lars
Bo Thorsen
2015-03-18 07:35:07 UTC
Permalink
Den 18-03-2015 kl. 08:31 skrev Knoll Lars:
> On 18/03/15 07:44, "Bo Thorsen" <***@vikingsoft.eu> wrote:
>
>> Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
>>> On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
>>>> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
>>>>> * Qt WebKit
>>>> While I understand the reasons on why you want to remove this one, I
>>>> think
>>>> that this goes against the promise of compatibility at [1]:
>>>>
>>>> "Qt essentials define the foundation of Qt on all platforms. They are
>>>> available on all supported development platforms and on the tested
>>>> target
>>>> platforms. They will remain source and binary compatible during Qt 5."
>>>>
>>>> Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
>>>> QtScript and QtDeclarative are listed as Addons, and "could probably
>>>> go".
> Yes, they are listed under Essentials, and we’ll need to move them over to
> add-ons. Unfortunately, we rely on a lot of 3rd party code (ie. WebKit)
> with the module, and as you probably know there were major changes in the
> landscape happening there when Google decided to for the whole thing and
> go their own way.
>
> Unfortunately this simply made it impossible for us to continue with Qt
> WebKit as before. We had to make some hard decisions, and the result was
> to focus on the new Webengine module, as we didn’t see a way to continue
> to support WebKit properly.
>
>>>> You're of course free to do whatever you want to do -- it's just that
>>>> the
>>>> project has promised that this won't happen.
>>> We promised not to break source or binary compatibility. Where are we
>>> doing
>>> that?
>> Removing classes is as binary incompatible as you can possibly make it.
> Deprecating an API is different from removing it. Deprecating is about
> asking people not to use this for new code/projects anymore.

Of course, but you said that it will be removed in 5.6.

Bo.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
Knoll Lars
2015-03-18 07:39:01 UTC
Permalink
On 18/03/15 08:35, "Bo Thorsen" <***@vikingsoft.eu> wrote:

>Den 18-03-2015 kl. 08:31 skrev Knoll Lars:
>> On 18/03/15 07:44, "Bo Thorsen" <***@vikingsoft.eu> wrote:
>>
>>> Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
>>>> On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
>>>>> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
>>>>>> * Qt WebKit
>>>>> While I understand the reasons on why you want to remove this one, I
>>>>> think
>>>>> that this goes against the promise of compatibility at [1]:
>>>>>
>>>>> "Qt essentials define the foundation of Qt on all platforms. They are
>>>>> available on all supported development platforms and on the tested
>>>>> target
>>>>> platforms. They will remain source and binary compatible during Qt
>>>>>5."
>>>>>
>>>>> Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
>>>>> QtScript and QtDeclarative are listed as Addons, and "could probably
>>>>> go".
>> Yes, they are listed under Essentials, and we’ll need to move them over
>>to
>> add-ons. Unfortunately, we rely on a lot of 3rd party code (ie. WebKit)
>> with the module, and as you probably know there were major changes in
>>the
>> landscape happening there when Google decided to for the whole thing and
>> go their own way.
>>
>> Unfortunately this simply made it impossible for us to continue with Qt
>> WebKit as before. We had to make some hard decisions, and the result was
>> to focus on the new Webengine module, as we didn’t see a way to continue
>> to support WebKit properly.
>>
>>>>> You're of course free to do whatever you want to do -- it's just that
>>>>> the
>>>>> project has promised that this won't happen.
>>>> We promised not to break source or binary compatibility. Where are we
>>>> doing
>>>> that?
>>> Removing classes is as binary incompatible as you can possibly make it.
>> Deprecating an API is different from removing it. Deprecating is about
>> asking people not to use this for new code/projects anymore.
>
>Of course, but you said that it will be removed in 5.6.

From the binary packages only, and only if the migration path is easy and
good enough. So far it seems that at least Qt Script and Qt WebKit might
have to stay around a little longer.

Cheers,
Lars
Florian Bruhin
2015-03-18 07:39:28 UTC
Permalink
* Knoll Lars <***@theqtcompany.com> [2015-03-18 07:31:00 +0000]:
> On 18/03/15 07:44, "Bo Thorsen" <***@vikingsoft.eu> wrote:
>
> >Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
> >> On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
> >>> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
> >>>> * Qt WebKit
> [...]
> >>>
> >>> You're of course free to do whatever you want to do -- it's just that
> >>>the
> >>> project has promised that this won't happen.
> >> We promised not to break source or binary compatibility. Where are we
> >>doing
> >> that?
> >
> >Removing classes is as binary incompatible as you can possibly make it.
>
> Deprecating an API is different from removing it. Deprecating is about
> asking people not to use this for new code/projects anymore.

I think that's the point Bo is trying to make - deprecating is fine
(though I'm unhappy with it as QtWebEngine doesn't exactly feel ready
yet), but removing it in 5.6 (as suggested in your original mail)
probably is not.

But if I understood correctly, the consensus here seems to be to
deprecate it in Qt 5.5 and remove it with Qt 6, which sounds much more
reasonable to me.

Florian

--
http://www.the-compiler.org | ***@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
Thiago Macieira
2015-03-18 11:07:22 UTC
Permalink
On Wednesday 18 March 2015 08:39:28 Florian Bruhin wrote:
> But if I understood correctly, the consensus here seems to be to
> deprecate it in Qt 5.5 and remove it with Qt 6, which sounds much more
> reasonable to me.

That's not the consensus.

People panicked when they read Tuukka's blog saying "considered for removal in
the future releases of Qt" without understanding what he actually meant.

Tuukka was talking about modules. Removing modules means they no longer get
compiled as part of the convenience binaries and as part of the convenience
"qt-everywhere" tarball. If you need them, compile the release.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Allan Sandfeld Jensen
2015-03-18 08:33:20 UTC
Permalink
On Wednesday 18 March 2015, Bo Thorsen wrote:
> Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
> > On Tuesday 17 March 2015 17:14:38 Jan Kundrát wrote:
> >> On Tuesday, 3 February 2015 08:33:46 CET, Knoll Lars wrote:
> >>> * Qt WebKit
> >>
> >> While I understand the reasons on why you want to remove this one, I
> >> think that this goes against the promise of compatibility at [1]:
> >>
> >> "Qt essentials define the foundation of Qt on all platforms. They are
> >> available on all supported development platforms and on the tested
> >> target platforms. They will remain source and binary compatible during
> >> Qt 5."
> >>
> >> Both "Qt WebKit" and "Qt WebKit Widgets" are listed under Essentials.
> >> QtScript and QtDeclarative are listed as Addons, and "could probably
> >> go".
> >>
> >> You're of course free to do whatever you want to do -- it's just that
> >> the project has promised that this won't happen.
> >
> > We promised not to break source or binary compatibility. Where are we
> > doing that?
>
> Removing classes is as binary incompatible as you can possibly make it.
>
They are not removed, they are deprecated.

`Allan
Thiago Macieira
2015-03-18 11:03:45 UTC
Permalink
On Wednesday 18 March 2015 07:44:12 Bo Thorsen wrote:
> Den 17-03-2015 kl. 23:45 skrev Thiago Macieira:
> > We promised not to break source or binary compatibility. Where are we
> > doing
> > that?
>
> Removing classes is as binary incompatible as you can possibly make it.

They're not removed. They remain exactly in the same library as they've always
been.

The only difference is that we may not ship those libraries in the pre-built
binaries. The only consequence of that is that you may need to compile them
yourselves.

I don't count that as binary compatibility breakage.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Bernhard
2015-03-17 22:04:39 UTC
Permalink
Some of our applications are relying on Qt Script and Qt Webkit. So I just
had a look at the replacements (Qt Webengine and Qt QML).

The documentation says "... WebEngine ... doesn't give direct access to the
network stack and the HTML document through C++ APIs".
Does this mean there is no way to access the DOM anymore? This would be
fatal for us. Accessing the DOM is essential for all of our applications
that use QWebView. Is there some replacement/workaround?

Also we use the QScriptEngineDebugger but there seems to be no debugger for
QJSEngine. Is there some replacement/workaround?

Are there other significant differences that I should consider?

--
Kind Regards
Bernhard Lindner

> -----UrsprÃŒngliche Nachricht-----
> Von: development-bounces+private=bernhard-***@qt-project.org
> [mailto:development-bounces+private=bernhard-***@qt-
> project.org] Im Auftrag von Knoll Lars
> Gesendet: Dienstag, 3. Februar 2015 08:34
> An: ***@qt-project.org
> Betreff: [Development] Deprecating modules with 5.5
>
> Hi,
>
> I’d like to mark a few modules as deprecated with 5.5, and most likely
> remove them from the binary packages with 5.6. These modules are:
>
> * Qt WebKit
> * Qt Declarative (Qt Quick 1)
> * Qt Script
>
> All of these modules are by now a couple of years old, don’t receive
updates
> above the bare minimum and have a replacement that is actively being
> developed in Qt 5.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Continue reading on narkive:
Loading...