Re: [Development] QtWebKit is coming back (part 2)

[Edward Welbourne]

07.09.2017, 10:45, "Martin Koller" :
>> It also seems that it requires a too new ICU devel package (at least
>> for CentOS 7.3), that is I need to deactivate INTL by using
>> -DENABLE_INTL=OFF
>>
>> Can you tell us what I actually disable with that switch, e.g.: what
>> does no longer work ?

Konstantin Tokarev (7 September 2017 10:09)
> Intl
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

Or, indeed:

http://www.ecma-international.org/ecma-402/3.0/index.html#intl-object

Eddy, who prefers authoritative specs.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

07.09.2017, 10:45, "Martin Koller" :
> On Donnerstag, 27. Juli 2017 16:13:05 CEST Konstantin Tokarev wrote:
>>  27.07.2017, 16:41, "Martin Koller" :
>>  > On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote:
>>  >
>>  >> >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. 
>> However this brings a
>>  >> >> degradation of user experience, especially in case of IndexedDB which 
>> was supported
>>  >> >> in previous versions. Therefore you have 3 options:
>>  >> >>
>>  >> >> 1) Disable these features and build limited version using GCC 4.8;
>>  >> >
>>  >> > that brings us to the second part of my question which was not 
>> answered: how ?
>>  >> > Is there any qmake or env var I can set ?
>>  >>
>>  >> Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
>>  >> -DENABLE_DATABASE_PROCESS=OFF to cmake arguments
>>  >>
>>  >> You should not use qmake in your package, look at [1] for example.
>>  >>
>>  >> [1] 
>> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec
>
> It also seems that it requires a too new ICU devel package (at least for 
> CentOS 7.3), that is
> I need to deactivate INTL by using -DENABLE_INTL=OFF
>
> Can you tell us what I actually disable with that switch, e.g.: what does no 
> longer work ?

Intl

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl

>
> --
> Best regards/Schöne Grüße
>
> Martin
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Martin Koller]

On Donnerstag, 27. Juli 2017 16:13:05 CEST Konstantin Tokarev wrote:
> 
> 27.07.2017, 16:41, "Martin Koller" :
> > On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote:
> >
> >>  >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. 
> >> However this brings a
> >>  >> degradation of user experience, especially in case of IndexedDB which 
> >> was supported
> >>  >> in previous versions. Therefore you have 3 options:
> >>  >>
> >>  >> 1) Disable these features and build limited version using GCC 4.8;
> >>  >
> >>  > that brings us to the second part of my question which was not 
> >> answered: how ?
> >>  > Is there any qmake or env var I can set ?
> >>
> >>  Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
> >>  -DENABLE_DATABASE_PROCESS=OFF to cmake arguments
> >>
> >>  You should not use qmake in your package, look at [1] for example.
> >>
> >>  [1] 
> >> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec

It also seems that it requires a too new ICU devel package (at least for CentOS 
7.3), that is
I need to deactivate INTL by using -DENABLE_INTL=OFF

Can you tell us what I actually disable with that switch, e.g.: what does no 
longer work ?

-- 
Best regards/Schöne Grüße

Martin

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

17.08.2017, 18:17, "Thiago Macieira" :
> On Thursday, 17 August 2017 08:12:23 PDT Konstantin Tokarev wrote:
>>  Altrernatively, you can drop qtwebkit sources on the same level with other
>>  Qt modules, however it will break if you customize installation paths, e.g.
>>  use custom libdir. Also, cross-compilation is not supported in this way
>
> That doesn't work anymore, as of this week, since commit
> 5a0dc401fad4adccbd975392295d2c77d936900f.

Indeed, I forgot that .gitmodules is used for non-git builds too

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

On Thursday, 17 August 2017 08:12:23 PDT Konstantin Tokarev wrote:
> Altrernatively, you can drop qtwebkit sources on the same level with other
> Qt modules, however it will break if you customize installation paths, e.g.
> use custom libdir. Also, cross-compilation is not supported in this way

That doesn't work anymore, as of this week, since commit 
5a0dc401fad4adccbd975392295d2c77d936900f.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

17.08.2017, 18:06, "Thiago Macieira" :
> On Thursday, 17 August 2017 07:24:05 PDT Martin Koller wrote:
>>  Hi,
>>
>>  is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in
>>  the way that I can build Qt with webkit support so that the help system and
>>  assistant also use it ?
>
> No.
>
> You need to use the split-build mechanism, the one that Linux distributions
> use. Build each of the regular modules individually, then qtwebkit, then
> qtwebkit-examples, qttools (for assistant).

Altrernatively, you can drop qtwebkit sources on the same level with other Qt 
modules,
however it will break if you customize installation paths, e.g. use custom 
libdir. Also,
cross-compilation is not supported in this way

>
>>  What is the recommended way to build Qt and assistant to have webkit support
>>  ?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

On Thursday, 17 August 2017 07:24:05 PDT Martin Koller wrote:
> Hi,
> 
> is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in
> the way that I can build Qt with webkit support so that the help system and
> assistant also use it ?

No.

You need to use the split-build mechanism, the one that Linux distributions 
use. Build each of the regular modules individually, then qtwebkit, then 
qtwebkit-examples, qttools (for assistant).

> What is the recommended way to build Qt and assistant to have webkit support
> ?


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Martin Koller]

Hi,

is the 5.212 branch now as integrated in Qt as it was before in Qt 5.5 in the 
way that I can build Qt
with webkit support so that the help system and assistant also use it ?

What is the recommended way to build Qt and assistant to have webkit support ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

27.07.2017, 16:41, "Martin Koller" :
> On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote:
>
>>  >> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. 
>> However this brings a
>>  >> degradation of user experience, especially in case of IndexedDB which 
>> was supported
>>  >> in previous versions. Therefore you have 3 options:
>>  >>
>>  >> 1) Disable these features and build limited version using GCC 4.8;
>>  >
>>  > that brings us to the second part of my question which was not answered: 
>> how ?
>>  > Is there any qmake or env var I can set ?
>>
>>  Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
>>  -DENABLE_DATABASE_PROCESS=OFF to cmake arguments
>>
>>  You should not use qmake in your package, look at [1] for example.
>>
>>  [1] 
>> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec
>
> thanks. I'm just trying this but I get a link failure (error below).
>
> Questions:
> - Does QtWebKit allow to disable Qt-Quick alltogether ? I don't need that.

-DENABLE_WEBKIT2=OFF

>   (I had Qt 5.9.1 configured without qtdeclarative, but then the cmake call 
> for QtWebKit already failed)
> - Does QtWebKit allow to be compiled as a namespaced/infixed library, as was 
> possible in e.g. Qt 5.5

QtWebKit has never allowed compilation as namespaced library, but it supports 
compilation against namespaced Qt

As for infix, it is not supported with new build system and this is is indeed a 
regression, patches are welcome

>   so that the result is a libQt5WebKitWinCC_OA.so (Qt 5.9.1 is compiled with 
> -qtnamespace WinCC_OA -qtlibinfix WinCC_OA)
>
> ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o:
>  In function 
> `QQuickWebViewExperimental::QQuickWebViewExperimental(QQuickWebView*, 
> QQuickWebViewPrivate*)':
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xb6):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::QQmlWebChannel(WinCC_OA::QObject*)'
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xfd):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)'
> ../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o:
>  In function 
> `QQuickWebViewExperimental::setWebChannel(WinCC_OA::QQmlWebChannel*)':
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x44):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::disconnectFrom(WinCC_OA::QObject*)'
> qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x78):
>  undefined reference to 
> `WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)'
> collect2: error: ld returned 1 exit status
> Source/WebKit/CMakeFiles/WebKit.dir/build.make:2647: recipe for target 
> 'lib/libQt5WebKit.so.5.212.0' failed
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Martin Koller]

On Dienstag, 25. Juli 2017 14:20:28 CEST Konstantin Tokarev wrote:

> >>  You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. 
> >> However this brings a
> >>  degradation of user experience, especially in case of IndexedDB which was 
> >> supported
> >>  in previous versions. Therefore you have 3 options:
> >>
> >>  1) Disable these features and build limited version using GCC 4.8;
> >
> > that brings us to the second part of my question which was not answered: 
> > how ?
> > Is there any qmake or env var I can set ?
> 
> Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
> -DENABLE_DATABASE_PROCESS=OFF to cmake arguments
> 
> You should not use qmake in your package, look at [1] for example.
> 
> [1] 
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec

thanks. I'm just trying this but I get a link failure (error below).

Questions:
- Does QtWebKit allow to disable Qt-Quick alltogether ? I don't need that.
  (I had Qt 5.9.1 configured without qtdeclarative, but then the cmake call for 
QtWebKit already failed)
- Does QtWebKit allow to be compiled as a namespaced/infixed library, as was 
possible in e.g. Qt 5.5
  so that the result is a libQt5WebKitWinCC_OA.so (Qt 5.9.1 is compiled with 
-qtnamespace WinCC_OA -qtlibinfix WinCC_OA)

../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o:
 In function 
`QQuickWebViewExperimental::QQuickWebViewExperimental(QQuickWebView*, 
QQuickWebViewPrivate*)':
qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xb6):
 undefined reference to 
`WinCC_OA::QQmlWebChannel::QQmlWebChannel(WinCC_OA::QObject*)'
qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimentalC2EP13QQuickWebViewP20QQuickWebViewPrivate+0xfd):
 undefined reference to 
`WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)'
../../lib/../Source/WebKit2/CMakeFiles/WebKit2.dir/UIProcess/API/qt/qquickwebview.cpp.o:
 In function 
`QQuickWebViewExperimental::setWebChannel(WinCC_OA::QQmlWebChannel*)':
qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x44):
 undefined reference to 
`WinCC_OA::QQmlWebChannel::disconnectFrom(WinCC_OA::QObject*)'
qquickwebview.cpp:(.text._ZN25QQuickWebViewExperimental13setWebChannelEPN8WinCC_OA14QQmlWebChannelE+0x78):
 undefined reference to 
