Re: Policy regarding QtWebKit and QtScript

Em sábado, 5 de março de 2016, às 08:09:22 PST, Thomas Friedrichsmeier escreveu: > I would advise KDE projects to be very > reluctant about moving away from QtWebKit, unless and until they have > very compelling reason to do so Like security. That's a compelling reason. The other day I noticed s

Re: Policy regarding QtWebKit and QtScript

Hi, sorry for a somewhat bitter tone, I find it a bit hard to avoid(*): On Sat, 5 Mar 2016 11:37:48 +0100 Allan Sandfeld Jensen wrote: > On Saturday 05 March 2016, Thomas Lübking wrote: > > On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier > > wrote: > > > QtWebEngine can _only_ be

Re: Policy regarding QtWebKit and QtScript

Hi, On Saturday, 5 March 2016, 08:09:22 CET, Thomas Friedrichsmeier wrote: > Hi, > > On Fri, 25 Dec 2015 12:42:26 +0100 > > Milian Wolff wrote: > > Sorry, but how is "it takes long to compile" and argument for or > > against a piece of software if there is no feature equivalent > > alternative

Re: Policy regarding QtWebKit and QtScript

On Saturday 05 March 2016, Thomas Lübking wrote: > On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier wrote: > > QtWebEngine can _only_ be compiled using (free > > as in beer) MSVC 2013. In particular, MinGW is explicitly _not_ > > supported. > > Out of pure curiosity: got details on t

Re: Policy regarding QtWebKit and QtScript

Hi, On Sat, 05 Mar 2016 09:58:34 +0100 Niels Ole Salscheider wrote: > On Saturday, 5 March 2016, 08:09:22 CET, Thomas Friedrichsmeier wrote: > > This is not only an uncomfortable situation for a free software > > project to be in. If you're trying to interface with third > > libraries that happen

Re: Policy regarding QtWebKit and QtScript

Hi, On Sat, 05 Mar 2016 10:35:23 +0100 Thomas Lübking wrote: > On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier wrote: > > QtWebEngine can _only_ be compiled using (free > > as in beer) MSVC 2013. In particular, MinGW is explicitly _not_ > > supported. > > Out of pure curiosity: go

Re: Policy regarding QtWebKit and QtScript

On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier wrote: QtWebEngine can _only_ be compiled using (free as in beer) MSVC 2013. In particular, MinGW is explicitly _not_ supported. Out of pure curiosity: got details on this? MSVC 2013 hardly supersets the GNU toolchain and the code c

Re: Policy regarding QtWebKit and QtScript

Hi, On Fri, 25 Dec 2015 12:42:26 +0100 Milian Wolff wrote: > Sorry, but how is "it takes long to compile" and argument for or > against a piece of software if there is no feature equivalent > alternative that takes less time to compile? > > Qt WebEngine is far easier to compile than Qt WebKit in

Re: Policy regarding QtWebKit and QtScript

Adriaan de Groot wrote: > Kevin, first off thank you for responding so carefully to Vadim and to me. > It does make a difference to porting efforts. I'm glad to be of help. I also spent quite some time fighting with this thing and I'm not entirely done yet, so I know how you feel. And you guys h

Re: Policy regarding QtWebKit and QtScript

Kevin, first off thank you for responding so carefully to Vadim and to me. It does make a difference to porting efforts. On Wednesday 06 January 2016 18:11:25 Kevin Kofler wrote: > unbundling doesn't seem to be the main focus. And the reason there are so > many patches is because they produced a

Re: Policy regarding QtWebKit and QtScript

Adriaan de Groot wrote: > - Why am I building ninja when it's already packaged externally? export NINJA_PATH=/usr/bin/ninja (or ninja-build or however your OS's package calls the binary) is enough to fix that. > - Why am I building yasm? Add GYP_CONFIG += "use_system_yasm=1" to your src/core/c

Re: Policy regarding QtWebKit and QtScript

I've been digging deep into QtWebEngine in the hope of to polishing it up for Fedora (which sounds less hopeless now that Fedora has become less strict on bundled libraries), seeing how QtWebKit has no future with nobody fixing security bugs in it, so let me clear up a few misconceptions in your

Re: Policy regarding QtWebKit and QtScript

On Wednesday 30 December 2015, Lisandro Damián Nicanor Pérez Meyer wrote: > On Wednesday 30 December 2015 00:19:39 Allan Sandfeld Jensen wrote: > [snip] > > > > - Same applies to most of the bundled stuff. A lot of the FreeBSD > > > patches > > > > > > for Chromium itself are, indeed, unbundlin

Re: Policy regarding QtWebKit and QtScript

On Wednesday 30 December 2015 00:19:39 Allan Sandfeld Jensen wrote: [snip] > > - Same applies to most of the bundled stuff. A lot of the FreeBSD patches > > > > for Chromium itself are, indeed, unbundlings. But those need to be re-done > > for webengine, because who knows how the versions differ.

Re: Policy regarding QtWebKit and QtScript