`WinCC_OA::QQmlWebChannel::connectTo(WinCC_OA::QObject*)'
collect2: error: ld returned 1 exit status
Source/WebKit/CMakeFiles/WebKit.dir/build.make:2647: recipe for target 
'lib/libQt5WebKit.so.5.212.0' failed

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

24.07.2017, 08:33, "Martin Koller" :
> On Sonntag, 23. Juli 2017 23:45:30 CEST Konstantin Tokarev wrote:
>>  23.07.2017, 23:49, "Martin Koller" :
>>  > On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote:
>>  >
>>  >> I'm not sure it would be acceptable, because updated QtWebKit requires 
>> full
>>  >> C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling 
>> some
>>  >> features, or with code changes, which were not done yet).
>>  >
>>  > I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the 
>> installed
>>  > gcc compiler (4.8.5) and I get:
>>  >
>>  > The WebKit build was disabled for the following reasons:
>>  > * Using gcc version 4.8, but at least gcc version 4.9 is required to 
>> build QtWebKit.
>>  >
>>  > So which features can I disable and how ?
>>  >
>>  > Note that gcc 4.8.5 is the std. compiler on the latest official version 
>> of openSuse and still
>>  > I can not compile ... :-(
>>
>>  You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However 
>> this brings a
>>  degradation of user experience, especially in case of IndexedDB which was 
>> supported
>>  in previous versions. Therefore you have 3 options:
>>
>>  1) Disable these features and build limited version using GCC 4.8;
>
> that brings us to the second part of my question which was not answered: how ?
> Is there any qmake or env var I can set ?

Pass -DENABLE_FTL_JIT=OFF -DENABLE_INDEXED_DATABASE=OFF
-DENABLE_DATABASE_PROCESS=OFF to cmake arguments

You should not use qmake in your package, look at [1] for example.

[1] 
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebkit.git/tree/qt5-qtwebkit.spec

>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Martin Koller]

On Sonntag, 23. Juli 2017 23:45:30 CEST Konstantin Tokarev wrote:
> 
> 23.07.2017, 23:49, "Martin Koller" :
> > On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote:
> >
> >>  I'm not sure it would be acceptable, because updated QtWebKit requires 
> >> full
> >>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling 
> >> some
> >>  features, or with code changes, which were not done yet).
> >
> > I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the 
> > installed
> > gcc compiler (4.8.5) and I get:
> >
> > The WebKit build was disabled for the following reasons:
> > * Using gcc version 4.8, but at least gcc version 4.9 is required to 
> > build QtWebKit.
> >
> > So which features can I disable and how ?
> >
> > Note that gcc 4.8.5 is the std. compiler on the latest official version of 
> > openSuse and still
> > I can not compile ... :-(
> 
> You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However 
> this brings a
> degradation of user experience, especially in case of IndexedDB which was 
> supported
> in previous versions. Therefore you have 3 options:
> 
> 1) Disable these features and build limited version using GCC 4.8;

that brings us to the second part of my question which was not answered: how ?
Is there any qmake or env var I can set ?

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

23.07.2017, 23:49, "Martin Koller" :
> On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote:
>
>>  I'm not sure it would be acceptable, because updated QtWebKit requires full
>>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
>>  features, or with code changes, which were not done yet).
>
> I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the 
> installed
> gcc compiler (4.8.5) and I get:
>
> The WebKit build was disabled for the following reasons:
> * Using gcc version 4.8, but at least gcc version 4.9 is required to 
> build QtWebKit.
>
> So which features can I disable and how ?
>
> Note that gcc 4.8.5 is the std. compiler on the latest official version of 
> openSuse and still
> I can not compile ... :-(

You can compile with GCC 4.8 if IndexedDB and FTL JIT are disabled. However 
this brings a
degradation of user experience, especially in case of IndexedDB which was 
supported
in previous versions. Therefore you have 3 options:

1) Disable these features and build limited version using GCC 4.8;

2) Provide patches that fix compilation with GCC 4.8 and these features enabled 
(it's broken now because GCC 4.8 fails to compile legal C++11 construction, 
namely expansion of vararg template parameter pack inside lambda expression;

3) Use a different compiler to build QtWebKit package which still can be binary 
compatible with the rest of the system. GCC >= 4.9 or Clang is fine

>
> I will have the same issue when I want to compile it for SLES-12-SP2 or RHEL 
> or CentOS-7
> all with gcc 4.8
>
> It would be really nice if the current release branch would compile at least 
> on these major distros
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> () ascii ribbon campaign - against html e-mail
> /\ - against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

On Sunday, 23 July 2017 13:49:18 PDT Martin Koller wrote:
> It would be really nice if the current release branch would compile at least
> on these major distros

Sorry, it's out of our hands. The source code upstream has moved on and is 
using C++ features not available in GCC 4.8.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Martin Koller]

On Mittwoch, 3. Mai 2017 17:03:50 CEST Konstantin Tokarev wrote:

> I'm not sure it would be acceptable, because updated QtWebKit requires full
> C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
> features, or with code changes, which were not done yet).

I'm trying to compile QtWebKit (5.212) on my openSuse 42.2, using the installed
gcc compiler (4.8.5) and I get:

The WebKit build was disabled for the following reasons:
* Using gcc version 4.8, but at least gcc version 4.9 is required to build 
QtWebKit.

So which features can I disable and how ?

Note that gcc 4.8.5 is the std. compiler on the latest official version of 
openSuse and still
I can not compile ... :-(

I will have the same issue when I want to compile it for SLES-12-SP2 or RHEL or 
CentOS-7
all with gcc 4.8

It would be really nice if the current release branch would compile at least on 
these major distros

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

11.05.2017, 16:10, "Oswald Buddenhagen" :
> On Wed, May 10, 2017 at 09:53:26AM +0200, Edward Welbourne wrote:
>> Oswald Buddenhagen (4 May 2017 18:35)
>> > i'll say outright that you can't be part of the qt supermodule and yet
>> > have independent releases. while that was the plan once upon a time, 
>> the
>> > whole release infrastructure simply doesn't deliver, and even just
>> > diverging branch names are a pita (proved by enginio).
>>
>> Can you elaborate on the pain here ?
>
> when the branch names are not uniform, they need to be derived from the
> repositories' actual contents (.qmake.conf, in particular). and that has
> historically been a mess because of lagging states due to late module
> additions, tardy version updates, and delayed merges and qt5 integrations.
>
> from the user perspective, diverging versions are a mess, because you
> never know what belongs together. that was particularly annoying with
> enginio, because there was no _reason_ for this being so.
>
>> I note, in particular, that we do have sub-sub-modules on branches
>> with eccentric names, or none
>
> these sub-modules' branches are completely desynchronized with qt, so
> dealing with them is not part of the qt release cycle. qt simply pins
> sha1s, and the modules are not directly in our CI.
>
>> What would we need to do to our release infrastructure to make it
>> cope with (as originally planned) independent release cycles for
>> distinct components ?
>
> i don't see how that would be logically possible at all as long as the
> rest of qt is released as a monolithic product and at the same time some
> qt modules depend on the prospective outliers. you would have to view
> the outlier as an external dependency, but that doesn't work because it
> depends on other qt modules, so it's circular.

I would be possible to pin sha1 in qt5.git from the tip of current stable branch
of the module, in the same manner as it's done now (except branch name
will be different and may be upgraded between Qt's patch releases)

As long as superbuild works, I don't see any technical problem with the
"circular" dependency.

>
> for additional illustration, consider jira: due to the differing
> versioning, you cannot use components for the outliers, but need
> separate products.

That's true.

>
> as atomizing the release of most qt modules is totally unrealistic and
> counterproductive, there isn't a way forward to arrive at a consistent
> model which would accomodate that.

Why?

For example, GNOME has a platform consisting of lots of libraries with
independent versioning and release schedules, and it works because
these libraries provide certain API/ABI guarantees

>
> oh, and then there are the processes for creating an actual release.
> have fun "forking" these for separate products ...
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Oswald Buddenhagen]

On Wed, May 10, 2017 at 09:53:26AM +0200, Edward Welbourne wrote:
>Oswald Buddenhagen (4 May 2017 18:35)
>> i'll say outright that you can't be part of the qt supermodule and yet
>> have independent releases. while that was the plan once upon a time, the
>> whole release infrastructure simply doesn't deliver, and even just
>> diverging branch names are a pita (proved by enginio).
> 
>Can you elaborate on the pain here ?
> 
when the branch names are not uniform, they need to be derived from the
repositories' actual contents (.qmake.conf, in particular). and that has
historically been a mess because of lagging states due to late module
additions, tardy version updates, and delayed merges and qt5 integrations.

from the user perspective, diverging versions are a mess, because you
never know what belongs together. that was particularly annoying with
enginio, because there was no _reason_ for this being so.

>I note, in particular, that we do have sub-sub-modules on branches
>with eccentric names, or none 
>
these sub-modules' branches are completely desynchronized with qt, so
dealing with them is not part of the qt release cycle. qt simply pins
sha1s, and the modules are not directly in our CI.

>What would we need to do to our release infrastructure to make it
>cope with (as originally planned) independent release cycles for
>distinct components ?
> 
i don't see how that would be logically possible at all as long as the
rest of qt is released as a monolithic product and at the same time some
qt modules depend on the prospective outliers. you would have to view
the outlier as an external dependency, but that doesn't work because it
depends on other qt modules, so it's circular.

for additional illustration, consider jira: due to the differing
versioning, you cannot use components for the outliers, but need
separate products.

as atomizing the release of most qt modules is totally unrealistic and
counterproductive, there isn't a way forward to arrive at a consistent
model which would accomodate that.

oh, and then there are the processes for creating an actual release.
have fun "forking" these for separate products ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Edward Welbourne]

Oswald Buddenhagen (4 May 2017 18:35)
> i'll say outright that you can't be part of the qt supermodule and yet
> have independent releases. while that was the plan once upon a time, the
> whole release infrastructure simply doesn't deliver, and even just
> diverging branch names are a pita (proved by enginio).

Can you elaborate on the pain here ?

I note, in particular, that we do have sub-sub-modules on branches with
eccentric names, or none (that is, what we use isn't obviously following
any branch I can see).  We seem to cope.  I do confess life would be
easier with uniform branch names, but git submodule should take care of
most complications,.

What would we need to do to our release infrastructure to make it cope
with (as originally planned) independent release cycles for distinct
components ?

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

  08.05.2017, 15:11, "Lars Knoll" : On 5 May 2017, at 13:15, Konstantin Tokarev  wrote: 05.05.2017, 10:04, "Tuukka Turunen" :Hi,There has also been some interest also for getting Qt WebEngine to be released much faster cycle than Qt – exactly due to the security update need. Even if we succeed in making substantially more frequent Qt patch releases than before, it may still be better if user would have the option to update some parts (like QWE) more frequently or out of sync.I think what we should consider, is to perhaps carve out Qt WebEngine from Qt as well. Not immediately, but for Qt 6 we should anyway consider our current setup of essential and add-on modules. For the html5 engine there is the matter of binary size in addition to release frequency. This is not to say that we would stop developing html5 engine – just that it might be beneficial to do in in different way than currently.For new updated Qt Webkit, perhaps we could have it as a separate item that works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. After it has existed for a while as a separate item, it is also easier to know what would be the best way to get it into a Qt release – or is that even necessary.BTW, let me bring an attention to the elephant in the room.Yes, my fork of QtWebKit existed for a while as a separate item. But it was neverand "official" successor, and even me myself was warning people that it is not anofficial replacement as some features are not yet restored.However, now there is no valid reason to keep using QtWebKit contained in 5.9 anddev branches anymore. Feature parity is achieved to the level of drop-in replacementthat can be applied system-wide. Still many people see 5.9 branch as a source of truth. Yes, we have been keeping the old code compiling, but we have not been supporting it for a while, and it hasn’t been tested since then neither.We need to convey a message to wide audience that old QtWebKit should no longer beused, and that there is a new release that should be used instead. Not only with Qt 5.9.0,but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., Ubuntu 14.04). I agree here. We’ve kept the old Qt Webkit compiling against newer Qt version because of requests from the community. I think we can drop this now, and tell people to use your branch instead. It’ll certainly be better and safer than the old code base.This is why question about version numbers and related stuff is important. If this is notdone, it doesn't matter at all whatever tag names will be picked and what schedules willbe followed. I have no problems dropping the old qtwebkit code base and tell people to move over to use your branch.  One option is that we do not provide any source package from the old code base for qtwebkit with Qt 5.9 anymore. This would free up the version numbers from 5.9 onwards.So I assume it's OK to use 5.9 number for QtWebKit relese that is coming now, right?  At the same time I do agree with Tuukka, that we need to reconsider the coupling between webkit/webengine and Qt releases. if current QtWebkit runs nicely on top of Qt, maybe that’s how we should keep it. This would allow us to provide source/binary packages of it on a more independent schedule. Cheers,Lars   Yours,TuukkaOn 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev"  wrote:04.05.2017, 19:35, "Oswald Buddenhagen" :> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:>> 03.05.2017, 17:27, "Sergio Martins" :>> > On 2017-05-03 15:02, Konstantin Tokarev wrote:>> >> Remaining question is versioning. While it's fine to dub current>> >> release "5.9" (but not 5.0, because we will have another WebKit update>> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:>> >>>> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,>> >> or is updated>> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt>> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from>> >> 5.2 as of now), and can be used e.g. as security update in Linux>> >> distro that does not normally update Qt version during its life cycle.>> >>>> >> Any comments?>> >>> > If Qt and QtWebKit will have different release schedules then that>> > numbering would indeed confuse people.>>>> What about choice of new versioning scheme?>>>> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes it>> clear that versioning is different now. Bug fixes will increment patch version (6.0.x),>> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major>> verison (7.0 etc.)>>>> Qt5 supermodule will be tracking latest 

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

08.05.2017, 15:22, "Lars Knoll" <lars.kn...@qt.io>:
>> On 8 May 2017, at 13:37, Jani Heikkinen <jani.heikki...@qt.io> wrote:
>>
>> Couple of comments below
>>
>> br,
>> Jani
>>
>>> -Original Message-
>>> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
>>> project.org] On Behalf Of Konstantin Tokarev
>>> Sent: maanantaina 8. toukokuuta 2017 12.56
>>> To: Tuukka Turunen <tuukka.turu...@qt.io>; Oswald Buddenhagen
>>> <oswald.buddenha...@qt.io>; development@qt-project.org
>>> Subject: Re: [Development] QtWebKit is coming back (part 2)
>>>
>>> 05.05.2017, 14:15, "Konstantin Tokarev" <annu...@yandex.ru>:
>>>> 05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
>>>>>  Hi,
>>>>>
>>>>>  There has also been some interest also for getting Qt WebEngine to be
>>> released much faster cycle than Qt – exactly due to the security update 
>>> need.
>>> Even if we succeed in making substantially more frequent Qt patch releases
>>> than before, it may still be better if user would have the option to update
>>> some parts (like QWE) more frequently or out of sync.
>>>
>>>>>  I think what we should consider, is to perhaps carve out Qt WebEngine
>>> from Qt as well. Not immediately, but for Qt 6 we should anyway consider
>>> our current setup of essential and add-on modules. For the html5 engine
>>> there is the matter of binary size in addition to release frequency. This 
>>> is not
>>> to say that we would stop developing html5 engine – just that it might be
>>> beneficial to do in in different way than currently.
>>>
>>>>>  For new updated Qt Webkit, perhaps we could have it as a separate item
>>> that works on top of Qt 5.9 for those to use it who prefer it over Qt
>>> WebEngine. After it has existed for a while as a separate item, it is also 
>>> easier
>>> to know what would be the best way to get it into a Qt release – or is that
>>> even necessary.
>>>
>>>> BTW, let me bring an attention to the elephant in the room.
>>>>
>>>> Yes, my fork of QtWebKit existed for a while as a separate item. But
>>>> it was never and "official" successor, and even me myself was warning
>>>> people that it is not an official replacement as some features are not yet
>>> restored.
>>>
>>>> However, now there is no valid reason to keep using QtWebKit contained
>>>> in 5.9 and dev branches anymore. Feature parity is achieved to the
>>>> level of drop-in replacement that can be applied system-wide. Still many
>>> people see 5.9 branch as a source of truth.
>>>
>>>> We need to convey a message to wide audience that old QtWebKit should
>>>> no longer be used, and that there is a new release that should be used
>>>> instead. Not only with Qt 5.9.0, but also with older Qt releases, down to 
>>>> Qt
>>> 5.2.x if people still use it (e.g., Ubuntu 14.04).
>>>
>>>> This is why question about version numbers and related stuff is
>>>> important. If this is not done, it doesn't matter at all whatever tag
>>>> names will be picked and what schedules will be followed.
>>>
>>> Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even 
>>> does
>>> not exist, I think it should be to make exceptions in branch and release
>>> management policies for
>>> 5.9 and 5.9.0 branches, solely to resolve situation described above.
>>
>> Actually 'old ' webkit is in our builds but not part of official releases, 
>> see e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162
>> That is because we have agreed to keep it working and deliver src packages 
>> for the releases as well. Not part of official release but in addition.
>
> As I said in my other mail, we could easily drop those unsupported packages. 
> Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they 
> do, there’s no need at all to release packages that are the same, but remove 
> the option of using the new version number for the updated engine.
>>> I propose the following plan:
>>>
>>> 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond 
>>> to
>>> "alpha" release, that has feature parity, but is not yet guaranteed to be
>>> polished enough.
&g

Re: [Development] QtWebKit is coming back (part 2)

[Lars Knoll]

On 8 May 2017, at 13:37, Jani Heikkinen 
<jani.heikki...@qt.io<mailto:jani.heikki...@qt.io>> wrote:

Couple of comments below

br,
Jani

-Original Message-
From: Development 
[mailto:development-bounces+jani.heikkinen=qt.io<http://qt.io/>@qt-
project.org<http://project.org/>] On Behalf Of Konstantin Tokarev
Sent: maanantaina 8. toukokuuta 2017 12.56
To: Tuukka Turunen <tuukka.turu...@qt.io<mailto:tuukka.turu...@qt.io>>; Oswald 
Buddenhagen
<oswald.buddenha...@qt.io<mailto:oswald.buddenha...@qt.io>>; 
development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] QtWebKit is coming back (part 2)



05.05.2017, 14:15, "Konstantin Tokarev" 
<annu...@yandex.ru<mailto:annu...@yandex.ru>>:
05.05.2017, 10:04, "Tuukka Turunen" 
<tuukka.turu...@qt.io<mailto:tuukka.turu...@qt.io>>:
 Hi,

 There has also been some interest also for getting Qt WebEngine to be
released much faster cycle than Qt – exactly due to the security update need.
Even if we succeed in making substantially more frequent Qt patch releases
than before, it may still be better if user would have the option to update
some parts (like QWE) more frequently or out of sync.

 I think what we should consider, is to perhaps carve out Qt WebEngine
from Qt as well. Not immediately, but for Qt 6 we should anyway consider
our current setup of essential and add-on modules. For the html5 engine
there is the matter of binary size in addition to release frequency. This is not
to say that we would stop developing html5 engine – just that it might be
beneficial to do in in different way than currently.

 For new updated Qt Webkit, perhaps we could have it as a separate item
that works on top of Qt 5.9 for those to use it who prefer it over Qt
WebEngine. After it has existed for a while as a separate item, it is also 
easier
to know what would be the best way to get it into a Qt release – or is that
even necessary.

BTW, let me bring an attention to the elephant in the room.

Yes, my fork of QtWebKit existed for a while as a separate item. But
it was never and "official" successor, and even me myself was warning
people that it is not an official replacement as some features are not yet
restored.

However, now there is no valid reason to keep using QtWebKit contained
in 5.9 and dev branches anymore. Feature parity is achieved to the
level of drop-in replacement that can be applied system-wide. Still many
people see 5.9 branch as a source of truth.

We need to convey a message to wide audience that old QtWebKit should
no longer be used, and that there is a new release that should be used
instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt
5.2.x if people still use it (e.g., Ubuntu 14.04).

This is why question about version numbers and related stuff is
important. If this is not done, it doesn't matter at all whatever tag
names will be picked and what schedules will be followed.

Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does
not exist, I think it should be to make exceptions in branch and release
management policies for
5.9 and 5.9.0 branches, solely to resolve situation described above.

Actually 'old ' webkit is in our builds but not part of official releases, see 
e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162
That is because we have agreed to keep it working and deliver src packages for 
the releases as well. Not part of official release but in addition.

As I said in my other mail, we could easily drop those unsupported packages. 
Maybe quickly check whether the 5.8 packages compile against Qt 5.9. If they 
do, there’s no need at all to release packages that are the same, but remove 
the option of using the new version number for the updated engine.


I propose the following plan:

1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to
"alpha" release, that has feature parity, but is not yet guaranteed to be
polished enough.
To be honest, I don't want to do this now. From release schedule point of view 
it is just too late, we cannot risk our Qt 5.9.0 release schedule because of 
this. At this point 5.10 should be enough. For me it is ok if you want to add 
TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of 
official ci builds in '5.9.x' it is too risky.

Yes, we can’t couple this to our Qt 5.9 release. It clearly comes too late for 
that.

In addition, I am not convinced it’s a too good idea, we were never really 
happy with that tight coupling for our web engine(s) in the past. So I’d 
propose we rather first try to figure out if we can keep those decoupled from a 
releasing perspective. This might create some challenges in how we handle 
things from a packaging/CI side, but working through those items might be 
helpful in the longer term, and something we could then 

Re: [Development] QtWebKit is coming back (part 2)

[Jani Heikkinen]

Couple of comments below

br,
Jani

> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Konstantin Tokarev
> Sent: maanantaina 8. toukokuuta 2017 12.56
> To: Tuukka Turunen <tuukka.turu...@qt.io>; Oswald Buddenhagen
> <oswald.buddenha...@qt.io>; development@qt-project.org
> Subject: Re: [Development] QtWebKit is coming back (part 2)
> 
> 
> 
> 05.05.2017, 14:15, "Konstantin Tokarev" <annu...@yandex.ru>:
> > 05.05.2017, 10:04, "Tuukka Turunen" <tuukka.turu...@qt.io>:
> >>  Hi,
> >>
> >>  There has also been some interest also for getting Qt WebEngine to be
> released much faster cycle than Qt – exactly due to the security update need.
> Even if we succeed in making substantially more frequent Qt patch releases
> than before, it may still be better if user would have the option to update
> some parts (like QWE) more frequently or out of sync.
> >>
> >>  I think what we should consider, is to perhaps carve out Qt WebEngine
> from Qt as well. Not immediately, but for Qt 6 we should anyway consider
> our current setup of essential and add-on modules. For the html5 engine
> there is the matter of binary size in addition to release frequency. This is 
> not
> to say that we would stop developing html5 engine – just that it might be
> beneficial to do in in different way than currently.
> >>
> >>  For new updated Qt Webkit, perhaps we could have it as a separate item
> that works on top of Qt 5.9 for those to use it who prefer it over Qt
> WebEngine. After it has existed for a while as a separate item, it is also 
> easier
> to know what would be the best way to get it into a Qt release – or is that
> even necessary.
> >
> > BTW, let me bring an attention to the elephant in the room.
> >
> > Yes, my fork of QtWebKit existed for a while as a separate item. But
> > it was never and "official" successor, and even me myself was warning
> > people that it is not an official replacement as some features are not yet
> restored.
> >
> > However, now there is no valid reason to keep using QtWebKit contained
> > in 5.9 and dev branches anymore. Feature parity is achieved to the
> > level of drop-in replacement that can be applied system-wide. Still many
> people see 5.9 branch as a source of truth.
> >
> > We need to convey a message to wide audience that old QtWebKit should
> > no longer be used, and that there is a new release that should be used
> > instead. Not only with Qt 5.9.0, but also with older Qt releases, down to Qt
> 5.2.x if people still use it (e.g., Ubuntu 14.04).
> >
> > This is why question about version numbers and related stuff is
> > important. If this is not done, it doesn't matter at all whatever tag
> > names will be picked and what schedules will be followed.
> 
> Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does
> not exist, I think it should be to make exceptions in branch and release
> management policies for
> 5.9 and 5.9.0 branches, solely to resolve situation described above.

Actually 'old ' webkit is in our builds but not part of official releases, see 
e.g https://testresults.qt.io/coin/integration/qt/qt5/tasks/1494068162
That is because we have agreed to keep it working and deliver src packages for 
the releases as well. Not part of official release but in addition. 

> 
> I propose the following plan:
> 
> 1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to
> "alpha" release, that has feature parity, but is not yet guaranteed to be
> polished enough.
To be honest, I don't want to do this now. From release schedule point of view 
it is just too late, we cannot risk our Qt 5.9.0 release schedule because of 
this. At this point 5.10 should be enough. For me it is ok if you want to add 
TP/Alpha etc in http://download.qt.io/community_releases/5.9/ but being part of 
official ci builds in '5.9.x' it is too risky.

> 2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha
> release at http://download.qt.io/community_releases/5.9/
This should be OK as well


> 3. For dev branch, follow all necessary procedures to change status of
> QtWebKit and make it work for Qt 5.10 without any schedule exceptions.
> 
> [1] http://doc.qt.io/qt-5/qtmodules.html
> 
> >
> >>  Yours,
> >>
> >>  Tuukka
> >>
> >>  On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev"
> <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of
> annu...@yandex.ru> wrote:
> >>
>

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

05.05.2017, 14:15, "Konstantin Tokarev" :
> 05.05.2017, 10:04, "Tuukka Turunen" :
>>  Hi,
>>
>>  There has also been some interest also for getting Qt WebEngine to be 
>> released much faster cycle than Qt – exactly due to the security update 
>> need. Even if we succeed in making substantially more frequent Qt patch 
>> releases than before, it may still be better if user would have the option 
>> to update some parts (like QWE) more frequently or out of sync.
>>
>>  I think what we should consider, is to perhaps carve out Qt WebEngine from 
>> Qt as well. Not immediately, but for Qt 6 we should anyway consider our 
>> current setup of essential and add-on modules. For the html5 engine there is 
>> the matter of binary size in addition to release frequency. This is not to 
>> say that we would stop developing html5 engine – just that it might be 
>> beneficial to do in in different way than currently.
>>
>>  For new updated Qt Webkit, perhaps we could have it as a separate item that 
>> works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
>> After it has existed for a while as a separate item, it is also easier to 
>> know what would be the best way to get it into a Qt release – or is that 
>> even necessary.
>
> BTW, let me bring an attention to the elephant in the room.
>
> Yes, my fork of QtWebKit existed for a while as a separate item. But it was 
> never
> and "official" successor, and even me myself was warning people that it is 
> not an
> official replacement as some features are not yet restored.
>
> However, now there is no valid reason to keep using QtWebKit contained in 5.9 
> and
> dev branches anymore. Feature parity is achieved to the level of drop-in 
> replacement
> that can be applied system-wide. Still many people see 5.9 branch as a source 
> of truth.
>
> We need to convey a message to wide audience that old QtWebKit should no 
> longer be
> used, and that there is a new release that should be used instead. Not only 
> with Qt 5.9.0,
> but also with older Qt releases, down to Qt 5.2.x if people still use it 
> (e.g., Ubuntu 14.04).
>
> This is why question about version numbers and related stuff is important. If 
> this is not
> done, it doesn't matter at all whatever tag names will be picked and what 
> schedules will
> be followed.

Since Qt 5.6 QtWebKit is in "removed" state and according to [1] it even does 
not exist,
I think it should be to make exceptions in branch and release management 
policies for
5.9 and 5.9.0 branches, solely to resolve situation described above.

I propose the following plan:

1. Merge wip/next into 5.9.0, 5.9, and dev. 5.9.0 contents will correspond to 
"alpha" release,
that has feature parity, but is not yet guaranteed to be polished enough.
2. Host sources and binaries of QtWebKit corresponding to 5.9.0-alpha release at
http://download.qt.io/community_releases/5.9/
3. For dev branch, follow all necessary procedures to change status of QtWebKit 
and make
it work for Qt 5.10 without any schedule exceptions.

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

>
>>  Yours,
>>
>>  Tuukka
>>
>>  On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
>> > annu...@yandex.ru> wrote:
>>
>>  04.05.2017, 19:35, "Oswald Buddenhagen" :
>>  > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  >> 03.05.2017, 17:27, "Sergio Martins" :
>>  >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >> >> Remaining question is versioning. While it's fine to dub current
>>  >> >> release "5.9" (but not 5.0, because we will have another WebKit 
>> update
>>  >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >> >>
>>  >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
>> 5.N,
>>  >> >> or is updated
>>  >> >> 2. It makes people believe that QtWebKit 5.N should be used with 
>> Qt
>>  >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting 
>> from
>>  >> >> 5.2 as of now), and can be used e.g. as security update in Linux
>>  >> >> distro that does not normally update Qt version during its life 
>> cycle.
>>  >> >>
>>  >> >> Any comments?
>>  >> >
>>  >> > If Qt and QtWebKit will have different release schedules then that
>>  >> > numbering would indeed confuse people.
>>  >>
>>  >> What about choice of new versioning scheme?
>>  >>
>>  >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
>> and makes it
>>  >> clear that versioning is different now. Bug fixes will increment 
>> patch version (6.0.x),
>>  >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
>> major
>>  >> verison (7.0 etc.)
>>  >>
>>  >> Qt5 supermodule will be tracking latest 

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

05.05.2017, 10:04, "Tuukka Turunen" :
> Hi,
>
> There has also been some interest also for getting Qt WebEngine to be 
> released much faster cycle than Qt – exactly due to the security update need. 
> Even if we succeed in making substantially more frequent Qt patch releases 
> than before, it may still be better if user would have the option to update 
> some parts (like QWE) more frequently or out of sync.
>
> I think what we should consider, is to perhaps carve out Qt WebEngine from Qt 
> as well. Not immediately, but for Qt 6 we should anyway consider our current 
> setup of essential and add-on modules. For the html5 engine there is the 
> matter of binary size in addition to release frequency. This is not to say 
> that we would stop developing html5 engine – just that it might be beneficial 
> to do in in different way than currently.
>
> For new updated Qt Webkit, perhaps we could have it as a separate item that 
> works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
> After it has existed for a while as a separate item, it is also easier to 
> know what would be the best way to get it into a Qt release – or is that even 
> necessary.

BTW, let me bring an attention to the elephant in the room.

Yes, my fork of QtWebKit existed for a while as a separate item. But it was 
never
and "official" successor, and even me myself was warning people that it is not 
an
official replacement as some features are not yet restored.

However, now there is no valid reason to keep using QtWebKit contained in 5.9 
and
dev branches anymore. Feature parity is achieved to the level of drop-in 
replacement
that can be applied system-wide. Still many people see 5.9 branch as a source 
of truth.

We need to convey a message to wide audience that old QtWebKit should no longer 
be
used, and that there is a new release that should be used instead. Not only 
with Qt 5.9.0,
but also with older Qt releases, down to Qt 5.2.x if people still use it (e.g., 
Ubuntu 14.04).

This is why question about version numbers and related stuff is important. If 
this is not
done, it doesn't matter at all whatever tag names will be picked and what 
schedules will
be followed.

>
> Yours,
>
> Tuukka
>
> On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
>  annu...@yandex.ru> wrote:
>
> 04.05.2017, 19:35, "Oswald Buddenhagen" :
> > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
> >> 03.05.2017, 17:27, "Sergio Martins" :
> >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >> >> Remaining question is versioning. While it's fine to dub current
> >> >> release "5.9" (but not 5.0, because we will have another WebKit 
> update
> >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >> >>
> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
> 5.N,
> >> >> or is updated
> >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt
> >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from
> >> >> 5.2 as of now), and can be used e.g. as security update in Linux
> >> >> distro that does not normally update Qt version during its life 
> cycle.
> >> >>
> >> >> Any comments?
> >> >
> >> > If Qt and QtWebKit will have different release schedules then that
> >> > numbering would indeed confuse people.
> >>
> >> What about choice of new versioning scheme?
> >>
> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
> and makes it
> >> clear that versioning is different now. Bug fixes will increment patch 
> version (6.0.x),
> >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
> major
> >> verison (7.0 etc.)
> >>
> >> Qt5 supermodule will be tracking latest available stable branch. When 
> release branch
> >> is created (e.g. 5.10.0), corresponding patch release branch is 
> created in qtwebkit
> >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt 
> release branches.
> >>
> >> However, I'm not sure about two things:
> >> 1) Is it possible to have custom branch names in qtwebkit repository, 
> or there need to
> >> be virtual 5.10 etc. branches to match other modules?
> >> 2) What about bug tracking in JIRA? I would like to keep existing 
> issues as is, but assing
> >> new release numbers to items fixed in new releases
> >
> > i'll say outright that you can't be part of the qt supermodule and yet
> > have independent releases. while that was the plan once upon a time, the
> > whole release infrastructure simply doesn't deliver, and even just
> > diverging branch names are a pita (proved by enginio). as a product, qt
> > is as monolithic as ever.
>

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

05.05.2017, 10:04, "Tuukka Turunen" :
> Hi,
>
> There has also been some interest also for getting Qt WebEngine to be 
> released much faster cycle than Qt – exactly due to the security update need. 
> Even if we succeed in making substantially more frequent Qt patch releases 
> than before, it may still be better if user would have the option to update 
> some parts (like QWE) more frequently or out of sync.
>
> I think what we should consider, is to perhaps carve out Qt WebEngine from Qt 
> as well. Not immediately, but for Qt 6 we should anyway consider our current 
> setup of essential and add-on modules. For the html5 engine there is the 
> matter of binary size in addition to release frequency. This is not to say 
> that we would stop developing html5 engine – just that it might be beneficial 
> to do in in different way than currently.
>
> For new updated Qt Webkit, perhaps we could have it as a separate item that 
> works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
> After it has existed for a while as a separate item, it is also easier to 
> know what would be the best way to get it into a Qt release – or is that even 
> necessary.

Note that qttools submodule depends on QtWebKit (for proper HTML rendering in 
Qt Assistant). Also, QtWebEngine is require for QtWebView module on 
Windows/MSVC. BTW, currently QtWebView is unavailable for Windows/MinGW, so it 
would make sense to add QtWebKit backend as well.

That's one reason why we cannot just exclude QtWebKit and QtWebEngine from qt5 
supermodule. Other reason is that Coin doesn't seem to be ready to support 
building projects other than qt5 and its submodules. 

>
> Yours,
>
> Tuukka
>
> On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
>  annu...@yandex.ru> wrote:
>
> 04.05.2017, 19:35, "Oswald Buddenhagen" :
> > On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
> >> 03.05.2017, 17:27, "Sergio Martins" :
> >> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >> >> Remaining question is versioning. While it's fine to dub current
> >> >> release "5.9" (but not 5.0, because we will have another WebKit 
> update
> >> >> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >> >>
> >> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
> 5.N,
> >> >> or is updated
> >> >> 2. It makes people believe that QtWebKit 5.N should be used with Qt
> >> >> 5.N only. QtWebKit supports wide range of Qt versions (starting from
> >> >> 5.2 as of now), and can be used e.g. as security update in Linux
> >> >> distro that does not normally update Qt version during its life 
> cycle.
> >> >>
> >> >> Any comments?
> >> >
> >> > If Qt and QtWebKit will have different release schedules then that
> >> > numbering would indeed confuse people.
> >>
> >> What about choice of new versioning scheme?
> >>
> >> I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
> and makes it
> >> clear that versioning is different now. Bug fixes will increment patch 
> version (6.0.x),
> >> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
> major
> >> verison (7.0 etc.)
> >>
> >> Qt5 supermodule will be tracking latest available stable branch. When 
> release branch
> >> is created (e.g. 5.10.0), corresponding patch release branch is 
> created in qtwebkit
> >> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt 
> release branches.
> >>
> >> However, I'm not sure about two things:
> >> 1) Is it possible to have custom branch names in qtwebkit repository, 
> or there need to
> >> be virtual 5.10 etc. branches to match other modules?
> >> 2) What about bug tracking in JIRA? I would like to keep existing 
> issues as is, but assing
> >> new release numbers to items fixed in new releases
> >
> > i'll say outright that you can't be part of the qt supermodule and yet
> > have independent releases. while that was the plan once upon a time, the
> > whole release infrastructure simply doesn't deliver, and even just
> > diverging branch names are a pita (proved by enginio). as a product, qt
> > is as monolithic as ever.
>
> Understood: no custom branch/tag names in official repo.
>
> >
> > your release cycle concerns seem to be centered around the webkit
> > backend, and you can deal with that by lowering the compatibility
> > guarantees of patch releases at this level, i.e. take the freedom to
> > upgrade webkit in a patch release. as long as you keep qt's api/abi
> > compat promises, you're fine. that means that you will not be able to
> > expose new webkit features until the next minor release if they 

Re: [Development] QtWebKit is coming back (part 2)

[Tuukka Turunen]

Hi,

There has also been some interest also for getting Qt WebEngine to be released 
much faster cycle than Qt – exactly due to the security update need. Even if we 
succeed in making substantially more frequent Qt patch releases than before, it 
may still be better if user would have the option to update some parts (like 
QWE) more frequently or out of sync. 

I think what we should consider, is to perhaps carve out Qt WebEngine from Qt 
as well. Not immediately, but for Qt 6 we should anyway consider our current 
setup of essential and add-on modules. For the html5 engine there is the matter 
of binary size in addition to release frequency. This is not to say that we 
would stop developing html5 engine – just that it might be beneficial to do in 
in different way than currently. 

For new updated Qt Webkit, perhaps we could have it as a separate item that 
works on top of Qt 5.9 for those to use it who prefer it over Qt WebEngine. 
After it has existed for a while as a separate item, it is also easier to know 
what would be the best way to get it into a Qt release – or is that even 
necessary. 

Yours,

Tuukka

On 04/05/2017, 22.26, "Development on behalf of Konstantin Tokarev" 
 wrote:
   

04.05.2017, 19:35, "Oswald Buddenhagen" :
> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  03.05.2017, 17:27, "Sergio Martins" :
>>  > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >>  Remaining question is versioning. While it's fine to dub current
>>  >>  release "5.9" (but not 5.0, because we will have another WebKit 
update
>>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >>
>>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 
5.N,
>>  >>  or is updated
>>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  >>  5.2 as of now), and can be used e.g. as security update in Linux
>>  >>  distro that does not normally update Qt version during its life 
cycle.
>>  >>
>>  >>  Any comments?
>>  >
>>  > If Qt and QtWebKit will have different release schedules then that
>>  > numbering would indeed confuse people.
>>
>>  What about choice of new versioning scheme?
>>
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x 
and makes it
>>  clear that versioning is different now. Bug fixes will increment patch 
version (6.0.x),
>>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
major
>>  verison (7.0 etc.)
>>
>>  Qt5 supermodule will be tracking latest available stable branch. When 
release branch
>>  is created (e.g. 5.10.0), corresponding patch release branch is created 
in qtwebkit
>>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt 
release branches.
>>
>>  However, I'm not sure about two things:
>>  1) Is it possible to have custom branch names in qtwebkit repository, 
or there need to
>>  be virtual 5.10 etc. branches to match other modules?
>>  2) What about bug tracking in JIRA? I would like to keep existing 
issues as is, but assing
>>  new release numbers to items fixed in new releases
>
> i'll say outright that you can't be part of the qt supermodule and yet
> have independent releases. while that was the plan once upon a time, the
> whole release infrastructure simply doesn't deliver, and even just
> diverging branch names are a pita (proved by enginio). as a product, qt
> is as monolithic as ever.

Understood: no custom branch/tag names in official repo.

>
> your release cycle concerns seem to be centered around the webkit
> backend, and you can deal with that by lowering the compatibility
> guarantees of patch releases at this level, i.e. take the freedom to
> upgrade webkit in a patch release. as long as you keep qt's api/abi
> compat promises, you're fine. that means that you will not be able to
> expose new webkit features until the next minor release if they require
> new api.

That's probably fine with me, except 2 moments that seem to require "out of 
band" releases:

1. Something should be done with current release. As I said, it's not an 
option to postpone
it to 5.10, however it also cannot be released as 5.9.1 because there are 
API additions
which I don't want to revert (in particular because these APIs were already 
shipped by
Linux distros that chose to provide TP4 and TP5). Also there is a change in 
QDataStream
format of QWebHistory.

2. Security updates. WebKitGTK team provides several patch releases for 
each stable branch,
which contain only fixes for 

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 19:35, "Oswald Buddenhagen" :
> On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
>>  03.05.2017, 17:27, "Sergio Martins" :
>>  > On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  >>  Remaining question is versioning. While it's fine to dub current
>>  >>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>  >>
>>  >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  >>  or is updated
>>  >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  >>  5.2 as of now), and can be used e.g. as security update in Linux
>>  >>  distro that does not normally update Qt version during its life cycle.
>>  >>
>>  >>  Any comments?
>>  >
>>  > If Qt and QtWebKit will have different release schedules then that
>>  > numbering would indeed confuse people.
>>
>>  What about choice of new versioning scheme?
>>
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and 
>> makes it
>>  clear that versioning is different now. Bug fixes will increment patch 
>> version (6.0.x),
>>  WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
>>  verison (7.0 etc.)
>>
>>  Qt5 supermodule will be tracking latest available stable branch. When 
>> release branch
>>  is created (e.g. 5.10.0), corresponding patch release branch is created in 
>> qtwebkit
>>  repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
>> branches.
>>
>>  However, I'm not sure about two things:
>>  1) Is it possible to have custom branch names in qtwebkit repository, or 
>> there need to
>>  be virtual 5.10 etc. branches to match other modules?
>>  2) What about bug tracking in JIRA? I would like to keep existing issues as 
>> is, but assing
>>  new release numbers to items fixed in new releases
>
> i'll say outright that you can't be part of the qt supermodule and yet
> have independent releases. while that was the plan once upon a time, the
> whole release infrastructure simply doesn't deliver, and even just
> diverging branch names are a pita (proved by enginio). as a product, qt
> is as monolithic as ever.

Understood: no custom branch/tag names in official repo.

>
> your release cycle concerns seem to be centered around the webkit
> backend, and you can deal with that by lowering the compatibility
> guarantees of patch releases at this level, i.e. take the freedom to
> upgrade webkit in a patch release. as long as you keep qt's api/abi
> compat promises, you're fine. that means that you will not be able to
> expose new webkit features until the next minor release if they require
> new api.

That's probably fine with me, except 2 moments that seem to require "out of 
band" releases:

1. Something should be done with current release. As I said, it's not an option 
to postpone
it to 5.10, however it also cannot be released as 5.9.1 because there are API 
additions
which I don't want to revert (in particular because these APIs were already 
shipped by
Linux distros that chose to provide TP4 and TP5). Also there is a change in 
QDataStream
format of QWebHistory.

2. Security updates. WebKitGTK team provides several patch releases for each 
stable branch,
which contain only fixes for bugs and security issues, and towards the end of 
release life cycle
they became primarily security updates. I think we should be able to release 
such updates ASAP,
by making up some tag name and scheduling custom build against newest patch 
release of Qt.

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Oswald Buddenhagen]

On Thu, May 04, 2017 at 04:51:45PM +0300, Konstantin Tokarev wrote:
> 03.05.2017, 17:27, "Sergio Martins" :
> > On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >>  Remaining question is versioning. While it's fine to dub current
> >>  release "5.9" (but not 5.0, because we will have another WebKit update
> >>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >>
> >>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
> >>  or is updated
> >>  2. It makes people believe that QtWebKit 5.N should be used with Qt
> >>  5.N only. QtWebKit supports wide range of Qt versions (starting from
> >>  5.2 as of now), and can be used e.g. as security update in Linux
> >>  distro that does not normally update Qt version during its life cycle.
> >>
> >>  Any comments?
> >
> > If Qt and QtWebKit will have different release schedules then that
> > numbering would indeed confuse people.
> 
> What about choice of new versioning scheme?
> 
> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and 
> makes it
> clear that versioning is different now. Bug fixes will increment patch 
> version (6.0.x),
> WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
> verison (7.0 etc.)
> 
> Qt5 supermodule will be tracking latest available stable branch. When release 
> branch
> is created (e.g. 5.10.0), corresponding patch release branch is created in 
> qtwebkit
> repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
> branches.
> 
> However, I'm not sure about two things:
> 1) Is it possible to have custom branch names in qtwebkit repository, or 
> there need to
> be virtual 5.10 etc. branches to match other modules?
> 2) What about bug tracking in JIRA? I would like to keep existing issues as 
> is, but assing
> new release numbers to items fixed in new releases
> 
i'll say outright that you can't be part of the qt supermodule and yet
have independent releases. while that was the plan once upon a time, the
whole release infrastructure simply doesn't deliver, and even just
diverging branch names are a pita (proved by enginio). as a product, qt
is as monolithic as ever.

your release cycle concerns seem to be centered around the webkit
backend, and you can deal with that by lowering the compatibility
guarantees of patch releases at this level, i.e. take the freedom to
upgrade webkit in a patch release. as long as you keep qt's api/abi
compat promises, you're fine. that means that you will not be able to
expose new webkit features until the next minor release if they require
new api.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 07:21:03 PDT, Konstantin Tokarev 
escreveu:
> Yes. But using 5.$large_number seems wrong too, because there is no hard
> upper limit for Qt 5.x series

No, but it's highly unlikely we'll get to 5.20 or 5.100.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Sergio Martins]

On 2017-05-04 14:51, Konstantin Tokarev wrote:

03.05.2017, 17:27, "Sergio Martins" :

On 2017-05-03 15:02, Konstantin Tokarev wrote:

 Remaining question is versioning. While it's fine to dub current
 release "5.9" (but not 5.0, because we will have another WebKit 
update

 in 5.10 time frame), using Qt versions in QtWebKit has downsides:

 1. It is not clear if 5.N+1 ships with the same WebKit branch as 
5.N,

 or is updated
 2. It makes people believe that QtWebKit 5.N should be used with Qt
 5.N only. QtWebKit supports wide range of Qt versions (starting from
 5.2 as of now), and can be used e.g. as security update in Linux
 distro that does not normally update Qt version during its life 
cycle.


 Any comments?


If Qt and QtWebKit will have different release schedules then that
numbering would indeed confuse people.


What about choice of new versioning scheme?

I'm leaning towards "6.0.0" number, because it's larger than any 5.x
and makes it
clear that versioning is different now. Bug fixes will increment patch
version (6.0.x),
WebKit updates minor version (6.1.x etc), API/ABI breaking changes - 
major

verison (7.0 etc.)


If you go down that route just make sure 7.0 is out before Qt 6 is 
released, otherwise it's confusing too.


No idea about your other questions.



Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 17:17, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev
> escreveu:
>>  I'm leaning towards "6.0.0" number, because it's larger than any 5.x and
>>  makes it clear that versioning is different now. Bug fixes will increment
>>  patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI
>>  breaking changes - major verison (7.0 etc.)
>
> I thought you weren't breaking either source or binary compatibility.

Correct.

> So using a new major number sounds wrong.

Yes. But using 5.$large_number seems wrong too, because there is no hard
upper limit for Qt 5.x series

>
> And what would you do when Qt 6 gets released in a couple of years?

There will be QtWebKit 7.x by then, because there are some desirable changes
that would break ABI. There is no clear plan yet, though.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 06:51:45 PDT, Konstantin Tokarev 
escreveu:
> I'm leaning towards "6.0.0" number, because it's larger than any 5.x and
> makes it clear that versioning is different now. Bug fixes will increment
> patch version (6.0.x), WebKit updates minor version (6.1.x etc), API/ABI
> breaking changes - major verison (7.0 etc.)

I thought you weren't breaking either source or binary compatibility. So using 
a new major number sounds wrong.

And what would you do when Qt 6 gets released in a couple of years?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

04.05.2017, 16:52, "Thiago Macieira" :
> Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu:
>>  > I hope for this (if possible, in 5.9 with Technology preview status
>>
>>  I don't think adding new TP in 5.9 at this point isn't that wise anymore. We
>>  have agreed to get all these new submodules (also TP ones) in before FF and
>>  so on 5.10 is first option.
>
> Fair enough, but QtWebKit can release a TP a little afterwards and just say
> it's compatible with Qt 5.9.

Will it be possbile to get binary packages into repositories of online SDK 
updater?

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quinta-feira, 4 de maio de 2017, às 00:17:30 PDT, Jani Heikkinen escreveu:
> > I hope for this (if possible, in 5.9 with Technology preview status 
> 
> I don't think adding new TP in 5.9 at this point isn't that wise anymore. We
> have agreed to get all these new submodules (also TP ones) in before FF and
> so on 5.10 is first option.

Fair enough, but QtWebKit can release a TP a little afterwards and just say 
it's compatible with Qt 5.9.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 17:27, "Sergio Martins" :
> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  Remaining question is versioning. While it's fine to dub current
>>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  or is updated
>>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  5.2 as of now), and can be used e.g. as security update in Linux
>>  distro that does not normally update Qt version during its life cycle.
>>
>>  Any comments?
>
> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.

What about choice of new versioning scheme?

I'm leaning towards "6.0.0" number, because it's larger than any 5.x and makes 
it
clear that versioning is different now. Bug fixes will increment patch version 
(6.0.x),
WebKit updates minor version (6.1.x etc), API/ABI breaking changes - major
verison (7.0 etc.)

Qt5 supermodule will be tracking latest available stable branch. When release 
branch
is created (e.g. 5.10.0), corresponding patch release branch is created in 
qtwebkit
repo (e.g., 6.1.1) and is frozen following the same schedule as Qt release 
branches.

However, I'm not sure about two things:
1) Is it possible to have custom branch names in qtwebkit repository, or there 
need to
be virtual 5.10 etc. branches to match other modules?
2) What about bug tracking in JIRA? I would like to keep existing issues as is, 
but assing
new release numbers to items fixed in new releases



Rationale why using Qt version is not optimal anymore:

1. New QtWebKit is using stable branch of WebKitGTK to simplify maintenance, and
plan is to continue doing this in future. Currenly WebKitGTK creates new stable 
branch
twice a year and follows GNOME release schedule. While this more or less matches
Qt release schedule, there may be unfortunate cases when schedules mismatch, and
WebKit upgrade won't be possible in time. Keeping WebKit not upgraded increases
maintenance burden, because it's harder to cherry-pick patches from diverging 
trunk,
and it's not possible anymore to reuse backporting work of WebKitGTK team.

In case WebKit upgrade is finished before Qt release, it's highly desirable to 
allow
downstreams (e.g. Linux distros) to get newer version faster.

In case WebKit upgrade was skipped for some reason when new Qt release is
made, it's important to reflect this in version number as well

2. There may be schedule missses because of lacking man power in QtWebKit team.
Like now for example, release is long overdue and it's just unacceptable to 
hold it
for more than half of year again.

3. As I already mentioned in the starting message, surprisingly large number of 
people
believe that QtWebKit x.y is tied to Qt x.y, while it supports a range of Qt 
versions,
and can be used as security update in Linux distros that do not normally update 
Qt
version during their release life cycle.

Historically, QtWebKit always supported at least N-1 release of Qt, and 
versioning
scheme used in Qt 4 times since Qt 4.7 (QtWebKit 2.0 - 2.3) better reflected 
this fact.


>
> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update
> the inner WebKit, for security reasons, (that even happened for
> QtWebEngine in a 5.6.x patch release).
>
> Thanks for your efforts on this!
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Jani Heikkinen]

> -Original Message-
> From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> project.org] On Behalf Of Konstantin Tokarev
> Sent: keskiviikkona 3. toukokuuta 2017 18.14
> To: Adalid Claure <acla...@gmail.com>
> Cc: development@qt-project.org
> Subject: Re: [Development] QtWebKit is coming back (part 2)
> 
> 
> 
> 03.05.2017, 18:05, "Adalid Claure" <acla...@gmail.com>:
> > Does this mean that at some point this new QtWebKit would be packaged
> with Qt (like in the old days)?
> 
> I hope for this (if possible, in 5.9 with Technology preview status ;)
I don't think adding new TP in 5.9 at this point isn't that wise anymore. We 
have agreed to get all these new submodules (also TP ones) in before FF and so 
on 5.10 is first option. 

br,
Jani

> 
> Also note that you can already get binaries compatible with Qt 5.8.0 from
> 
> https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5
> 
> (but note that TP5 does not include QML API yet)
> 
> They are built in Coin just like official binaries packaged in Qt SDK.
> 
> >
> > On Wed, May 3, 2017 at 10:25 AM, Sergio Martins
> <sergio.mart...@kdab.com> wrote:
> >> On 2017-05-03 15:02, Konstantin Tokarev wrote:
> >> Remaining question is versioning. While it's fine to dub current
> >> release "5.9" (but not 5.0, because we will have another WebKit
> >> update in 5.10 time frame), using Qt versions in QtWebKit has downsides:
> >>
> >> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
> >> or is updated 2. It makes people believe that QtWebKit 5.N should be
> >> used with Qt 5.N only. QtWebKit supports wide range of Qt versions
> >> (starting from
> >> 5.2 as of now), and can be used e.g. as security update in Linux
> >> distro that does not normally update Qt version during its life cycle.
> >>
> >> Any comments?
> >>
> >> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.
> >>
> >> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update the
> inner WebKit, for security reasons, (that even happened for QtWebEngine in
> a 5.6.x patch release).
> >>
> >> Thanks for your efforts on this!
> >>
> >> Regards,
> >> --
> >> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> >> Klarälvdalens Datakonsult AB, a KDAB Group company
> >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB -
> The
> >> Qt, C++ and OpenGL Experts
> >>
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > ,
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> --
> Regards,
> Konstantin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 21:25, "Thiago Macieira" :
> Em quarta-feira, 3 de maio de 2017, às 10:55:49 PDT, Konstantin Tokarev
> escreveu:
>>  So, do you think we should update 5.6 branch of QtWebKit with wip/next
>>  contents, fix qmake wrapper project to work with Qt 5.6, and raise
>>  requirements to whatever it can require with Qt 5.9? That's fine with me.
>
> No, you should make a different LTS release that works with Qt 5.6.

OK

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quarta-feira, 3 de maio de 2017, às 10:55:49 PDT, Konstantin Tokarev 
escreveu:
> So, do you think we should update 5.6 branch of QtWebKit with wip/next
> contents, fix qmake wrapper project to work with Qt 5.6, and raise
> requirements to whatever it can require with Qt 5.9? That's fine with me.

No, you should make a different LTS release that works with Qt 5.6.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 20:44, "Thiago Macieira" :
> Em quarta-feira, 3 de maio de 2017, às 08:03:50 PDT, Konstantin Tokarev
> escreveu:
>>  I'm not sure it would be acceptable, because updated QtWebKit requires full
>>  C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
>>  features, or with code changes, which were not done yet).
>>
>>  Also, there are differences in supported platforms and system requirements.
>>
>>  macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is
>>  working fine on OS X 10.7, however the oldest officially supported version
>>  is 10.10 (as in upstream). I'm pretty sure that WK2 IPC with Mach ports
>>  will break when compiling for older targets, though it should be possible
>>  to switch to unix sockets just for 5.6.
>>
>>  Windows: Windows XP support seems to be feasible, if needed, without new
>>  MediaFoundation-based player. Will require backporting Conan-related patches
>>  in qt5.git to 5.6 branch.
>>
>>  Linux: GStreamer 0.10 is not supported, so official builds with video will
>>  have to use QtMultimedia MediaPlayer implementation.
>>
>>  I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now
>>  because of missing ICU. However, I guess it will be possible to reintroduce
>>  QNX support if there are interested folks here, at least Widgets API.
>
> None of those look like deal-breakers. You should be able to:
>  * require C++11 [*] and require newer compilers than 5.6 does
>  * drop support for older platforms (XP, macOS < 10.9, etc.)
>  * require upgraded libraries, like GStreamer
>
> Especially if you're going to do releases out of phase with Qt, it should be
> fine to require more than 5.6 did. And people should just accept it: if you're
> dealing with something that evolves rapidly and is a security-sensitive, you
> should be prepared to upgrade your environment quickly too.
>
> [*] actually, we should remove the option from configure.

So, do you think we should update 5.6 branch of QtWebKit with wip/next contents,
fix qmake wrapper project to work with Qt 5.6, and raise requirements to 
whatever it
can require with Qt 5.9? That's fine with me.

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Thiago Macieira]

Em quarta-feira, 3 de maio de 2017, às 08:03:50 PDT, Konstantin Tokarev 
escreveu:
> I'm not sure it would be acceptable, because updated QtWebKit requires full
> C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
> features, or with code changes, which were not done yet).
> 
> Also, there are differences in supported platforms and system requirements.
> 
> macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is
> working fine on OS X 10.7, however the oldest officially supported version
> is 10.10 (as in upstream). I'm pretty sure that WK2 IPC with Mach ports
> will break when compiling for older targets, though it should be possible
> to switch to unix sockets just for 5.6.
> 
> Windows: Windows XP support seems to be feasible, if needed, without new
> MediaFoundation-based player. Will require backporting Conan-related patches
> in qt5.git to 5.6 branch.
> 
> Linux: GStreamer 0.10 is not supported, so official builds with video will
> have to use QtMultimedia MediaPlayer implementation.
> 
> I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now
> because of missing ICU. However, I guess it will be possible to reintroduce
> QNX support if there are interested folks here, at least Widgets API.

None of those look like deal-breakers. You should be able to:
 * require C++11 [*] and require newer compilers than 5.6 does
 * drop support for older platforms (XP, macOS < 10.9, etc.)
 * require upgraded libraries, like GStreamer

Especially if you're going to do releases out of phase with Qt, it should be 
fine to require more than 5.6 did. And people should just accept it: if you're 
dealing with something that evolves rapidly and is a security-sensitive, you 
should be prepared to upgrade your environment quickly too.

[*] actually, we should remove the option from configure.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 18:05, "Adalid Claure" :
> Does this mean that at some point this new QtWebKit would be packaged with Qt 
> (like in the old days)?

I hope for this (if possible, in 5.9 with Technology preview status ;)

Also note that you can already get binaries compatible with Qt 5.8.0 from

https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5

(but note that TP5 does not include QML API yet)

They are built in Coin just like official binaries packaged in Qt SDK.

>
> On Wed, May 3, 2017 at 10:25 AM, Sergio Martins  
> wrote:
>> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>> Remaining question is versioning. While it's fine to dub current
>> release "5.9" (but not 5.0, because we will have another WebKit update
>> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>> or is updated
>> 2. It makes people believe that QtWebKit 5.N should be used with Qt
>> 5.N only. QtWebKit supports wide range of Qt versions (starting from
>> 5.2 as of now), and can be used e.g. as security update in Linux
>> distro that does not normally update Qt version during its life cycle.
>>
>> Any comments?
>>
>> If Qt and QtWebKit will have different release schedules then that numbering 
>> would indeed confuse people.
>>
>> Have you thought about an LTS version too ? What would LTS mean, for 
>> QtWebKit ? I think during the LTS lifetime we would still need to update the 
>> inner WebKit, for security reasons, (that even happened for QtWebEngine in a 
>> 5.6.x patch release).
>>
>> Thanks for your efforts on this!
>>
>> Regards,
>> --
>> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
>> Klarälvdalens Datakonsult AB, a KDAB Group company
>> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Adalid Claure]

Does this mean that at some point this new QtWebKit would be packaged with
Qt (like in the old days)?

On Wed, May 3, 2017 at 10:25 AM, Sergio Martins 
wrote:

> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>
>> Remaining question is versioning. While it's fine to dub current
>> release "5.9" (but not 5.0, because we will have another WebKit update
>> in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>> 1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>> or is updated
>> 2. It makes people believe that QtWebKit 5.N should be used with Qt
>> 5.N only. QtWebKit supports wide range of Qt versions (starting from
>> 5.2 as of now), and can be used e.g. as security update in Linux
>> distro that does not normally update Qt version during its life cycle.
>>
>> Any comments?
>>
>
> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.
>
> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update
> the inner WebKit, for security reasons, (that even happened for QtWebEngine
> in a 5.6.x patch release).
>
>
> Thanks for your efforts on this!
>
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

03.05.2017, 17:27, "Sergio Martins" :
> On 2017-05-03 15:02, Konstantin Tokarev wrote:
>>  Remaining question is versioning. While it's fine to dub current
>>  release "5.9" (but not 5.0, because we will have another WebKit update
>>  in 5.10 time frame), using Qt versions in QtWebKit has downsides:
>>
>>  1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
>>  or is updated
>>  2. It makes people believe that QtWebKit 5.N should be used with Qt
>>  5.N only. QtWebKit supports wide range of Qt versions (starting from
>>  5.2 as of now), and can be used e.g. as security update in Linux
>>  distro that does not normally update Qt version during its life cycle.
>>
>>  Any comments?
>
> If Qt and QtWebKit will have different release schedules then that
> numbering would indeed confuse people.
>
> Have you thought about an LTS version too ? What would LTS mean, for
> QtWebKit ? I think during the LTS lifetime we would still need to update
> the inner WebKit, for security reasons, (that even happened for
> QtWebEngine in a 5.6.x patch release).

I'm not sure it would be acceptable, because updated QtWebKit requires full
C++11 support in the compiler (gcc >= 4.9, 4.8 possible with disabling some
features, or with code changes, which were not done yet).

Also, there are differences in supported platforms and system requirements.

macOS: One user reported that QtWebKit TP5 built for OS X 10.9 target is 
working fine
on OS X 10.7, however the oldest officially supported version is 10.10 (as in 
upstream).
I'm pretty sure that WK2 IPC with Mach ports will break when compiling for 
older targets,
though it should be possible to switch to unix sockets just for 5.6.

Windows: Windows XP support seems to be feasible, if needed, without new
MediaFoundation-based player. Will require backporting Conan-related patches in
qt5.git to 5.6 branch.

Linux: GStreamer 0.10 is not supported, so official builds with video will have 
to use
QtMultimedia MediaPlayer implementation.

I'm not sure about QNX support in QtWebKit 5.6, it is skipped in CI now because 
of
missing ICU. However, I guess it will be possible to reintroduce QNX support if 
there are
interested folks here, at least Widgets API.

All platforms will need to have cmake >= 2.8.12, this might reduce testing 
coverage for
older cmake versions in 5.6

>
> Thanks for your efforts on this!
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back (part 2)

[Sergio Martins]

On 2017-05-03 15:02, Konstantin Tokarev wrote:

Remaining question is versioning. While it's fine to dub current
release "5.9" (but not 5.0, because we will have another WebKit update
in 5.10 time frame), using Qt versions in QtWebKit has downsides:

1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N,
or is updated
2. It makes people believe that QtWebKit 5.N should be used with Qt
5.N only. QtWebKit supports wide range of Qt versions (starting from
5.2 as of now), and can be used e.g. as security update in Linux
distro that does not normally update Qt version during its life cycle.

Any comments?


If Qt and QtWebKit will have different release schedules then that 
numbering would indeed confuse people.


Have you thought about an LTS version too ? What would LTS mean, for 
QtWebKit ? I think during the LTS lifetime we would still need to update 
the inner WebKit, for security reasons, (that even happened for 
QtWebEngine in a 5.6.x patch release).



Thanks for your efforts on this!


Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWebKit is coming back (part 2)

[Konstantin Tokarev]

Hi all,

A lot of time has passed since original thread [1]. Lots of work was done since 
then, and it took much more time than what I've originally planned, however I 
think now we can use updated QtWebKit as a full replacement of our previous 
branch that didn't have updates of WebKit engine since Qt 5.2.

You can find results of this work in wip/next branch of our QtWebKit repository 
[2] that is checked by Coin on desktop Linux, macOS, and Windows (both MSVC and 
MinGW) configurations.

QtWebKit Technology Preview 5 [3], based on this branch, is already packaged by 
Arch Linux [4] and MSYS2 [5], while KaOS Linux distribution ships it as a 
replacement for old QtWebKit package [6]. It also has had extensive testing by 
developers and users of such open source projects as PhantomJS [7], Otter 
Browser [8], Qutebrowser [9]. Lots of bugs were discovered and fixed in the 
process, a few are not fixed yet but there are no real showstoppers.

Major concern, rased in the previous discussion, was feature parity. You can 
see current status at [10], all major gaps were filled, including support for 
QML API (WebKit 2) on Windows that was causing concerns previously (it isn't 
merged to wip/next yet, but works here). There are still a few missing features 
in QML API, but they affect undocumented experimental part of the API.

I propose we should replace contents of dev branch with wip/next as soon as 
WebKit2/Windows patches are landed. I also think it would be better to release 
it alongside with Qt 5.9 instead of current 5.9 branch contents to stop 
proliferation of old insecure WebKit version. I understand that it does not fit 
into existing schedule of Qt 5.9, however in the previous discussion Lars 
supported the idea of having independent schedule for QtWebKit

Remaining question is versioning. While it's fine to dub current release "5.9" 
(but not 5.0, because we will have another WebKit update in 5.10 time frame), 
using Qt versions in QtWebKit has downsides:

1. It is not clear if 5.N+1 ships with the same WebKit branch as 5.N, or is 
updated
2. It makes people believe that QtWebKit 5.N should be used with Qt 5.N only. 
QtWebKit supports wide range of Qt versions (starting from 5.2 as of now), and 
can be used e.g. as security update in Linux distro that does not normally 
update Qt version during its life cycle.

Any comments?

--

[1] http://lists.qt-project.org/pipermail/development/2016-June/026156.html
[2] https://code.qt.io/qt/qtwebkit.git; it contains snapshots from 
https://github.com/annulen/webkit with unnecessary files excluded
[3] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5
[4] https://www.archlinux.org/packages/extra/x86_64/qt5-webkit-ng/
 https://www.archlinux.org/packages/extra/i686/qt5-webkit-ng/
[5] 
http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-qtwebkit-tp5-4-any.pkg.tar.xz
 
http://repo.msys2.org/mingw/i686/mingw-w64-i686-qtwebkit-tp5-4-any.pkg.tar.xz
[6] 
http://kaosx.tk/packages/index.php?act=show=main=date=qtwebkit-tp-5.6.2.3-3-x86_64.pkg.tar.xz
[7] http://phantomjs.org/
[8] http://otter-browser.org/
[9] http://qutebrowser.org/
[10] https://github.com/annulen/webkit/wiki/Comparison-with-QtWebKit-5.6

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Harald Vistnes]

Hi Konstantin,

precompiled binaries for VS2015 and Qt 5.8 would be perfect! That would
save me a lot of time. Compiling qtwebkit failed, I haven't had the time to
dig into it yet. I'll try your binaries instead.

Thanks,
Harald

2016-12-16 11:51 GMT+01:00 Konstantin Tokarev <annu...@yandex.ru>:

>
>
> 16.12.2016, 13:25, "Harald Vistnes" <harald.vist...@gmail.com>:
> > Silly me, I forgot to run qmake, just tried to run nmake/jom. It's
> compiling now, hopefully without problems.
> >
> > Thanks for your help!
>
>
> I you are using widgets API, consider trying QtWebKit TP4 from [1]. There
> are precompiled binaries for VS2015 and Qt 5.7, if you are interested I can
> prepare 5.8 binaries for you. See [2] for additional background.
>
> [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp4
> [2] http://qtwebkit.blogspot.com/2016/08/qtwebkit-im-back.html
>
>
> > Harald
> >
> > 2016-12-16 10:14 GMT+01:00 Kai Koehne <kai.koe...@qt.io>:
> >>> -Original Message-
> >>> From: Harald Vistnes [mailto:harald.vist...@gmail.com]
> >>> Sent: Friday, December 16, 2016 10:01 AM
> >>> To: Kai Koehne <kai.koe...@qt.io>
> >>> Cc: development@qt-project.org
> >>> Subject: Re: [Development] qtwebkit
> >>>
> >>> Yes, nothing happens.
> >>
> >> So there's no output from qmake? Have you checked that the webkit
> sources are actually there?
> >>
> >> Either qmake should end with an error indicating unmet
> dependencies. Or jom/nmake with a compile error ...
> >>
> >> Kai
> >>
> >>> Harald
> >>>
> >>> 2016-12-16 9:59 GMT+01:00 Kai Koehne <kai.koe...@qt.io
> >>> <mailto:kai.koe...@qt.io> >:
> >>>
> >>>   Have you tried running qmake && jom (or nmake) manually
> inside
> >>> the qtwebkit source directory?
> >>>
> >>>   Kai
> >>>
> >>>   > -Original Message-
> >>>   > From: Development [mailto:development-bounces+kai.koehne
> >>> <mailto:development-bounces%2Bkai.koehne> =qt.io@qt-
> >>>   > project.org <http://project.org> ] On Behalf Of Harald
> Vistnes
> >>>   > Sent: Friday, December 16, 2016 9:55 AM
> >>
> >>>   > To: development@qt-project.org <mailto:development@qt-
> >>> project.org>
> >>>   > Subject: [Development] qtwebkit
> >>>   >
> >>>   > Hi,
> >>>   >
> >>>   > is it still possible to build the qtwebkit module manually
> in 5.8.0?
> >>> I've tried
> >>>   > fetching the sources from git, but qtwebkit is not built.
> I guess I
> >>> have to
> >>>   > change some build scripts since it is obsolete, but I am
> not sure
> >>> what needs
> >>>   > to be done.
> >>>   >
> >>>   > Here is what I did
> >>>   >
> >>>   > git clone git://code.qt.io/qt/qt5.git <
> http://code.qt.io/qt/qt5.git>
> >>> <http://code.qt.io/qt/qt5.git> cd qt5 perl
> >>>   > init-repository --module-subset=all,-ignore,-
> qtwebkit-examples,-
> >>>   > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-
> >>> qtdatavis3d,-
> >>>   > qtcharts,-qtpurchasing,-qtquickcontrols2,-
> qtserialport,-qtwayland,-
> >>> qtdoc
> >>>   > git checkout 5.8.0
> >>>   >
> >>>   > configure -prefix %CD%\qtbase -opensource -shared -confirm-
> >>> license -
> >>>   > debug-and-release -release -opengl desktop -qt-zlib
> -qt-libpng -no-
> >>> angle -qt-
> >>>   > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip
> qtsensors -skip
> >>>   > qtwayland -skip qtserialbus -skip qtserialport -skip
> >>> qtvirtualkeyboard -skip
> >>>   > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip
> qtspeech -skip
> >>>   > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -
> >>> nomake tests
> >>>   >
> >>>   > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro
> >>> <http://qt.pro>  <http://qt.pro>
> >>>
> >>>   > (line 29), but that did not help.
> >>>   >
> >>>   > I'm on Windows 10 with VS2015. I've built qtwebkit before,
> so I
> >>> think I have
> >>>   > all dependencies installed.
> >>>   >
> >>>   > What am I missing?
> >>>   >
> >>>   > Thanks,
> >>>   > Harald
> > ,
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
>
>
>
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Konstantin Tokarev]

16.12.2016, 13:25, "Harald Vistnes" <harald.vist...@gmail.com>:
> Silly me, I forgot to run qmake, just tried to run nmake/jom. It's 
> compiling now, hopefully without problems.
>
> Thanks for your help!


I you are using widgets API, consider trying QtWebKit TP4 from [1]. There are 
precompiled binaries for VS2015 and Qt 5.7, if you are interested I can prepare 
5.8 binaries for you. See [2] for additional background.

[1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp4
[2] http://qtwebkit.blogspot.com/2016/08/qtwebkit-im-back.html


> Harald
>
> 2016-12-16 10:14 GMT+01:00 Kai Koehne <kai.koe...@qt.io>:
>>> -Original Message-
>>> From: Harald Vistnes [mailto:harald.vist...@gmail.com]
>>> Sent: Friday, December 16, 2016 10:01 AM
>>> To: Kai Koehne <kai.koe...@qt.io>
>>> Cc: development@qt-project.org
>>> Subject: Re: [Development] qtwebkit
>>>
>>> Yes, nothing happens.
>>
>> So there's no output from qmake? Have you checked that the webkit 
>> sources are actually there?
>>
>> Either qmake should end with an error indicating unmet dependencies. Or 
>> jom/nmake with a compile error ...
>>
>> Kai
>>
>>> Harald
>>>
>>> 2016-12-16 9:59 GMT+01:00 Kai Koehne <kai.koe...@qt.io
>>> <mailto:kai.koe...@qt.io> >:
>>>
>>>       Have you tried running qmake && jom (or nmake) manually inside
>>> the qtwebkit source directory?
>>>
>>>       Kai
>>>
>>>       > -Original Message-
>>>       > From: Development [mailto:development-bounces+kai.koehne
>>> <mailto:development-bounces%2Bkai.koehne> =qt.io@qt-
>>>       > project.org <http://project.org> ] On Behalf Of Harald Vistnes
>>>       > Sent: Friday, December 16, 2016 9:55 AM
>>
>>>       > To: development@qt-project.org <mailto:development@qt-
>>> project.org>
>>>       > Subject: [Development] qtwebkit
>>>       >
>>>       > Hi,
>>>       >
>>>       > is it still possible to build the qtwebkit module manually in 
>>> 5.8.0?
>>> I've tried
>>>       > fetching the sources from git, but qtwebkit is not built. I 
>>> guess I
>>> have to
>>>       > change some build scripts since it is obsolete, but I am not 
>>> sure
>>> what needs
>>>       > to be done.
>>>       >
>>>       > Here is what I did
>>>       >
>>>       > git clone git://code.qt.io/qt/qt5.git 
>>> <http://code.qt.io/qt/qt5.git>
>>> <http://code.qt.io/qt/qt5.git> cd qt5 perl
>>>       > init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
>>>       > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-
>>> qtdatavis3d,-
>>>       > 
>>> qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-
>>> qtdoc
>>>       > git checkout 5.8.0
>>>       >
>>>       > configure -prefix %CD%\qtbase -opensource -shared -confirm-
>>> license -
>>>       > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng 
>>> -no-
>>> angle -qt-
>>>       > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip 
>>> qtsensors -skip
>>>       > qtwayland -skip qtserialbus -skip qtserialport -skip
>>> qtvirtualkeyboard -skip
>>>       > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech 
>>> -skip
>>>       > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -
>>> nomake tests
>>>       >
>>>       > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro
>>> <http://qt.pro>  <http://qt.pro>
>>>
>>>       > (line 29), but that did not help.
>>>       >
>>>       > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I
>>> think I have
>>>       > all dependencies installed.
>>>       >
>>>       > What am I missing?
>>>       >
>>>       > Thanks,
>>>       > Harald
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development






-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Harald Vistnes]

Silly me, I forgot to run qmake, just tried to run nmake/jom. It's
compiling now, hopefully without problems.

Thanks for your help!

Harald

2016-12-16 10:14 GMT+01:00 Kai Koehne <kai.koe...@qt.io>:

> > -Original Message-
> > From: Harald Vistnes [mailto:harald.vist...@gmail.com]
> > Sent: Friday, December 16, 2016 10:01 AM
> > To: Kai Koehne <kai.koe...@qt.io>
> > Cc: development@qt-project.org
> > Subject: Re: [Development] qtwebkit
> >
> > Yes, nothing happens.
>
> So there's no output from qmake? Have you checked that the webkit sources
> are actually there?
>
> Either qmake should end with an error indicating unmet dependencies. Or
> jom/nmake with a compile error ...
>
> Kai
>
> > Harald
> >
> > 2016-12-16 9:59 GMT+01:00 Kai Koehne <kai.koe...@qt.io
> > <mailto:kai.koe...@qt.io> >:
> >
> >
> >   Have you tried running qmake && jom (or nmake) manually inside
> > the qtwebkit source directory?
> >
> >   Kai
> >
> >   > -Original Message-
> >   > From: Development [mailto:development-bounces+kai.koehne
> > <mailto:development-bounces%2Bkai.koehne> =qt.io@qt-
> >   > project.org <http://project.org> ] On Behalf Of Harald Vistnes
> >   > Sent: Friday, December 16, 2016 9:55 AM
> >   > To: development@qt-project.org <mailto:development@qt-
> > project.org>
> >   > Subject: [Development] qtwebkit
> >   >
> >   > Hi,
> >   >
> >   > is it still possible to build the qtwebkit module manually in
> 5.8.0?
> > I've tried
> >   > fetching the sources from git, but qtwebkit is not built. I
> guess I
> > have to
> >   > change some build scripts since it is obsolete, but I am not sure
> > what needs
> >   > to be done.
> >   >
> >   > Here is what I did
> >   >
> >   > git clone git://code.qt.io/qt/qt5.git <
> http://code.qt.io/qt/qt5.git>
> > <http://code.qt.io/qt/qt5.git> cd qt5 perl
> >   > init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
> >   > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-
> > qtdatavis3d,-
> >   > qtcharts,-qtpurchasing,-qtquickcontrols2,-
> qtserialport,-qtwayland,-
> > qtdoc
> >   > git checkout 5.8.0
> >   >
> >   > configure -prefix %CD%\qtbase -opensource -shared -confirm-
> > license -
> >   > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng
> -no-
> > angle -qt-
> >   > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip
> qtsensors -skip
> >   > qtwayland -skip qtserialbus -skip qtserialport -skip
> > qtvirtualkeyboard -skip
> >   > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech
> -skip
> >   > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -
> > nomake tests
> >   >
> >   > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro
> > <http://qt.pro>  <http://qt.pro>
> >
> >   > (line 29), but that did not help.
> >   >
> >   > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I
> > think I have
> >   > all dependencies installed.
> >   >
> >   > What am I missing?
> >   >
> >   > Thanks,
> >   > Harald
> >
> >
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Kai Koehne]

> -Original Message-
> From: Harald Vistnes [mailto:harald.vist...@gmail.com]
> Sent: Friday, December 16, 2016 10:01 AM
> To: Kai Koehne <kai.koe...@qt.io>
> Cc: development@qt-project.org
> Subject: Re: [Development] qtwebkit
> 
> Yes, nothing happens.

So there's no output from qmake? Have you checked that the webkit sources are 
actually there?

Either qmake should end with an error indicating unmet dependencies. Or 
jom/nmake with a compile error ...

Kai

> Harald
> 
> 2016-12-16 9:59 GMT+01:00 Kai Koehne <kai.koe...@qt.io
> <mailto:kai.koe...@qt.io> >:
> 
> 
>   Have you tried running qmake && jom (or nmake) manually inside
> the qtwebkit source directory?
> 
>   Kai
> 
>   > -Original Message-
>   > From: Development [mailto:development-bounces+kai.koehne
> <mailto:development-bounces%2Bkai.koehne> =qt.io@qt-
>   > project.org <http://project.org> ] On Behalf Of Harald Vistnes
>   > Sent: Friday, December 16, 2016 9:55 AM
>   > To: development@qt-project.org <mailto:development@qt-
> project.org>
>   > Subject: [Development] qtwebkit
>   >
>   > Hi,
>   >
>   > is it still possible to build the qtwebkit module manually in 5.8.0?
> I've tried
>   > fetching the sources from git, but qtwebkit is not built. I guess I
> have to
>   > change some build scripts since it is obsolete, but I am not sure
> what needs
>   > to be done.
>   >
>   > Here is what I did
>   >
>   > git clone git://code.qt.io/qt/qt5.git <http://code.qt.io/qt/qt5.git>
> <http://code.qt.io/qt/qt5.git> cd qt5 perl
>   > init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
>   > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-
> qtdatavis3d,-
>   > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-
> qtdoc
>   > git checkout 5.8.0
>   >
>   > configure -prefix %CD%\qtbase -opensource -shared -confirm-
> license -
>   > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-
> angle -qt-
>   > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors 
> -skip
>   > qtwayland -skip qtserialbus -skip qtserialport -skip
> qtvirtualkeyboard -skip
>   > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip
>   > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -
> nomake tests
>   >
>   > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro
> <http://qt.pro>  <http://qt.pro>
> 
>   > (line 29), but that did not help.
>   >
>   > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I
> think I have
>   > all dependencies installed.
>   >
>   > What am I missing?
>   >
>   > Thanks,
>   > Harald
> 
> 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Harald Vistnes]

Yes, nothing happens.

Harald

2016-12-16 9:59 GMT+01:00 Kai Koehne <kai.koe...@qt.io>:

> Have you tried running qmake && jom (or nmake) manually inside the
> qtwebkit source directory?
>
> Kai
>
> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Harald Vistnes
> > Sent: Friday, December 16, 2016 9:55 AM
> > To: development@qt-project.org
> > Subject: [Development] qtwebkit
> >
> > Hi,
> >
> > is it still possible to build the qtwebkit module manually in 5.8.0?
> I've tried
> > fetching the sources from git, but qtwebkit is not built. I guess I have
> to
> > change some build scripts since it is obsolete, but I am not sure what
> needs
> > to be done.
> >
> > Here is what I did
> >
> > git clone git://code.qt.io/qt/qt5.git <http://code.qt.io/qt/qt5.git> cd
> qt5 perl
> > init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
> > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,-
> > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc
> > git checkout 5.8.0
> >
> > configure -prefix %CD%\qtbase -opensource -shared -confirm-license -
> > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle
> -qt-
> > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip
> > qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard
> -skip
> > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip
> > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -nomake tests
> >
> > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro <http://qt.pro>
> > (line 29), but that did not help.
> >
> > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I
> have
> > all dependencies installed.
> >
> > What am I missing?
> >
> > Thanks,
> > Harald
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Kai Koehne]

Have you tried running qmake && jom (or nmake) manually inside the qtwebkit 
source directory?

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Harald Vistnes
> Sent: Friday, December 16, 2016 9:55 AM
> To: development@qt-project.org
> Subject: [Development] qtwebkit
> 
> Hi,
> 
> is it still possible to build the qtwebkit module manually in 5.8.0? I've 
> tried
> fetching the sources from git, but qtwebkit is not built. I guess I have to
> change some build scripts since it is obsolete, but I am not sure what needs
> to be done.
> 
> Here is what I did
> 
> git clone git://code.qt.io/qt/qt5.git <http://code.qt.io/qt/qt5.git> cd qt5 
> perl
> init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
> qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,-
> qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc
> git checkout 5.8.0
> 
> configure -prefix %CD%\qtbase -opensource -shared -confirm-license -
> debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle -qt-
> libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip
> qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip
> qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip
> qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -nomake tests
> 
> I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro <http://qt.pro>
> (line 29), but that did not help.
> 
> I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I have
> all dependencies installed.
> 
> What am I missing?
> 
> Thanks,
> Harald
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qtwebkit

[Harald Vistnes]

Hi,

is it still possible to build the qtwebkit module manually in 5.8.0? I've
tried fetching the sources from git, but qtwebkit is not built. I guess I
have to change some build scripts since it is obsolete, but I am not sure
what needs to be done.

Here is what I did

git clone git://code.qt.io/qt/qt5.git
cd qt5
perl init-repository
--module-subset=all,-ignore,-qtwebkit-examples,-qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,-qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc
git checkout 5.8.0
configure -prefix %CD%\qtbase -opensource -shared -confirm-license
-debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle
-qt-libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors
-skip qtwayland -skip qtserialbus -skip qtserialport -skip
qtvirtualkeyboard -skip qtdatavis3d -skip qtcharts -skip qtpurchasing -skip
qtspeech -skip qtnetworkauth -skip qtwebengine -platform win32-msvc2015
-nomake tests

I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro (line 29), but
that did not help.

I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I
have all dependencies installed.

What am I missing?

Thanks,
Harald
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Konstantin Tokarev]

07.06.2016, 19:01, "Stephen Chu" :
> I don’t see Mac mentioned in either links provided. Is Mac supported?

You can build qtwebkit-stable branch on OS X now, see instructions at [1].
Binaries will be available for TP2.

[1] https://github.com/annulen/webkit/wiki/Building-QtWebKit-on-OS-X

>
> Stephen Chu
>
> On 6/4/16, 3:20 PM, "Development on behalf of Konstantin Tokarev" 
>  annu...@yandex.ru> wrote:
>
>> Hi all,
>>
>> As some of you may already know, there is an ongoing effort to revive 
>> QtWebKit by updating its WebKit engine to the current state of upstream at 
>> webkit.org [1].
>>
>> While it still haven't reached feature parity with QtWebkit module hosted by 
>> Qt Project, its Widgets API is already in a good shape [2]. It also brings 
>> many new features, including support for large part of ES2015. It is binary 
>> compatible with QtWebKit 5.6 and can be used as drop-in replacement.
>>
>> In this regard I have following questions to the Qt community:
>>
>> 1. Would you like to see this project as a part of Qt Project?
>>
>> QtWebKit used to be a part of Qt Essentials (at least before its removal in 
>> 5.6 release, I'm not sure what status does it have right now). I think it's 
>> neither feasible nor reasonable to restore this status it as a part of Qt 
>> Essentials, as it used to be before 5.6. We have a massive amount of 3rd 
>> party code so it would require much more work to support complete range of 
>> platforms and compilers, supported by Qt. In particular, full C++ 11 support 
>> is required from compiler, making minimal required GCC version as high as 
>> 4.8. (In the meanwhile, WebKit already started adoption of C++1y in trunk, 
>> though GCC 4.9 is still supported)
>>
>> Also it's likely that supported platforms won't have perfect feature parity, 
>> and it's not clear if we are going to support WebKit 2 on Windows at all (if 
>> somebody reading this is interested, please join us!)
>>
>> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should 
>> it be versioned?
>>
>> Pros:
>> * It is a drop-in replacement for QtWebKit, so it would simplify its 
>> downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 
>> 5.6 with this new offering.
>> * QtWebKit is a name of Qt port of WebKit. This project is basically a 
>> rebase of Qt port code to the newer revision of trunk, so I don't see it as 
>> a fork of original project, but mere update.
>>
>> Cons:
>> * Old QtWebKit will probably continue to exist, because range of supported 
>> platforms for new QtWebKit is more limited. Right now we have no plans to 
>> support Android, QNX or WinCE, it's also unclear if we will ever support 
>> WebKit 2 on Windows. That means we need a way to make a clear difference 
>> between branches of the project.
>> * Users may mistakenly report problems specific to the new version to Qt 
>> JIRA. This issue could be worked around if Qt Project kindly allowed us to 
>> have a project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I 
>> could simply move such reports to another project and reassign. OTOH, it's 
>> quite possible that bugs reported against new QtWebKit affect 5.6 as well, 
>> for example see QTBUG-53532.
>>
>> Of course, if anybody here is interested, any kind of help will be greatly 
>> appreciated.
>>
>> Thanks in advance!
>>
>> [1] https://github.com/annulen/webkit/wiki
>> [2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html
>> Latest development is in "qtwebkit-stable" branch, we are planning to 
>> release TP2 with many fixes and improvements really soon
>>
>> --
>> Regards,
>> Konstantin
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Konstantin Tokarev]

Allan,

Thanks for write-up, I'd like to add just a few side notes

08.06.2016, 22:49, "Allan Sandfeld Jensen" :
>  I was asked how we used to structure and develop QtWebKit, and how it would
>  relate to the new project. So here some background and my thoughts:
>
>  The way QtWebKit used to be developed was upstream in WebKit, at some point a
>  release was branched and squashed into the qt respository in one big commit,
>  where we also removed all the layout tests which makes up the by far largest
>  part of the webkit repo.
>
>  The last branch of QtWebKit (originally branched for Qt 5.2) had three
>  different repos: WebKit upsteam, a fork of upstream living in gitorious where
>  our 5.2 git branch relative to upstream lived, and which was supposed to be
>  identical to the Qt-repo except supporting layout tests, and finally the
>  QtWebKit module in Qt repo. WebKit's build-system and CI ran on upstream
>  (equivalent to Qt dev), and on the the fork (equivalent to 5.2). Qt's build-
>  system and CI ran only on the Qt repo (basically only git tags).
>
>  Such a structure while workable is obviously not optimal, and even if we did
>  continue with such a 3 way model, it would be ideal if the upstream-fork 
> could
>  be hosted together with the official qt version.
>
>  For an unofficial QtWebKit I would suggest just using an upstream fork on a
>  friendly git host. Being kicked out of upstream WebKit also means it would be
>  the only place of development. This is also how I maintained QtWebKit 2.3
>  which was a backport of modern QtWebKit to Qt4.

If I understood correctly, in this thread Lars has agreed to make it "official",
though it's not clear to me how will it map to existing structure of Qt Project.

>  Such as structure will however
>  become a problem if QtWebKit-NG needs to integrate with Qt build/CI system
>  again, since the repo would be a huge, unnecessary burden to check out, for
>  anyone who needs to just build or test it.

While it's certainly true that full WebKit repo creates more burden, arguably 
it's
not a showstopper: after repo is initially cloned it does not take a lot of time
and traffic to update it, also problem with large clone size can be mitigated by
limiting clone depth and by using sparse checkout feature of git.

Though I'm not sure if Gerrit will perform well on the full repo.

>
>  Note, it is not easy to split a WebKit repository and make the layout-tests a
>  submodule due to the sensible WebKit policy of always maintaining and adding
>  tests atomically with each commit that adds features that needs testing or
>  changes test output.
>
>  Best regards
>  `Allan
>
>  ___
>  Development mailing list
>  Development@qt-project.org
>  http://lists.qt-project.org/mailman/listinfo/development


-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Allan Sandfeld Jensen]

I was asked how we used to structure and develop QtWebKit, and how it would 
relate to the new project. So here some background and my thoughts:

The way QtWebKit used to be developed was upstream in WebKit, at some point a 
release was branched and squashed into the qt respository in one big commit, 
where we also removed all the layout tests which makes up the by far largest 
part of the webkit repo.

The last branch of QtWebKit (originally branched for Qt 5.2) had three 
different repos: WebKit upsteam, a fork of upstream living in gitorious where 
our 5.2 git branch relative to upstream lived, and which was supposed to be 
identical to the Qt-repo except supporting layout tests, and finally the 
QtWebKit module in Qt repo. WebKit's build-system and CI ran on upstream 
(equivalent to Qt dev), and on the the fork (equivalent to 5.2). Qt's build-
system and CI ran only on the Qt repo (basically only git tags).

Such a structure while workable is obviously not optimal, and even if we did 
continue with such a 3 way model, it would be ideal if the upstream-fork could 
be hosted together with the official qt version.

For an unofficial QtWebKit I would suggest just using an upstream fork on a 
friendly git host. Being kicked out of upstream WebKit also means it would be 
the only place of development. This is also how I maintained QtWebKit 2.3 
which was a backport of modern QtWebKit to Qt4. Such as structure will however 
become a problem if QtWebKit-NG needs to integrate with Qt build/CI system 
again, since the repo would be a huge, unnecessary burden to check out, for 
anyone who needs to just build or test it.