2015-12-25 15:01 GMT+03:00 Adriaan de Groot : > On Friday 25 December 2015 12:42:26 you wrote: >> On Donnerstag, 24. Dezember 2015 12:14:06 CET Adriaan de Groot wrote: >> > On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer >> > >> > wrote: >> > > > The idea that users may hav

Re: Policy regarding QtWebKit and QtScript

On Tuesday 29 December 2015, Adriaan de Groot wrote: > On Wednesday 30 December 2015 01:34:46 Vadim Zhukov wrote: > > There is a little chance QtWebEngine will be ported on OpenBSD: if > > someone will come in and fix Chromium and QtWebEngine to bundle less, > > at least. I won't volunteer: handlin

Re: Policy regarding QtWebKit and QtScript

On Wednesday 30 December 2015 01:34:46 Vadim Zhukov wrote: > There is a little chance QtWebEngine will be ported on OpenBSD: if > someone will come in and fix Chromium and QtWebEngine to bundle less, > at least. I won't volunteer: handling a few hundreds of KDE ports + > ports of Qt itself is alrea

Re: Policy regarding QtWebKit and QtScript

On Friday 25 December 2015 13:43:22 Nicolás Alvarez wrote: [snip] > The linking step needs 4GB of RAM At least on the qtwebkit case that's the amount of RAM without generating debugging symbols (or maybe using stabs). I also know that Allan has worked toward deembedding stuff from QtWebEngine.

Re: Policy regarding QtWebKit and QtScript

On Friday, 25 December 2015, 14:28:14 CET, Thomas Lübking wrote: > On Freitag, 25. Dezember 2015 12:42:26 CEST, Milian Wolff wrote: > > Sorry, but how is "it takes long to compile" and argument for or against a > > piece of software if there is no feature equivalent alternative that takes > > less

Re: Policy regarding QtWebKit and QtScript

On Saturday 26 December 2015 11:50:16 Adriaan de Groot wrote: > On Friday 25 December 2015 13:34:01 Allan Sandfeld Jensen wrote: > > Does Chromium build on FreeBSD already? In know in QtWebEngine we have > > several qmake conditions that would need to be changed from linux to > > posix:!mac, but I

Re: Policy regarding QtWebKit and QtScript

On Friday 25 December 2015 13:34:01 Allan Sandfeld Jensen wrote: > Does Chromium build on FreeBSD already? In know in QtWebEngine we have > several qmake conditions that would need to be changed from linux to > posix:!mac, but I haven't tried because I wasn't sure if FreeBSD was even > support by

Re: Policy regarding QtWebKit and QtScript

> On Dec 25, 2015, at 10:28, Thomas Lübking wrote: > >> On Freitag, 25. Dezember 2015 12:42:26 CEST, Milian Wolff wrote: >> >> Sorry, but how is "it takes long to compile" and argument for or against a >> piece of software if there is no feature equivalent alternative that takes >> less time

Re: Policy regarding QtWebKit and QtScript

On Freitag, 25. Dezember 2015 12:42:26 CEST, Milian Wolff wrote: Sorry, but how is "it takes long to compile" and argument for or against a piece of software if there is no feature equivalent alternative that takes less time to compile? How demanding is it exactly? Considering Gentoo users, i

Re: Policy regarding QtWebKit and QtScript

On Friday 25 December 2015, Adriaan de Groot wrote: > On Friday 25 December 2015 12:42:26 you wrote: > > On Donnerstag, 24. Dezember 2015 12:14:06 CET Adriaan de Groot wrote: > > > On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez > > > Meyer > > > > > > wrote: > > > > > The idea

Re: Policy regarding QtWebKit and QtScript

On Friday 25 December 2015 12:42:26 you wrote: > On Donnerstag, 24. Dezember 2015 12:14:06 CET Adriaan de Groot wrote: > > On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer > > > > wrote: > > > > The idea that users may have remainders of QtWebKit 5.5 on their disk > > > > (

Re: Policy regarding QtWebKit and QtScript

On Donnerstag, 24. Dezember 2015 12:14:06 CET Adriaan de Groot wrote: > On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer > > wrote: > > > The idea that users may have remainders of QtWebKit 5.5 on their disk > > > (or > > > not and thus unresolvable linkage) and install Qt

Re: Policy regarding QtWebKit and QtScript

On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer wrote: > > The idea that users may have remainders of QtWebKit 5.5 on their disk (or > > not and thus unresolvable linkage) and install Qt 5.6 and still have (not > > recompiled) client code that is now gonna crash scares me

Re: Policy regarding QtWebKit and QtScript

Hi, >> Isn't the designated successor for QtScript QJSEngine >> (I even assumed there should be some porting tools?) > > That's what I meant under 'qml engines'. :) > > A relevant mail by Frederik: > http://lists.qt-project.org/pipermail/interest/2015-June/017446.html for KTextEditor: 1) kross

Re: Policy regarding QtWebKit and QtScript

On Wednesday 23 December 2015 00:06:18 Luigi Toscano wrote: > Shouldn't it be the other way around? Workable solution first and drop the > old one later? The big problem of keeping qtwebkit in the 5.6 release is that it would need to be supported for the 3 years of the long term support release a

Re: Policy regarding QtWebKit and QtScript