Note, it is not easy to split a WebKit repository and make the layout-tests a 
submodule due to the sensible WebKit policy of always maintaining and adding 
tests atomically with each commit that adds features that needs testing or 
changes test output.

Best regards
`Allan

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Konstantin Tokarev]

07.06.2016, 19:01, "Stephen Chu" :
> I don’t see Mac mentioned in either links provided. Is Mac supported?

Not yet, though a couple of changes needed to compile on OS X were already 
integrated.
If you want to try building it, I can give you a few instructions.

>
> Stephen Chu
>
> On 6/4/16, 3:20 PM, "Development on behalf of Konstantin Tokarev" 
>  annu...@yandex.ru> wrote:
>
>> Hi all,
>>
>> As some of you may already know, there is an ongoing effort to revive 
>> QtWebKit by updating its WebKit engine to the current state of upstream at 
>> webkit.org [1].
>>
>> While it still haven't reached feature parity with QtWebkit module hosted by 
>> Qt Project, its Widgets API is already in a good shape [2]. It also brings 
>> many new features, including support for large part of ES2015. It is binary 
>> compatible with QtWebKit 5.6 and can be used as drop-in replacement.
>>
>> In this regard I have following questions to the Qt community:
>>
>> 1. Would you like to see this project as a part of Qt Project?
>>
>> QtWebKit used to be a part of Qt Essentials (at least before its removal in 
>> 5.6 release, I'm not sure what status does it have right now). I think it's 
>> neither feasible nor reasonable to restore this status it as a part of Qt 
>> Essentials, as it used to be before 5.6. We have a massive amount of 3rd 
>> party code so it would require much more work to support complete range of 
>> platforms and compilers, supported by Qt. In particular, full C++ 11 support 
>> is required from compiler, making minimal required GCC version as high as 
>> 4.8. (In the meanwhile, WebKit already started adoption of C++1y in trunk, 
>> though GCC 4.9 is still supported)
>>
>> Also it's likely that supported platforms won't have perfect feature parity, 
>> and it's not clear if we are going to support WebKit 2 on Windows at all (if 
>> somebody reading this is interested, please join us!)
>>
>> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should 
>> it be versioned?
>>
>> Pros:
>> * It is a drop-in replacement for QtWebKit, so it would simplify its 
>> downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 
>> 5.6 with this new offering.
>> * QtWebKit is a name of Qt port of WebKit. This project is basically a 
>> rebase of Qt port code to the newer revision of trunk, so I don't see it as 
>> a fork of original project, but mere update.
>>
>> Cons:
>> * Old QtWebKit will probably continue to exist, because range of supported 
>> platforms for new QtWebKit is more limited. Right now we have no plans to 
>> support Android, QNX or WinCE, it's also unclear if we will ever support 
>> WebKit 2 on Windows. That means we need a way to make a clear difference 
>> between branches of the project.
>> * Users may mistakenly report problems specific to the new version to Qt 
>> JIRA. This issue could be worked around if Qt Project kindly allowed us to 
>> have a project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I 
>> could simply move such reports to another project and reassign. OTOH, it's 
>> quite possible that bugs reported against new QtWebKit affect 5.6 as well, 
>> for example see QTBUG-53532.
>>
>> Of course, if anybody here is interested, any kind of help will be greatly 
>> appreciated.
>>
>> Thanks in advance!
>>
>> [1] https://github.com/annulen/webkit/wiki
>> [2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html
>> Latest development is in "qtwebkit-stable" branch, we are planning to 
>> release TP2 with many fixes and improvements really soon
>>
>> --
>> Regards,
>> Konstantin
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Stephen Chu]

I don’t see Mac mentioned in either links provided. Is Mac supported?

Stephen Chu







On 6/4/16, 3:20 PM, "Development on behalf of Konstantin Tokarev" 
 wrote:

>Hi all,
>
>As some of you may already know, there is an ongoing effort to revive QtWebKit 
>by updating its WebKit engine to the current state of upstream at webkit.org 
>[1]. 
>
>While it still haven't reached feature parity with QtWebkit module hosted by 
>Qt Project, its Widgets API is already in a good shape [2]. It also brings 
>many new features, including support for large part of ES2015. It is binary 
>compatible with QtWebKit 5.6 and can be used as drop-in replacement.
>
>In this regard I have following questions to the Qt community:
>
>1. Would you like to see this project as a part of Qt Project?
>
>QtWebKit used to be a part of Qt Essentials (at least before its removal in 
>5.6 release, I'm not sure what status does it have right now). I think it's 
>neither feasible nor reasonable to restore this status it as a part of Qt 
>Essentials, as it used to be before 5.6. We have a massive amount of 3rd party 
>code so it would require much more work to support complete range of platforms 
>and compilers, supported by Qt. In particular, full C++ 11 support is required 
>from compiler, making minimal required GCC version as high as 4.8. (In the 
>meanwhile, WebKit already started adoption of C++1y in trunk, though GCC 4.9 
>is still supported)
>
>Also it's likely that supported platforms won't have perfect feature parity, 
>and it's not clear if we are going to support WebKit 2 on Windows at all (if 
>somebody reading this is interested, please join us!)
>
>2. Is it OK to use "QtWebKit" name for this project, and if yes, how should it 
>be versioned?
>
>Pros:
>* It is a drop-in replacement for QtWebKit, so it would simplify its 
>downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 
>5.6 with this new offering.
>* QtWebKit is a name of Qt port of WebKit. This project is basically a rebase 
>of Qt port code to the newer revision of trunk, so I don't see it as a fork of 
>original project, but mere update.
>
>Cons:
>* Old QtWebKit will probably continue to exist, because range of supported 
>platforms for new QtWebKit is more limited. Right now we have no plans to 
>support Android, QNX or WinCE, it's also unclear if we will ever support 
>WebKit 2 on Windows. That means we need a way to make a clear difference 
>between branches of the project.
>* Users may mistakenly report problems specific to the new version to Qt JIRA. 
>This issue could be worked around if Qt Project kindly allowed us to have a 
>project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I could 
>simply move such reports to another project and reassign. OTOH, it's quite 
>possible that bugs reported against new QtWebKit affect 5.6 as well, for 
>example see QTBUG-53532.
>
>Of course, if anybody here is interested, any kind of help will be greatly 
>appreciated.
>
>Thanks in advance!
>
>
>[1] https://github.com/annulen/webkit/wiki
>[2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html
>Latest development is in "qtwebkit-stable" branch, we are planning to release 
>TP2 with many fixes and improvements really soon
>
>-- 
>Regards,
>Konstantin
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Lars Knoll]

On 07/06/16 16:03, "Development on behalf of Thiago Macieira" 
 wrote:

>Em terça-feira, 7 de junho de 2016, às 08:47:12 PDT, Florian Bruhin escreveu:
>> FWIW the unofficial name it just happened to get in various related
>> IRC channels is "QtWebKit-NG" ;)
>
>I like that.

Sounds good to me as well.

Lars


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Thiago Macieira]

Em terça-feira, 7 de junho de 2016, às 08:47:12 PDT, Florian Bruhin escreveu:
> FWIW the unofficial name it just happened to get in various related
> IRC channels is "QtWebKit-NG" ;)

I like that.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Konstantin Tokarev]

07.06.2016, 09:47, "Florian Bruhin" :
> * Lars Knoll  [2016-06-07 06:38:35 +]:
>>  Ok, in this case a separate repo is maybe a better strategy.
>>  WebKitQt (as Allan proposed) might be a good name in this case :)
>
> I don't want to start any bike-shedding here, but if there's a
> QtWebKit and a WebKitQt and those are *basically* different versions
> of the same thing, that sounds like a source for a lot of confusion...

I admit that I was thinking about WebKitQt name before Allan proposed it,
for the same reason + because project becomes somewhat more "WebKitish"
and less "Qtish" over the time.

However I have the same concern as Florian, i.e. difference is too subtle
to eleminate confusion, and too significant for seamless update.

BTW, I think it's not strictly necessary to equate public name of the project
and basename of the final component of repo url. For instance, new repo could be
at qt/webkit.git. Optionally with snapshots and tags pushed into qt/qtwebkit.git
for convenience of packagers.


>
> FWIW the unofficial name it just happened to get in various related
> IRC channels is "QtWebKit-NG" ;)
>
> Florian
>
> --
> http://www.the-compiler.org | m...@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/
> ,
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Florian Bruhin]

* Lars Knoll  [2016-06-07 06:38:35 +]:
> Ok, in this case a separate repo is maybe a better strategy.
> WebKitQt (as Allan proposed) might be a good name in this case :)

I don't want to start any bike-shedding here, but if there's a
QtWebKit and a WebKitQt and those are *basically* different versions
of the same thing, that sounds like a source for a lot of confusion...

FWIW the unofficial name it just happened to get in various related
IRC channels is "QtWebKit-NG" ;)

Florian

-- 
http://www.the-compiler.org | m...@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/


signature.asc
Description: PGP signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Lars Knoll]

On 06/06/16 17:40, "Konstantin Tokarev"  wrote:



>
>
>06.06.2016, 16:54, "Lars Knoll" :
>> Hi Konstantin,
>>
>> I’d be happy to host this project here on qt-project.org (and that includes 
>> of course both source code and bug tracking) :)
>
>Thank you!
>
>>
>> I don’t think it is a problem that the set of supported platforms is 
>> different from Qt WebKit in 5.6, this would have evolved in any way due to 
>> changes in the upstream project. I can also see why it would be hard to 
>> support certain things such as webkit2 on Windows (it has been difficult to 
>> support that in the past).
>>
>> I don’t even see a larger problem with continuing the development in the 
>> existing qtwebkit repository under three conditions: First, the branch names 
>> should make it clear that this is the new effort and not the older Qt WebKit 
>> that is being shipped with 5.6. Secondly the project needs to continue to 
>> either have full binary compatibility with the old QtWebKit in this case or 
>> bump the major .so version. A drop-in replacement (ie. Keeping BC) would be 
>> preferred if that’s possible. Thirdly, the documentation needs to be very 
>> explicit about the feature delta between old and new versions.
>
>There is one technical reason _against_ re-using existing qtwebkit repository: 
>these two repos do not have any shared history. Repository [1] is a direct 
>fork of upstream, while repository [2] uses squashed history and does not 
>include LayoutTests. If we want to reuse [2] to hold code from [1] and don't 
>want to bloat it with several extra GiBs of data overnight, the only 
>reasonable startegy is to import snapshots, like it was done in old days.
>
>Having such stripped-down repository will probably be beneficial for users 
>(and maybe occasional contributors as well) who won't need to deal with 
>full-blown WebKit repo, but for actual development full repository is needed.


Ok, in this case a separate repo is maybe a better strategy. WebKitQt (as Allan 
proposed) might be a good name in this case :)
If it’s a separate repo, I don’t see a problem with having the actual repo here.
>
>There are other concerns which may affect your decision:
>
>1. We use CMake-based build system, most of which is shared with other Webkit 
>ports. This is purely pragmatic decision, aimed at maintenance cost reduction 
>[3].
>2. We use the same licensing policy as WebKit, i.e. BSD + LGPLv2 and no LGPLv3 
>[4]
>3. Our plan is to use stable branches of WebKitGTK as a base of our stable 
>branches, e.g. now it is 2.12 branch [5]. This may cause lack of alignment 
>with Qt release schedule sometimes.

I would probably do the same/similar decisions here. I don’t think they are 
reasons not to have the repo on qt-project.org if you want to have it there.

Of course the webkit port would live it’s own life independent of the rest of 
Qt in terms of release schedules, but that’s fine. 

Cheers,
Lars

>
>
>[1] https://github.com/annulen/webkit
>[2] http://code.qt.io/cgit/qt/qtwebkit.git/
>[3] https://github.com/annulen/webkit/wiki/FAQ
>[4] https://github.com/annulen/webkit/wiki/Licensing
>[5] Reasons to use WebKitGTK instead of Apple's stable branch:
>* we share more code with GTK than with Apple, especially on *nix
>* on embedded, Apple is strongly focused on ARM64 whle GTK supports wider 
> range of platforms
>* GTK creates stable branches 2x more often than Apple => less lagging 
> behind ToT
>
>>
>> Cheers,
>> Lars
>>
>> On 04/06/16 22:40, "Development on behalf of Thiago Macieira" 
>> > thiago.macie...@intel.com> wrote:
>>
>>> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu:
  2. Is it OK to use "QtWebKit" name for this project, and if yes, how 
 should
  it be versioned?

  Pros:
  * It is a drop-in replacement for QtWebKit,
>>>
>>> Please don't. You can use the same soname if you are binary compatible, but
>>> please call the module / project something different to indicate that it's
>>> different from the previous effort. We cannot give the impression that it 
>>> is a
>>> continuation if it doesn't get as wide support as the old one had and 
>>> feature
>>> parity.
>>>
>>> PS: Windows CE is dropped from 5.8, so you don't have to worry about it.
>>>
>>> --
>>> Thiago Macieira - thiago.macieira (AT) intel.com
>>>   Software Architect - Intel Open Source Technology Center
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>
>-- 
>Regards,
>Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Konstantin Tokarev]

06.06.2016, 16:54, "Lars Knoll" :
> Hi Konstantin,
>
> I’d be happy to host this project here on qt-project.org (and that includes 
> of course both source code and bug tracking) :)
>
> I don’t think it is a problem that the set of supported platforms is 
> different from Qt WebKit in 5.6, this would have evolved in any way due to 
> changes in the upstream project. I can also see why it would be hard to 
> support certain things such as webkit2 on Windows (it has been difficult to 
> support that in the past).
>
> I don’t even see a larger problem with continuing the development in the 
> existing qtwebkit repository under three conditions: First, the branch names 
> should make it clear that this is the new effort and not the older Qt WebKit 
> that is being shipped with 5.6. Secondly the project needs to continue to 
> either have full binary compatibility with the old QtWebKit in this case or 
> bump the major .so version. A drop-in replacement (ie. Keeping BC) would be 
> preferred if that’s possible.

The only exisiting BC issue is with linker scripts, since we don't use qmake 
we'll need to imitate what different Qt versions do. Otherwise, it is 
compatible, e.g. it was reported to work with binary PyQt packages installed 
from repositories


> Thirdly, the documentation needs to be very explicit about the feature delta 
> between old and new versions.
>
> Cheers,
> Lars
>
> On 04/06/16 22:40, "Development on behalf of Thiago Macieira" 
>  thiago.macie...@intel.com> wrote:
>
>> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu:
>>>  2. Is it OK to use "QtWebKit" name for this project, and if yes, how should
>>>  it be versioned?
>>>
>>>  Pros:
>>>  * It is a drop-in replacement for QtWebKit,
>>
>> Please don't. You can use the same soname if you are binary compatible, but
>> please call the module / project something different to indicate that it's
>> different from the previous effort. We cannot give the impression that it is 
>> a
>> continuation if it doesn't get as wide support as the old one had and feature
>> parity.
>>
>> PS: Windows CE is dropped from 5.8, so you don't have to worry about it.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Konstantin Tokarev]

06.06.2016, 16:54, "Lars Knoll" :
> Hi Konstantin,
>
> I’d be happy to host this project here on qt-project.org (and that includes 
> of course both source code and bug tracking) :)

Thank you!

>
> I don’t think it is a problem that the set of supported platforms is 
> different from Qt WebKit in 5.6, this would have evolved in any way due to 
> changes in the upstream project. I can also see why it would be hard to 
> support certain things such as webkit2 on Windows (it has been difficult to 
> support that in the past).
>
> I don’t even see a larger problem with continuing the development in the 
> existing qtwebkit repository under three conditions: First, the branch names 
> should make it clear that this is the new effort and not the older Qt WebKit 
> that is being shipped with 5.6. Secondly the project needs to continue to 
> either have full binary compatibility with the old QtWebKit in this case or 
> bump the major .so version. A drop-in replacement (ie. Keeping BC) would be 
> preferred if that’s possible. Thirdly, the documentation needs to be very 
> explicit about the feature delta between old and new versions.

There is one technical reason _against_ re-using existing qtwebkit repository: 
these two repos do not have any shared history. Repository [1] is a direct fork 
of upstream, while repository [2] uses squashed history and does not include 
LayoutTests. If we want to reuse [2] to hold code from [1] and don't want to 
bloat it with several extra GiBs of data overnight, the only reasonable 
startegy is to import snapshots, like it was done in old days.

Having such stripped-down repository will probably be beneficial for users (and 
maybe occasional contributors as well) who won't need to deal with full-blown 
WebKit repo, but for actual development full repository is needed.

There are other concerns which may affect your decision:

1. We use CMake-based build system, most of which is shared with other Webkit 
ports. This is purely pragmatic decision, aimed at maintenance cost reduction 
[3].
2. We use the same licensing policy as WebKit, i.e. BSD + LGPLv2 and no LGPLv3 
[4]
3. Our plan is to use stable branches of WebKitGTK as a base of our stable 
branches, e.g. now it is 2.12 branch [5]. This may cause lack of alignment with 
Qt release schedule sometimes.


[1] https://github.com/annulen/webkit
[2] http://code.qt.io/cgit/qt/qtwebkit.git/
[3] https://github.com/annulen/webkit/wiki/FAQ
[4] https://github.com/annulen/webkit/wiki/Licensing
[5] Reasons to use WebKitGTK instead of Apple's stable branch:
* we share more code with GTK than with Apple, especially on *nix
* on embedded, Apple is strongly focused on ARM64 whle GTK supports wider 
range of platforms
* GTK creates stable branches 2x more often than Apple => less lagging 
behind ToT

>
> Cheers,
> Lars
>
> On 04/06/16 22:40, "Development on behalf of Thiago Macieira" 
>  thiago.macie...@intel.com> wrote:
>
>> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu:
>>>  2. Is it OK to use "QtWebKit" name for this project, and if yes, how should
>>>  it be versioned?
>>>
>>>  Pros:
>>>  * It is a drop-in replacement for QtWebKit,
>>
>> Please don't. You can use the same soname if you are binary compatible, but
>> please call the module / project something different to indicate that it's
>> different from the previous effort. We cannot give the impression that it is 
>> a
>> continuation if it doesn't get as wide support as the old one had and feature
>> parity.
>>
>> PS: Windows CE is dropped from 5.8, so you don't have to worry about it.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Lars Knoll]

Hi Konstantin,



I’d be happy to host this project here on qt-project.org (and that includes of 
course both source code and bug tracking) :)

I don’t think it is a problem that the set of supported platforms is different 
from Qt WebKit in 5.6, this would have evolved in any way due to changes in the 
upstream project. I can also see why it would be hard to support certain things 
such as webkit2 on Windows (it has been difficult to support that in the past).

I don’t even see a larger problem with continuing the development in the 
existing qtwebkit repository under three conditions: First, the  branch names 
should make it clear that this is the new effort and not the older Qt WebKit 
that is being shipped with 5.6. Secondly the project needs to continue to 
either have full binary compatibility with the old QtWebKit in this case or 
bump the major .so version. A drop-in replacement (ie. Keeping BC) would be 
preferred if that’s possible. Thirdly, the documentation needs to be very 
explicit about the feature delta between old and new versions.

Cheers,
Lars


On 04/06/16 22:40, "Development on behalf of Thiago Macieira" 
 wrote:

>Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu:
>> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should
>> it be versioned?
>> 
>> Pros:
>> * It is a drop-in replacement for QtWebKit,
>
>Please don't. You can use the same soname if you are binary compatible, but 
>please call the module / project something different to indicate that it's 
>different from the previous effort. We cannot give the impression that it is a 
>continuation if it doesn't get as wide support as the old one had and feature 
>parity.
>
>PS: Windows CE is dropped from 5.8, so you don't have to worry about it.
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Allan Sandfeld Jensen]

On Saturday 04 June 2016, Thiago Macieira wrote:
> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu:
> > 2. Is it OK to use "QtWebKit" name for this project, and if yes, how
> > should it be versioned?
> > 
> > Pros:
> > * It is a drop-in replacement for QtWebKit,
> 
> Please don't. You can use the same soname if you are binary compatible, but
> please call the module / project something different to indicate that it's
> different from the previous effort. We cannot give the impression that it
> is a continuation if it doesn't get as wide support as the old one had and
> feature parity.
> 
I would suggest the name WebKitQt, that would fit the names of other upstream 
WebKit ports.

`Allan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebKit is coming back

[Thiago Macieira]

Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu:
> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should
> it be versioned?
> 
> Pros:
> * It is a drop-in replacement for QtWebKit,

Please don't. You can use the same soname if you are binary compatible, but 
please call the module / project something different to indicate that it's 
different from the previous effort. We cannot give the impression that it is a 
continuation if it doesn't get as wide support as the old one had and feature 
parity.

PS: Windows CE is dropped from 5.8, so you don't have to worry about it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWebKit is coming back

[Konstantin Tokarev]

Hi all,

As some of you may already know, there is an ongoing effort to revive QtWebKit 
by updating its WebKit engine to the current state of upstream at webkit.org 
[1]. 

While it still haven't reached feature parity with QtWebkit module hosted by Qt 
Project, its Widgets API is already in a good shape [2]. It also brings many 
new features, including support for large part of ES2015. It is binary 
compatible with QtWebKit 5.6 and can be used as drop-in replacement.

In this regard I have following questions to the Qt community:

1. Would you like to see this project as a part of Qt Project?

QtWebKit used to be a part of Qt Essentials (at least before its removal in 5.6 
release, I'm not sure what status does it have right now). I think it's neither 
feasible nor reasonable to restore this status it as a part of Qt Essentials, 
as it used to be before 5.6. We have a massive amount of 3rd party code so it 
would require much more work to support complete range of platforms and 
compilers, supported by Qt. In particular, full C++ 11 support is required from 
compiler, making minimal required GCC version as high as 4.8. (In the 
meanwhile, WebKit already started adoption of C++1y in trunk, though GCC 4.9 is 
still supported)

Also it's likely that supported platforms won't have perfect feature parity, 
and it's not clear if we are going to support WebKit 2 on Windows at all (if 
somebody reading this is interested, please join us!)