On Tuesday 22 December 2015 16:07:06 Lisandro Damián Nicanor Pérez Meyer wrote: > IIRC Thiago said that it didn't use private stuff, so recompiling should be > more than enough (in case it is really needed). I might be wrong. But that's the kind of breakage that is easily caught before Qt relea

Re: Policy regarding QtWebKit and QtScript

On Wed, Dec 23, 2015 at 12:06 AM, Luigi Toscano wrote: > > Shouldn't it be the other way around? Workable solution first and drop the > old > one later? > > That's exactly what people said when plans to drop QtWebKit and QtScript were first announced. As people provided specific examples of com

Re: Policy regarding QtWebKit and QtScript

Pau Garcia i Quiles ha scritto: > > > On Tue, Dec 22, 2015 at 11:02 PM, Albert Astals Cid > wrote: > > > > Soon Qt 5.6 will be released and with it, 2 quite widely used > > frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but > > I think this

Re: Policy regarding QtWebKit and QtScript

On Tue, Dec 22, 2015 at 11:02 PM, Albert Astals Cid wrote: > > > Soon Qt 5.6 will be released and with it, 2 quite widely used > > frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but > > I think this is much less of a problem. > > As far as I understand they are just going to be

Re: Policy regarding QtWebKit and QtScript

El Tuesday 22 December 2015, a les 18:10:44, Aleix Pol va escriure: > Hi, > Soon Qt 5.6 will be released and with it, 2 quite widely used > frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but > I think this is much less of a problem. As far as I understand they are just going to

Re: Policy regarding QtWebKit and QtScript

On Tuesday 22 December 2015 20:03:22 Thomas Lübking wrote: > On Dienstag, 22. Dezember 2015 19:44:21 CEST, Aleix Pol wrote: > > compiling for some time, but that's not a reason to rely on it on our > > side. > > Sure, getting rid of it is mandatory. > What worries me is that this *break* happens i

Re: Policy regarding QtWebKit and QtScript

On Tuesday 22 December 2015 19:50:43 Allan Sandfeld Jensen wrote: > On Tuesday 22 December 2015, Thomas Lübking wrote: > > On Dienstag, 22. Dezember 2015 19:05:23 CEST, Ivan Čukić wrote: > > > So, using Kross would mean implementing the kjs backend for it that we > > > had in 4.x times? > > > > Is

Re: Policy regarding QtWebKit and QtScript

On Dienstag, 22. Dezember 2015 19:44:21 CEST, Aleix Pol wrote: compiling for some time, but that's not a reason to rely on it on our side. Sure, getting rid of it is mandatory. What worries me is that this *break* happens in a *minor* Qt release. Should generally not happen. Period. It shoul

Re: Policy regarding QtWebKit and QtScript

On Tuesday 22 December 2015, Thomas Lübking wrote: > On Dienstag, 22. Dezember 2015 19:05:23 CEST, Ivan Čukić wrote: > > So, using Kross would mean implementing the kjs backend for it that we > > had in 4.x times? > > Isn't the designated successor for QtScript QJSEngine (I even assumed there > sh

Re: Policy regarding QtWebKit and QtScript

> Isn't the designated successor for QtScript QJSEngine > (I even assumed there should be some porting tools?) That's what I meant under 'qml engines'. :) A relevant mail by Frederik: http://lists.qt-project.org/pipermail/interest/2015-June/017446.html Cheers, Ivan -- KDE, ivan.cu...@kde.org, h

Re: Policy regarding QtWebKit and QtScript

On Dienstag, 22. Dezember 2015 19:05:23 CEST, Ivan Čukić wrote: So, using Kross would mean implementing the kjs backend for it that we had in 4.x times? Isn't the designated successor for QtScript QJSEngine (I even assumed there should be some porting tools?) About QtWebkit - what exactly do

Re: Policy regarding QtWebKit and QtScript

> QtScript support in Kross depends on Qt's QtScript. Meant to reimplement the scripting mechanisms we have to use Kross instead of QtScript - to expose the scriptable objects to Kross. IIRC (haven't checked Kross for a long time) it supported accessing Qt objects and properties/methods, was able

Re: Policy regarding QtWebKit and QtScript

2015-12-22 20:21 GMT+03:00 Ivan Čukić : > As for QtScript, I see two approaches: > - kross (what is the state of it?) > - qml engines Hi Ivan, I don't get what you are suggesting. QtScript support in Kross depends on Qt's QtScript. -- Alexander Potashev

Re: Policy regarding QtWebKit and QtScript

http://blog.qt.io/blog/2015/12/18/qt-5-6-beta-released/ > Webkit and Qt Quick 1 Removed > > We have removed WebKit and Qt Quick 1 from Qt 5.6 release content. > The source code is still available in the repositories, but these are not > packaged with Qt 5.6 any more. **Qt Script remains deprecated

Policy regarding QtWebKit and QtScript

Hi, Soon Qt 5.6 will be released and with it, 2 quite widely used frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but I think this is much less of a problem. I'd say we need a plan to figure out what to do with these dependencies. I don't think assuming that they will stay around