2. Is it OK to use "QtWebKit" name for this project, and if yes, how should it 
be versioned?

Pros:
* It is a drop-in replacement for QtWebKit, so it would simplify its downstream 
adoption, e.g. Linux distros could replace old insecure QtWebKit 5.6 with this 
new offering.
* QtWebKit is a name of Qt port of WebKit. This project is basically a rebase 
of Qt port code to the newer revision of trunk, so I don't see it as a fork of 
original project, but mere update.

Cons:
* Old QtWebKit will probably continue to exist, because range of supported 
platforms for new QtWebKit is more limited. Right now we have no plans to 
support Android, QNX or WinCE, it's also unclear if we will ever support WebKit 
2 on Windows. That means we need a way to make a clear difference between 
branches of the project.
* Users may mistakenly report problems specific to the new version to Qt JIRA. 
This issue could be worked around if Qt Project kindly allowed us to have a 
project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I could 
simply move such reports to another project and reassign. OTOH, it's quite 
possible that bugs reported against new QtWebKit affect 5.6 as well, for 
example see QTBUG-53532.

Of course, if anybody here is interested, any kind of help will be greatly 
appreciated.

Thanks in advance!


[1] https://github.com/annulen/webkit/wiki
[2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html
Latest development is in "qtwebkit-stable" branch, we are planning to release 
TP2 with many fixes and improvements really soon

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit to vcxproj

[Thiago Macieira]

Em sexta-feira, 27 de maio de 2016, às 08:47:01 BRT, raven-worx Software 
escreveu:
> QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore  
> and WebCore modules are missing.

In other words, most of WebKit.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit to vcxproj

[Konstantin Tokarev]

27.05.2016, 09:47, "raven-worx Software" :
> Oswald Buddenhagen  wrote:
>
>>  note that vcxproj support for the build of qt as a whole has been
>>  dropped a while ago, which is reflected by incomplete projects being
>>  generated. you may be able to use them successfully for debugging, but
>>  there is no way to use them for actually building qt reliably.
>
> i know. I had do to some fixing in the generated projects to make them
> compile. But those generated vcxproj files were essential to get
> started with.
>
> Now i have a Qt5 (almost all major modules) converted and compiling
> adn even running.
> QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore
> and WebCore modules are missing.
>
> The webkit sources already come with vcxproj files of these 3 modules.
> Can i take those instead directly? Meaning are those just core modules
> of Webkit? Or do they need some special Qt configuration?

These vcxproj have absolutely nothing to do with QtWebKit.
They are meant for building AppleWin and WinCairo ports.



-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit to vcxproj

[raven-worx Software]

Oswald Buddenhagen  wrote:


note that vcxproj support for the build of qt as a whole has been
dropped a while ago, which is reflected by incomplete projects being
generated. you may be able to use them successfully for debugging, but
there is no way to use them for actually building qt reliably.


i know. I had do to some fixing in the generated projects to make them  
compile.  But those generated vcxproj files were essential to get  
started with.


Now i have a Qt5 (almost all major modules) converted and compiling  
adn even running.
QtWebkit conversion also looks good so far. Only WTF, JavaScriptCore  
and WebCore modules are missing.


The webkit sources already come with vcxproj files of these 3 modules.  
Can i take those instead directly? Meaning are those just core modules  
of Webkit? Or do they need some special Qt configuration?




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit to vcxproj

[Oswald Buddenhagen]

On Wed, May 25, 2016 at 04:11:00PM +0200, raven-worx Software wrote:
> i am trying to create a vcxproj-Project of the QtWebKit module.
>
there is no hope whatsoever to get that working.

note that vcxproj support for the build of qt as a whole has been
dropped a while ago, which is reflected by incomplete projects being
generated. you may be able to use them successfully for debugging, but
there is no way to use them for actually building qt reliably.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit to vcxproj

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of raven-worx Software
> Sent: Wednesday, May 25, 2016 4:11 PM
> To: development@qt-project.org
> Subject: [Development] QtWebkit to vcxproj
> 
> Hi,
> 
> i am trying to create a vcxproj-Project of the QtWebKit module.

Which begs the question: Why?

I'm not claiming it's not possible. But building Qt itself within Visual Studio
Is not common, let alone Qt WebKit.

Kai

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWebkit to vcxproj

[raven-worx Software]

Hi,

i am trying to create a vcxproj-Project of the QtWebKit module.
For that i call "qmake -tp vc -r"
This results in error "Project ERROR: Strict subdir dependencies can  
only be used with subdirs template"

(https://bugreports.qt.io/browse/QTBUG-50099)

I can get rid of this error by commenting all lines which call  
addStrictSubdirOrderBetween() in the affected .pro files.


So far so good. I now have a solution which contains and successfully  
builds most QtWebKit projects.


The only projects i still have issues with are WTF, WebCore and  
JavaScriptCore.


WTF
--
Now when i call "qmake -tp vc WTF.pro" it returns without any output  
and it seems like it finished successfully. But no project is created  
and it silently fails.
Now when i call "qmake -tp vc WTF.pro -o WTF.vcxproj" instead i get  
several messages like:
"qtwebkit/Source/WTF/WTF.pri:16: 'use?' is not a recognized test  
function" messages


WebCore
-
calling "qmake -tp vc WebCore.pro -o WebCore.vcxproj" results in:

Info: creating cache file  
C:\Qt\Qt-5.x-git\qtwebkit\Source\WebCore\WebCore.vcxproj\.qmake.cache


Running configure tests...

Checking for fontconfig... QDir::mkpath: Empty or null file name
C:/Qt/Qt-5.x-git/qtbase/mkspecs/features/configure.prf:68: Cannot  
create directory .

Project ERROR: Aborting.



So my question is how can i create "Qt-ified" webkit core projects?


regards.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit fails to build

[Koehne Kai]

> -Original Message-
> [...]
>   Failed to open file:
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in
>   at
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl
>   line 306.
>   Makefile.WebCore.DerivedSources:786: recipe for target
> 'generated/MathMLNames.cpp' failed
>   mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9
>   mingw32-make[3]: Leaving directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
>   Makefile.WebCore:36: recipe for target 'sub-DerivedSources-pri-
> make_first-ordered' failed
>   mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-
> ordered] Error 2
>   mingw32-make[2]: Leaving directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
>   Makefile:218: recipe for target 'sub-Source-WebCore-WebCore-pro-
> make_first-ordered' failed
>   mingw32-make[1]: *** [sub-Source-WebCore-WebCore-pro-
> make_first-ordered] Error 2
>   mingw32-make[1]: Leaving directory 'Z:/src/kde/qt5/qtwebkit'
>   Makefile:1074: recipe for target 'module-qtwebkit-make_first'
> failed
>   mingw32-make: *** [module-qtwebkit-make_first] Error 2
> 
>   mathtags.in   exists at the location specified,
> just not being opened.

The call doesn't look wrong, and actually succeeds for me.

Maybe it's a defect of the perl version?  I'm using ActiveState Perl 5.16.3 (64 
bit).  

You can also try to run the above command manually.

Finally, any online virus scanners active? ;)

Hope this helps,

Kai Koehne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit fails to build

[Partha Bagchi]

[image: Mic Drop]
No suggestions at all? :(

I am stuck here and without Webkit, I cannot build digikam.


On Thu, Mar 31, 2016 at 2:25 PM, Partha Bagchi  wrote:

> I seem to have hit another snag. Hoping someone can point to a solution.
> In my build process, I am getting the following error:
>
> mingw32-make[2]: Entering directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> ( test -e Makefile.WebCore.DerivedSources ||
> Z:/src/kde/qt5/qtbase/bin/qmake.exe
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/DerivedSources.pri -o
> Makefile.WebCore.DerivedSources ) && mingw32-make -f
> Makefile.WebCore.DerivedSources
> WARNING: Failure to find: generated/InternalSettingsGenerated.idl
> mingw32-make[3]: Entering directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> perl -IZ:/src/kde/qt5/qtwebkit/Source/WebCore/bindings/scripts
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl --tags
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in --attrs
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathattrs.in --extraDefines
> "UNICODE ENABLE_3D_RENDERING=1 ENABLE_ACCELERATED_2D_CANVAS=1 ENABLE_BLOB=1
> ENABLE_CANVAS_PATH=1 ENABLE_CHANNEL_MESSAGING=1
> ENABLE_CSS_BOX_DECORATION_BREAK=1 ENABLE_CSS_COMPOSITING=1
> ENABLE_CSS_EXCLUSIONS=1 ENABLE_CSS_FILTERS=1 ENABLE_CSS_IMAGE_SET=1
> ENABLE_CSS_REGIONS=1 ENABLE_CSS_SHAPES=1 ENABLE_CSS_STICKY_POSITION=1
> ENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED=1 ENABLE_DATALIST_ELEMENT=1
> ENABLE_DETAILS_ELEMENT=1 ENABLE_DEVICE_ORIENTATION=1
> ENABLE_DOWNLOAD_ATTRIBUTE=1 ENABLE_FAST_MOBILE_SCROLLING=1 ENABLE_FILTERS=1
> ENABLE_FTPDIR=1 ENABLE_FULLSCREEN_API=1 ENABLE_GEOLOCATION=1
> ENABLE_GESTURE_EVENTS=1 ENABLE_ICONDATABASE=1 ENABLE_IFRAME_SEAMLESS=1
> ENABLE_INDEXED_DATABASE=1 ENABLE_INPUT_TYPE_COLOR=1 ENABLE_INSPECTOR=1
> ENABLE_INSPECTOR_SERVER=1 ENABLE_JAVASCRIPT_DEBUGGER=1
> ENABLE_LEGACY_NOTIFICATIONS=1 ENABLE_LEGACY_VIEWPORT_ADAPTION=1
> ENABLE_LEGACY_VENDOR_PREFIXES=1 ENABLE_LEGACY_WEB_AUDIO=1
> ENABLE_LINK_PREFETCH=1 ENABLE_METER_ELEMENT=1 ENABLE_MHTML=1
> ENABLE_NOTIFICATIONS=1 ENABLE_ORIENTATION_EVENTS=1
> ENABLE_PAGE_VISIBILITY_API=1 ENABLE_PROGRESS_ELEMENT=1
> ENABLE_RESOLUTION_MEDIA_QUERY=1 ENABLE_REQUEST_ANIMATION_FRAME=1
> ENABLE_SHARED_WORKERS=1 ENABLE_SMOOTH_SCROLLING=1 ENABLE_SQL_DATABASE=1
> ENABLE_SUBPIXEL_LAYOUT=1 ENABLE_SVG=1 ENABLE_SVG_FONTS=1
> ENABLE_TOUCH_ADJUSTMENT=1 ENABLE_TOUCH_EVENTS=1 ENABLE_VIDEO_TRACK=1
> ENABLE_VIEW_MODE_CSS_MEDIA=1 ENABLE_WEB_SOCKETS=1 ENABLE_WEB_TIMING=1
> ENABLE_WORKERS=1 ENABLE_XHR_TIMEOUT=1 WTF_USE_TILED_BACKING_STORE=1
> WTF_USE_CROSS_PLATFORM_CONTEXT_MENUS=1 HAVE_QTQUICK=1 HAVE_QTPRINTSUPPORT=1
> HAVE_QSTYLE=1 HAVE_QTTESTLIB=1 HAVE_QTPOSITIONING=1 HAVE_QTSENSORS=1
> WTF_USE_LIBXML2=1 ENABLE_XSLT=1 WTF_USE_ZLIB=1 WTF_USE_WEBP=1
> WTF_USE_LIBJPEG=1 WTF_USE_LIBPNG=1 ENABLE_NETSCAPE_PLUGIN_API=1
> PLUGIN_ARCHITECTURE_UNSUPPORTED=1 WTF_USE_3D_GRAPHICS=1 ENABLE_WEBGL=1
> ENABLE_VIDEO=1 WTF_USE_QT_MULTIMEDIA=1 HAVE_SQLITE3=1 ENABLE_TOUCH_SLIDER=1
> WTF_USE_LEVELDB=1 ENABLE_BATTERY_STATUS=0 ENABLE_CANVAS_PROXY=0
> ENABLE_CSP_NEXT=0 ENABLE_CSS_GRID_LAYOUT=0 ENABLE_CSS_HIERARCHIES=0
> ENABLE_CSS_IMAGE_ORIENTATION=0 ENABLE_CSS_IMAGE_RESOLUTION=0
> ENABLE_CSS_SHADERS=0 ENABLE_CSS_VARIABLES=0 ENABLE_CSS3_CONDITIONAL_RULES=0
> ENABLE_CSS3_TEXT=0 ENABLE_CSS3_TEXT_LINE_BREAK=0 ENABLE_DASHBOARD_SUPPORT=0
> ENABLE_DATAGRID=0 ENABLE_DATA_TRANSFER_ITEMS=0 ENABLE_DIRECTORY_UPLOAD=0
> ENABLE_FILE_SYSTEM=0 ENABLE_FONT_LOAD_EVENTS=0 ENABLE_GAMEPAD=0
> ENABLE_HIGH_DPI_CANVAS=0 ENABLE_INPUT_SPEECH=0 ENABLE_INPUT_TYPE_DATE=0
> ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE=0 ENABLE_INPUT_TYPE_DATETIMELOCAL=0
> ENABLE_INPUT_TYPE_MONTH=0 ENABLE_INPUT_TYPE_TIME=0 ENABLE_INPUT_TYPE_WEEK=0
> ENABLE_LEGACY_CSS_VENDOR_PREFIXES=0 ENABLE_MATHML=0 ENABLE_MEDIA_SOURCE=0
> ENABLE_MEDIA_STATISTICS=0 ENABLE_MEDIA_STREAM=0 ENABLE_MICRODATA=0
> ENABLE_MOUSE_CURSOR_SCALE=0 ENABLE_NAVIGATOR_CONTENT_UTILS=0
> ENABLE_NETWORK_INFO=0 ENABLE_NOSNIFF=0 ENABLE_PROXIMITY_EVENTS=0
> ENABLE_QUOTA=0 ENABLE_RESOURCE_TIMING=0 ENABLE_SCRIPTED_SPEECH=0
> ENABLE_SECCOMP_FILTERS=0 ENABLE_SHADOW_DOM=0 ENABLE_STYLE_SCOPED=0
> ENABLE_TEMPLATE_ELEMENT=0 ENABLE_TEXT_AUTOSIZING=0
> ENABLE_THREADED_HTML_PARSER=0 ENABLE_TOUCH_ICON_LOADING=0
> ENABLE_USER_TIMING=0 ENABLE_VIBRATION=0 ENABLE_WEB_AUDIO=0" --preprocessor
> "'Z:\src\kde\qt5\qtbase\bin\moc.exe' -E" --factory --wrapperFactory
> --outputDir generated
> Failed to open file: Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/
> mathtags.in at Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl
> line 306.
> Makefile.WebCore.DerivedSources:786: recipe for target
> 'generated/MathMLNames.cpp' failed
> mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9
> mingw32-make[3]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> Makefile.WebCore:36: recipe for target
> 'sub-DerivedSources-pri-make_first-ordered' failed
> mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-ordered] Error 2
> mingw32-make[2]: 

[Development] qtwebkit fails to build

[Partha Bagchi]

I seem to have hit another snag. Hoping someone can point to a solution. In
my build process, I am getting the following error:

mingw32-make[2]: Entering directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
( test -e Makefile.WebCore.DerivedSources ||
Z:/src/kde/qt5/qtbase/bin/qmake.exe
Z:/src/kde/qt5/qtwebkit/Source/WebCore/DerivedSources.pri -o
Makefile.WebCore.DerivedSources ) && mingw32-make -f
Makefile.WebCore.DerivedSources
WARNING: Failure to find: generated/InternalSettingsGenerated.idl
mingw32-make[3]: Entering directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
perl -IZ:/src/kde/qt5/qtwebkit/Source/WebCore/bindings/scripts
Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl --tags
Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in --attrs
Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathattrs.in --extraDefines
"UNICODE ENABLE_3D_RENDERING=1 ENABLE_ACCELERATED_2D_CANVAS=1 ENABLE_BLOB=1
ENABLE_CANVAS_PATH=1 ENABLE_CHANNEL_MESSAGING=1
ENABLE_CSS_BOX_DECORATION_BREAK=1 ENABLE_CSS_COMPOSITING=1
ENABLE_CSS_EXCLUSIONS=1 ENABLE_CSS_FILTERS=1 ENABLE_CSS_IMAGE_SET=1
ENABLE_CSS_REGIONS=1 ENABLE_CSS_SHAPES=1 ENABLE_CSS_STICKY_POSITION=1
ENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED=1 ENABLE_DATALIST_ELEMENT=1
ENABLE_DETAILS_ELEMENT=1 ENABLE_DEVICE_ORIENTATION=1
ENABLE_DOWNLOAD_ATTRIBUTE=1 ENABLE_FAST_MOBILE_SCROLLING=1 ENABLE_FILTERS=1
ENABLE_FTPDIR=1 ENABLE_FULLSCREEN_API=1 ENABLE_GEOLOCATION=1
ENABLE_GESTURE_EVENTS=1 ENABLE_ICONDATABASE=1 ENABLE_IFRAME_SEAMLESS=1
ENABLE_INDEXED_DATABASE=1 ENABLE_INPUT_TYPE_COLOR=1 ENABLE_INSPECTOR=1
ENABLE_INSPECTOR_SERVER=1 ENABLE_JAVASCRIPT_DEBUGGER=1
ENABLE_LEGACY_NOTIFICATIONS=1 ENABLE_LEGACY_VIEWPORT_ADAPTION=1
ENABLE_LEGACY_VENDOR_PREFIXES=1 ENABLE_LEGACY_WEB_AUDIO=1
ENABLE_LINK_PREFETCH=1 ENABLE_METER_ELEMENT=1 ENABLE_MHTML=1
ENABLE_NOTIFICATIONS=1 ENABLE_ORIENTATION_EVENTS=1
ENABLE_PAGE_VISIBILITY_API=1 ENABLE_PROGRESS_ELEMENT=1
ENABLE_RESOLUTION_MEDIA_QUERY=1 ENABLE_REQUEST_ANIMATION_FRAME=1
ENABLE_SHARED_WORKERS=1 ENABLE_SMOOTH_SCROLLING=1 ENABLE_SQL_DATABASE=1
ENABLE_SUBPIXEL_LAYOUT=1 ENABLE_SVG=1 ENABLE_SVG_FONTS=1
ENABLE_TOUCH_ADJUSTMENT=1 ENABLE_TOUCH_EVENTS=1 ENABLE_VIDEO_TRACK=1
ENABLE_VIEW_MODE_CSS_MEDIA=1 ENABLE_WEB_SOCKETS=1 ENABLE_WEB_TIMING=1
ENABLE_WORKERS=1 ENABLE_XHR_TIMEOUT=1 WTF_USE_TILED_BACKING_STORE=1
WTF_USE_CROSS_PLATFORM_CONTEXT_MENUS=1 HAVE_QTQUICK=1 HAVE_QTPRINTSUPPORT=1
HAVE_QSTYLE=1 HAVE_QTTESTLIB=1 HAVE_QTPOSITIONING=1 HAVE_QTSENSORS=1
WTF_USE_LIBXML2=1 ENABLE_XSLT=1 WTF_USE_ZLIB=1 WTF_USE_WEBP=1
WTF_USE_LIBJPEG=1 WTF_USE_LIBPNG=1 ENABLE_NETSCAPE_PLUGIN_API=1
PLUGIN_ARCHITECTURE_UNSUPPORTED=1 WTF_USE_3D_GRAPHICS=1 ENABLE_WEBGL=1
ENABLE_VIDEO=1 WTF_USE_QT_MULTIMEDIA=1 HAVE_SQLITE3=1 ENABLE_TOUCH_SLIDER=1
WTF_USE_LEVELDB=1 ENABLE_BATTERY_STATUS=0 ENABLE_CANVAS_PROXY=0
ENABLE_CSP_NEXT=0 ENABLE_CSS_GRID_LAYOUT=0 ENABLE_CSS_HIERARCHIES=0
ENABLE_CSS_IMAGE_ORIENTATION=0 ENABLE_CSS_IMAGE_RESOLUTION=0
ENABLE_CSS_SHADERS=0 ENABLE_CSS_VARIABLES=0 ENABLE_CSS3_CONDITIONAL_RULES=0
ENABLE_CSS3_TEXT=0 ENABLE_CSS3_TEXT_LINE_BREAK=0 ENABLE_DASHBOARD_SUPPORT=0
ENABLE_DATAGRID=0 ENABLE_DATA_TRANSFER_ITEMS=0 ENABLE_DIRECTORY_UPLOAD=0
ENABLE_FILE_SYSTEM=0 ENABLE_FONT_LOAD_EVENTS=0 ENABLE_GAMEPAD=0
ENABLE_HIGH_DPI_CANVAS=0 ENABLE_INPUT_SPEECH=0 ENABLE_INPUT_TYPE_DATE=0
ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE=0 ENABLE_INPUT_TYPE_DATETIMELOCAL=0
ENABLE_INPUT_TYPE_MONTH=0 ENABLE_INPUT_TYPE_TIME=0 ENABLE_INPUT_TYPE_WEEK=0
ENABLE_LEGACY_CSS_VENDOR_PREFIXES=0 ENABLE_MATHML=0 ENABLE_MEDIA_SOURCE=0
ENABLE_MEDIA_STATISTICS=0 ENABLE_MEDIA_STREAM=0 ENABLE_MICRODATA=0
ENABLE_MOUSE_CURSOR_SCALE=0 ENABLE_NAVIGATOR_CONTENT_UTILS=0
ENABLE_NETWORK_INFO=0 ENABLE_NOSNIFF=0 ENABLE_PROXIMITY_EVENTS=0
ENABLE_QUOTA=0 ENABLE_RESOURCE_TIMING=0 ENABLE_SCRIPTED_SPEECH=0
ENABLE_SECCOMP_FILTERS=0 ENABLE_SHADOW_DOM=0 ENABLE_STYLE_SCOPED=0
ENABLE_TEMPLATE_ELEMENT=0 ENABLE_TEXT_AUTOSIZING=0
ENABLE_THREADED_HTML_PARSER=0 ENABLE_TOUCH_ICON_LOADING=0
ENABLE_USER_TIMING=0 ENABLE_VIBRATION=0 ENABLE_WEB_AUDIO=0" --preprocessor
"'Z:\src\kde\qt5\qtbase\bin\moc.exe' -E" --factory --wrapperFactory
--outputDir generated
Failed to open file: Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/
mathtags.in at Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl
line 306.
Makefile.WebCore.DerivedSources:786: recipe for target
'generated/MathMLNames.cpp' failed
mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9
mingw32-make[3]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
Makefile.WebCore:36: recipe for target
'sub-DerivedSources-pri-make_first-ordered' failed
mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-ordered] Error 2
mingw32-make[2]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
Makefile:218: recipe for target
'sub-Source-WebCore-WebCore-pro-make_first-ordered' failed
mingw32-make[1]: *** [sub-Source-WebCore-WebCore-pro-make_first-ordered]
Error 2
mingw32-make[1]: Leaving directory 'Z:/src/kde/qt5/qtwebkit'
Makefile:1074: recipe for target 

[Development] QtWebKit: Turning off NPAPI plugin

[Ilya Kowalewski]

Hello!

Recently I was wondering how to unload specific NPAPI-based plugin (e.g.
flash player) via QtWebKit and haven't succeed so far. Do you guys have any
ideas on is it possible or not?

Ideally, I'd like to propogate a method to QWebView, which will unload()
npapi module there, but I am not sure that I know where it's
(PluginPackage) is being stored inside QtWebKit.

Thanks!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Simon Hausmann]

On Wednesday, November 28, 2012 09:38:24 AM Konstantin Ritt wrote:
 OR this could be a result of using QRawFont backdoor :)

That wouldn't explain though why it works on Mac and Linux, no?

There are two code paths in WebKit, a fast text code path and one for complex 
text (note how it's not called slow ;). I'm not 100% sure, but I think the 
chinese characters would likely go through the fast text code path, which is 
indeed using QRawFont. If that is the case, then it may be a matter of not 
finding the right fonts on Windows.


Simon
 
 @Fan Yang: did you file a bug? what is it's number?
 
 Konstantin
 
 2012/11/28 Hausmann Simon simon.hausm...@digia.com:
  Hi,
  
  If the issue appears only with QtWebKit on Windows but not with the same
  version on Mac or Linux/X11, then I think it is very unlikely that it can
  be resolved with a setting. These things should work out of the box with
  Qt (like you expect).
  
  It could be an issue in WebKit, maybe ICU or something in the font
  database causing us not to find fonts.
  
  Traditionally these kind of problems usually are either a text
  encoding/decoding  problem, a problem with shaping (unlikely) or a lack
  of fonts (or us not finding them).
  
  Simon
  
  --
  Sendt fra min Nokia N923.11.12 01:07 skrev Yang Fan:
  Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
  only Windows version has this problem, so I indicated it on Windows in
  the mail subject. I didn't create a bug report, since I think there may
  be some setting items of Qt/QtWebkit could resolve this problem.
  
  
  
  
  On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:
  
  At least for me, browser could display simplified Chinese characters
  correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now.
  Maybe someone with your configuration could verify it works or not.
  
  
  Have you created bug report?
  
  
  Regards,
  Liang
  
  
  
  From: development-bounces+liang.qi=digia@qt-project.org
  [development-bounces+liang.qi=digia@qt-project.org] on behalf of Yang
  Fan [missd...@gmail.com] Sent: Thursday, November 22, 2012 7:24 AM
  To: development@qt-project.org
  Subject: [Development] QtWebkit from Qt5 couldn't display Chinese
  characters correctly on Windows
  
  
  
  
  Hi All,
  
  Maybe it's not so suitable to ask here, since there's no reply in the
  Interest maillist. I built Qt5 from Git with MSVC2010 SP1 by myself, I
  used ICU5.0 to build QtWebkit. But I found it couldn't display Chinese
  characters correctly on Windows, the official example under
  qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did
  I miss something? Someone has reported this issue before but got no
  reply. https://qt-project.org/forums/viewthread/21022 . Any suggestion
  would be appreciated.
  
  
  Regards,
  Fan Yang
  
  
  
  
  ___
  Development mailing list
  Development@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/development
  
  
  
  
  
  --
  
  Regards,
  Fan Yang
  ___
  Development mailing list
  Development@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

Hi,

Thanks for your reply.
I created a bug at https://bugreports.qt-project.org/browse/QTWEBKIT-383.


On Wed, Nov 28, 2012 at 3:26 PM, Hausmann Simon simon.hausm...@digia.comwrote:

 Hi,

 If the issue appears only with QtWebKit on Windows but not with the same
 version on Mac or Linux/X11, then I think it is very unlikely that it can
 be resolved with a setting. These things should work out of the box with Qt
 (like you expect).

 It could be an issue in WebKit, maybe ICU or something in the font
 database causing us not to find fonts.

 Traditionally these kind of problems usually are either a text
 encoding/decoding  problem, a problem with shaping (unlikely) or a lack of
 fonts (or us not finding them).

 Simon

 --
 Sendt fra min Nokia N923.11.12 01:07 skrev Yang Fan:
 Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
 only Windows version has this problem, so I indicated it on Windows in the
 mail subject.
 I didn't create a bug report, since I think there may be some setting
 items of Qt/QtWebkit could resolve this problem.




 On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

 At least for me, browser could display simplified Chinese characters
 correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe
 someone with your configuration could verify it works or not.


 Have you created bug report?


 Regards,
 Liang



 From: 
 development-bounces+liang.qi=digia@qt-project.org[development-bounces+liang.qi=
 digia@qt-project.org] on behalf of Yang Fan [missd...@gmail.com]
 Sent: Thursday, November 22, 2012 7:24 AM
 To: development@qt-project.org
 Subject: [Development] QtWebkit from Qt5 couldn't display Chinese
 characters correctly on Windows




 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.


 Regards,
 Fan Yang




 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development





 --

 Regards,
 Fan Yang




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

Any update?


On Tue, Nov 27, 2012 at 8:30 AM, Yang Fan missd...@gmail.com wrote:

 Any update?


 On Fri, Nov 23, 2012 at 8:07 AM, Yang Fan missd...@gmail.com wrote:

 Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
 only Windows version has this problem, so I indicated it on Windows in the
 mail subject.
 I didn't create a bug report, since I think there may be some setting
 items of Qt/QtWebkit could resolve this problem.


 On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

  At least for me, browser could display simplified Chinese characters
 correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe
 someone with your configuration could verify it works or not.

  Have you created bug report?

  Regards,
 Liang

  --
 *From:* 
 development-bounces+liang.qi=digia@qt-project.org[development-bounces+liang.qi=
 digia@qt-project.org] on behalf of Yang Fan [missd...@gmail.com]
 *Sent:* Thursday, November 22, 2012 7:24 AM
 *To:* development@qt-project.org
 *Subject:* [Development] QtWebkit from Qt5 couldn't display Chinese
 characters correctly on Windows


 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.

 Regards,
 Fan Yang



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development




 --
 Regards,
 Fan Yang




 --
 Regards,
 Fan Yang




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Hausmann Simon]

Hi,

If the issue appears only with QtWebKit on Windows but not with the same 
version on Mac or Linux/X11, then I think it is very unlikely that it can be 
resolved with a setting. These things should work out of the box with Qt (like 
you expect).

It could be an issue in WebKit, maybe ICU or something in the font database 
causing us not to find fonts.

Traditionally these kind of problems usually are either a text 
encoding/decoding  problem, a problem with shaping (unlikely) or a lack of 
fonts (or us not finding them).

Simon

--
Sendt fra min Nokia N923.11.12 01:07 skrev Yang Fan:
Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10, only 
Windows version has this problem, so I indicated it on Windows in the mail 
subject.
I didn't create a bug report, since I think there may be some setting items of 
Qt/QtWebkit could resolve this problem.




On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

At least for me, browser could display simplified Chinese characters correctly 
on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe someone with 
your configuration could verify it works or not. 


Have you created bug report? 


Regards,
Liang



From: development-bounces+liang.qi=digia@qt-project.org 
[development-bounces+liang.qi=digia@qt-project.org] on behalf of Yang Fan 
[missd...@gmail.com]
Sent: Thursday, November 22, 2012 7:24 AM
To: development@qt-project.org
Subject: [Development] QtWebkit from Qt5 couldn't display Chinese characters 
correctly on Windows




Hi All,

Maybe it's not so suitable to ask here, since there's no reply in the Interest 
maillist.
I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build 
QtWebkit. But I found it couldn't display Chinese characters correctly on 
Windows, the official example under 
qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I miss 
something? Someone has reported this issue before but got no reply. 
https://qt-project.org/forums/viewthread/21022 .
Any suggestion would be appreciated.


Regards,
Fan Yang




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development





-- 

Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Konstantin Ritt]

OR this could be a result of using QRawFont backdoor :)

@Fan Yang: did you file a bug? what is it's number?

Konstantin


2012/11/28 Hausmann Simon simon.hausm...@digia.com:
 Hi,

 If the issue appears only with QtWebKit on Windows but not with the same 
 version on Mac or Linux/X11, then I think it is very unlikely that it can be 
 resolved with a setting. These things should work out of the box with Qt 
 (like you expect).

 It could be an issue in WebKit, maybe ICU or something in the font database 
 causing us not to find fonts.

 Traditionally these kind of problems usually are either a text 
 encoding/decoding  problem, a problem with shaping (unlikely) or a lack of 
 fonts (or us not finding them).

 Simon

 --
 Sendt fra min Nokia N923.11.12 01:07 skrev Yang Fan:
 Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10, only 
 Windows version has this problem, so I indicated it on Windows in the mail 
 subject.
 I didn't create a bug report, since I think there may be some setting items 
 of Qt/QtWebkit could resolve this problem.




 On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

 At least for me, browser could display simplified Chinese characters 
 correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe 
 someone with your configuration could verify it works or not.


 Have you created bug report?


 Regards,
 Liang



 From: development-bounces+liang.qi=digia@qt-project.org 
 [development-bounces+liang.qi=digia@qt-project.org] on behalf of Yang Fan 
 [missd...@gmail.com]
 Sent: Thursday, November 22, 2012 7:24 AM
 To: development@qt-project.org
 Subject: [Development] QtWebkit from Qt5 couldn't display Chinese characters 
 correctly on Windows




 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the 
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build 
 QtWebkit. But I found it couldn't display Chinese characters correctly on 
 Windows, the official example under 
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I 
 miss something? Someone has reported this issue before but got no reply. 
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.


 Regards,
 Fan Yang




 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development





 --

 Regards,
 Fan Yang
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

Any update?


On Fri, Nov 23, 2012 at 8:07 AM, Yang Fan missd...@gmail.com wrote:

 Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
 only Windows version has this problem, so I indicated it on Windows in the
 mail subject.
 I didn't create a bug report, since I think there may be some setting
 items of Qt/QtWebkit could resolve this problem.


 On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

  At least for me, browser could display simplified Chinese characters
 correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe
 someone with your configuration could verify it works or not.

  Have you created bug report?

  Regards,
 Liang

  --
 *From:* 
 development-bounces+liang.qi=digia@qt-project.org[development-bounces+liang.qi=
 digia@qt-project.org] on behalf of Yang Fan [missd...@gmail.com]
 *Sent:* Thursday, November 22, 2012 7:24 AM
 *To:* development@qt-project.org
 *Subject:* [Development] QtWebkit from Qt5 couldn't display Chinese
 characters correctly on Windows


 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.

 Regards,
 Fan Yang



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development




 --
 Regards,
 Fan Yang




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Konstantin Ritt]

Hi,

Plz check if the rich text editor example shows these Chinese
characters correctly.

Konstantin


2012/11/22 Yang Fan missd...@gmail.com:

 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.

 Regards,
 Fan Yang



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Qi Liang]

At least for me, browser could display simplified Chinese characters correctly 
on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe someone with 
your configuration could verify it works or not.

Have you created bug report?

Regards,
Liang


From: development-bounces+liang.qi=digia@qt-project.org 
[development-bounces+liang.qi=digia@qt-project.org] on behalf of Yang Fan 
[missd...@gmail.com]
Sent: Thursday, November 22, 2012 7:24 AM
To: development@qt-project.org
Subject: [Development] QtWebkit from Qt5 couldn't display Chinese characters 
correctly on Windows


Hi All,

Maybe it's not so suitable to ask here, since there's no reply in the Interest 
maillist.
I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build 
QtWebkit. But I found it couldn't display Chinese characters correctly on 
Windows, the official example under 
qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I miss 
something? Someone has reported this issue before but got no reply. 
https://qt-project.org/forums/viewthread/21022 .
Any suggestion would be appreciated.

Regards,
Fan Yang


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

Yes, I checked this issue on Windows 7, Mac OSX 10.6.8 and Ubuntu 12.10,
only Windows version has this problem, so I indicated it on Windows in the
mail subject.
I didn't create a bug report, since I think there may be some setting items
of Qt/QtWebkit could resolve this problem.


On Thu, Nov 22, 2012 at 11:03 PM, Qi Liang liang...@digia.com wrote:

  At least for me, browser could display simplified Chinese characters
 correctly on mac. BTW, all the old text codecs are in QtCore 5.0 now. Maybe
 someone with your configuration could verify it works or not.

  Have you created bug report?

  Regards,
 Liang

  --
 *From:* 
 development-bounces+liang.qi=digia@qt-project.org[development-bounces+liang.qi=
 digia@qt-project.org] on behalf of Yang Fan [missd...@gmail.com]
 *Sent:* Thursday, November 22, 2012 7:24 AM
 *To:* development@qt-project.org
 *Subject:* [Development] QtWebkit from Qt5 couldn't display Chinese
 characters correctly on Windows


 Hi All,

 Maybe it's not so suitable to ask here, since there's no reply in the
 Interest maillist.
 I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
 QtWebkit. But I found it couldn't display Chinese characters correctly on
 Windows, the official example under
 qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
 miss something? Someone has reported this issue before but got no reply.
 https://qt-project.org/forums/viewthread/21022 .
 Any suggestion would be appreciated.

 Regards,
 Fan Yang



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

The example under qt5\qtbase\examples\widgets\richtext\textedit seems OK.
It could input Chinese characters, opens a text file contains Chinese
characters and displays correctly.


On Thu, Nov 22, 2012 at 10:34 PM, Konstantin Ritt ritt...@gmail.com wrote:

 Hi,

 Plz check if the rich text editor example shows these Chinese
 characters correctly.

 Konstantin


 2012/11/22 Yang Fan missd...@gmail.com:
 
  Hi All,
 
  Maybe it's not so suitable to ask here, since there's no reply in the
  Interest maillist.
  I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
  QtWebkit. But I found it couldn't display Chinese characters correctly on
  Windows, the official example under
  qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did
 I
  miss something? Someone has reported this issue before but got no reply.
  https://qt-project.org/forums/viewthread/21022 .
  Any suggestion would be appreciated.
 
  Regards,
  Fan Yang
 
 
 
  ___
  Development mailing list
  Development@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/development
 




-- 
Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtWebkit from Qt5 couldn't display Chinese characters correctly on Windows

[Yang Fan]

Hi All,

Maybe it's not so suitable to ask here, since there's no reply in the
Interest maillist.
I built Qt5 from Git with MSVC2010 SP1 by myself, I used ICU5.0 to build
QtWebkit. But I found it couldn't display Chinese characters correctly on
Windows, the official example under
qt5\qtwebkit-examples-and-demos\examples\browser has the same issue. Did I
miss something? Someone has reported this issue before but got no reply.
https://qt-project.org/forums/viewthread/21022 .
Any suggestion would be appreciated.

Regards,
Fan Yang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qtwebkit changes to qt/4.8

[Girish Ramakrishnan]

Hi QtWebKit team,
What's the best way to deal with patches to QtWebKit1/qt4 (for
example, http://codereview.qt-project.org/#change,21292) ?

Is the strategy still to get it all upstream? Since, I assume, there
is QtWebKit 2.3 planned how will this patch end up in Qt? (Is the
answer that it won't ever end up in Qt4?)

If the answer is to get it all upstream  - would you agree that the
sanity bot should complain when anyone tries to commit to
src/3rdparty/webkit ?

Thanks,
Girish
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit changes to qt/4.8

[Girish Ramakrishnan]

Hi,

On Fri, Mar 30, 2012 at 4:57 PM, Girish Ramakrishnan
gir...@forwardbias.in wrote:
 Hi QtWebKit team,
 is QtWebKit 2.3 planned how will this patch end up in Qt? (Is the

Correction, I meant 'Since there is no QtWebKit 2.3 planned...'

Girish
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit-examples-and-demos.patch

[Rohan McGovern]

Philip Ashmore said:
 Hi there.
 Please find attached a patch for qtwebkit-examples-and-demos that allows 
 the build to complete on Debian Wheezy amd64.
 
 Please also note that this patch includes a previously submitted patch, 
 not yet applied.
 
 Also, examples/webkit/fancybrowser/fancybrowser.pro contains a 
 TARGET.EPOCHEAPSIZE in symbian{} that seems to contain invalid utf-8 
 characters.
 

Hi Philip,

Are you able to push your patches into the gerrit code review tool at
http://codereview.qt-project.org ?
(documentation at http://wiki.qt-project.org/Code_Reviews )

Patches generally can't be accepted unless the copyright holder has
signed a Contributor License Agreement (CLA), which is managed through
the code review tool.  Loose patches to mailing lists or to the bug
tracker may not make satisfactory progress.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit-examples-and-demos.patch

[a.gra...@gmail.com]

Hi,

On 11 February 2012 21:15, Philip Ashmore cont...@philipashmore.com wrote:
 Hi there.
 Please find attached a patch for qtwebkit-examples-and-demos that allows the
 build to complete on Debian Wheezy amd64.

 Please also note that this patch includes a previously submitted patch, not
 yet applied.

 Also, examples/webkit/fancybrowser/fancybrowser.pro contains a
 TARGET.EPOCHEAPSIZE in symbian{} that seems to contain invalid utf-8
 characters.

nice! Today I wasn't able to build the whole qt5 code because of an
error in qtwebkit-examples-and-demos :)
You've been faster than me fixing the code, thank you som much!

-- 
Andrea Grandi - Nokia Qt Ambassador
Ubuntu Member: https://launchpad.net/~andreagrandi
website: http://www.andreagrandi.it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qtwebkit-examples-and-demos/examples/browser/cookiejar.cpp is missing #include QNetworkCookie

[Philip Ashmore]

Hi there.

qtwebkit-examples-and-demos/examples/browser/cookiejar.cpp is missing 
#include QNetworkCookie.


Please find the patch attached.

Regards,
Philip Ashmore
diff --git a/examples/browser/cookiejar.cpp b/examples/browser/cookiejar.cpp
index d65573d..194f25b 100644
--- a/examples/browser/cookiejar.cpp
+++ b/examples/browser/cookiejar.cpp
@@ -61,7 +61,7 @@
 #include QtWebKit/QWebSettings
 
 #include QtCore/QDebug
-
+#include QNetworkCookie
 static const unsigned int JAR_VERSION = 23;
 
 QT_BEGIN_NAMESPACE
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development