Re: Policy regarding QtWebKit and QtScript

[Thiago Macieira]

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 something strange with one of my online web mail 
accounts I only access using rekonq (QtWebKit), so it may be that the engine 
is already past expiration date.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

Re: Policy regarding QtWebKit and QtScript

[Thomas Friedrichsmeier]

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 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 cannot
> > make use of MSVC's "let's try to compile this junk, despite it's
> > not nearly valid c++" features, because it generally still needs to
> > compile on other systems.
> > 
> Chromium doesn't support it, and generally we try to stick to the
> same platforms Chromium support. We haven't actually investigated how
> much work it would be to make it work.

I think making a credible effort in that direction is really the _least_
thing you can and should do. I do understand your whole idea is to get
by with fewer (or no) patches(**). And I understand you are not
particularly keen to even think about introducing a significant
patch-set, when you have long since committed to QtWebEngine. But that
strategy simply carries a cost, and I'm not quite sure that this is
well-understood, yet.

As things stand, I think you are effectively phasing out MinGW-support,
and to be honest, my impression is that you have not been terribly
upfront about it, so far.

Regards
Thomas

---

(*) So, some background, in case anyone is interested: My application
needs an internal HTML-browser for several purposes. It also interfaces
with MinGW-only library / environment. (Why not try to support MSVC for
that library, I hear you ask? Because it has literally 8000+ add-on
packages, not all of which are cross-platform, not all of which contain
compiled code, but thousands of which are distributed as -
MinGW-compiled - binaries.)

I am lucky on two counts, here: First, I don't need to display any
remote HTML, and so I can get by using QtWebKit for now. But the time
will come when some of the add-ons start relying on browser features
that are not supported by QtWebKit, or some third application/framework,
that I'd like to interface with, will hard-depend on QtWebEngine.
Second, I am interfacing with a C-only API, and so I can (sort of) get
along with MSVC. But there are more subtleties in mixing the two
compilers than an incompatible C++-ABI, and these are no-fun at all to
debug. As one example, it took me almost an entire day to debug a
(deterministic!) crash, when the MinGW-library was trying to free a
pointer that I had to allocate myself (with MSVC). Getting lucky,
again, I did find a way to hack around this. But there are more,
non-derministic issues that appear to be unique to the MSVC-build.

(**) On the other hand, at least these patches would not be
Qt-specific. Even if they won't be upstreamed, I imagine you could
count on a least some community support in maintaining them.


pgpop31tLWwA3.pgp
Description: OpenPGP digital signature

Re: Policy regarding QtWebKit and QtScript

[Niels Ole Salscheider]

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 that takes less time to compile?
> > 
> > Qt WebEngine is far easier to compile than Qt WebKit in my
> > experience, and it certainly doesn't take significantly longer. And
> > of course the former is far superior than the latter.
> 
> I'm late to this thread, I know. But in fact on Windows the situation
> is arguably a bit worse: QtWebEngine can _only_ be compiled using (free
> as in beer) MSVC 2013. In particular, MinGW is explicitly _not_
> supported.
> 
> 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 to be MinGW-only, for various reasons, it can be between
> no-fun-at-all, and downright incompatibility. Remember, the C++-ABI is
> just not compatible between MinGW and MSVC.

I agree that this is a bad situation. Are there any plans from upstream to fix 
this at some point?

> I have no idea how hard it would be to resolve this (it is rumored to
> be hard), but until it is, 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. For use cases such as "display some
> trusted local HTML files", I think QtWebKit is still the tool of choice.

The problem with QtWebKit really is that it probably has many vulnerabilities 
that are fixed in upstream WebKit but where the fixes are not backported. 
It would probably be ok to use it for "trusted local HTML" but I am not sure 
how many cases there are where you can guarantee this. And using QtWebKit half 
of the time and QtWebEngine for the other half does not necessarily solve your 
Windows problem.

Btw, do we already have an official policy regarding QtWebEngine? There are 
already KDE applications using it, but is it ok to hard-depend on it or should 
it be optional for now?

> Regards
> Thomas

Re: Policy regarding QtWebKit and QtScript

[Allan Sandfeld Jensen]

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 this?
> MSVC 2013 hardly supersets the GNU toolchain and the code cannot make use
> of MSVC's "let's try to compile this junk, despite it's not nearly valid
> c++" features, because it generally still needs to compile on other
> systems.
> 
Chromium doesn't support it, and generally we try to stick to the same 
platforms Chromium support. We haven't actually investigated how much work it 
would be to make it work. Likely it would mostly be fixes in Chromium's gyp 
files, but it could be a lot of changes that would then need to maintained. I 
also know in WebKit we had to deal with a lot of unique MinGW compiler bugs 
that needed to be worked around, we could quickly run into the same in 
Chromium.

Best regards
`Allan

Re: Policy regarding QtWebKit and QtScript

[Thomas Friedrichsmeier]

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 to be MinGW-only, for various reasons, it can
> > be between no-fun-at-all, and downright incompatibility. Remember,
> > the C++-ABI is just not compatible between MinGW and MSVC.
> 
> I agree that this is a bad situation. Are there any plans from
> upstream to fix this at some point?

Looks somewhat grim, although, hopefully this is not the last word:
https://bugreports.qt.io/browse/QTBUG-42725
 
> The problem with QtWebKit really is that it probably has many
> vulnerabilities that are fixed in upstream WebKit but where the fixes
> are not backported. It would probably be ok to use it for "trusted
> local HTML" but I am not sure how many cases there are where you can
> guarantee this. And using QtWebKit half of the time and QtWebEngine
> for the other half does not necessarily solve your Windows problem.

True, but it would make it somewhat less severe. The more frameworks /
applications play nice with _both_ compilers, the more likely that I
can combine all required bits for my purpose on at least _one_ compiler.
 
> Btw, do we already have an official policy regarding QtWebEngine?
> There are already KDE applications using it, but is it ok to
> hard-depend on it or should it be optional for now?

Dunno. Of course, as things stand, in the mid term, applications in need
of a _secure_ html viewer will have basically no other choice than
to hard-depend on QtWebEngine. But I would argue for a policy along
the lines of:

  - Do not hard depend on QtWebEngine, unless you really have to.
- Where security is _not_ a concern, you should (optionally) support
  compilation with QtWebKit.
- Where security _is_ a concern, consider whether you can
  (optionally) use an external browser for the purpose at hand.

Regards
Thomas


pgp2AKyLUIaKj.pgp
Description: OpenPGP digital signature

Re: Policy regarding QtWebKit and QtScript

[Thomas Friedrichsmeier]

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 my
> experience, and it certainly doesn't take significantly longer. And
> of course the former is far superior than the latter.

I'm late to this thread, I know. But in fact on Windows the situation
is arguably a bit worse: QtWebEngine can _only_ be compiled using (free
as in beer) MSVC 2013. In particular, MinGW is explicitly _not_
supported.

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 to be MinGW-only, for various reasons, it can be between
no-fun-at-all, and downright incompatibility. Remember, the C++-ABI is
just not compatible between MinGW and MSVC.

I have no idea how hard it would be to resolve this (it is rumored to
be hard), but until it is, 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. For use cases such as "display some
trusted local HTML files", I think QtWebKit is still the tool of choice.

Regards
Thomas


pgpawCAqDAbVA.pgp
Description: OpenPGP digital signature

Re: Policy regarding QtWebKit and QtScript

[Kevin Kofler]

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 
post:

Vadim Zhukov wrote:
> Same applies to OpenBSD. QtWebEngine uses its own, qmake-based, build
> system, so at least 50% of effort of porting Chromium should be
> repeated.

The Chromium part is actually built using gyp. QMake just shells out to gyp 
to build it. You can add gyp flags in the src/core/config/*.pri files 
(you'll probably want a config/openbsd.pri anyway, unless you abuse 
linux.pri).

> Next thing is that chromium already requires some tricks to allow it
> being compiled (or, more technically, linked) on 32-bit platforms. In
> fact, on OpenBSD it currently packages on i386 and amd64; it's going
> to became amd64 soon:
> http://betanews.com/2015/11/30/google-killing-chrome-for-32-bit-linux/
> . QtWebkit is large enough, too, but still fits into 32-bit address
> space. That's not about trashing swap partition; that's about being
> able to link stuff at all.

That article is about the proprietary Chrome. It even explicitly says that 
Chromium will keep supporting 32-bit x86.

What it does require though (on x86) is SSE2. In case anybody is interested, 
I have a patch fixing that (basically a cumulative revert of all the related 
upstream changes) that I still need to test. Here is what I have so far:
https://bugzilla.redhat.com/attachment.cgi?id=1108340=diff
but it might not even compile yet.

> KDE4 runs on OpenBSD/sparc64 (I had successful reports from users).
> Chromium doesn't work there due to (at least) memory alignment bugs.
> QtWebEngine is out of SPARC game, therefore, too. Adoption of
> QtWebEngine will mean no modern KDE for sparc64. And it's a 64-bit
> platform, not limited by 2/3/4GB of address space! I'm not ever
> talking about MIPS world...

You'd also need a V8 port, which means a JIT for that platform (because V8 
has no interpreter fallback). This is a major concern with QtWebEngine, it 
destroys the portability of Qt and KDE to new architectures. We were happy 
when the V8 dependency was dropped from QML 2, and very unhappy when it was 
reintroduced through the backdoor with QtWebEngine.

> And, as it was already mentioned many times, Chromium/QtWebEngine
> bundles a lot of software, often outdated. What happens when a
> security flaw is found in, say, giflib? - The packager adds an
> upstream patch or rolls a new release from upstream. What happens in
> case of bundled copy? - Nothing, because chromium developers don't
> want to break things and thus do not care about updating software
> ASAP. And if they do, those updates are delayed because the
> chromium/Qt packages need to be redone (reviewed, rebuilt, repackaged
> and verified). And that's far less trivial and takes far more time
> than patching and repackaging giflib. End users get unsecure software
> as a result, possible even thinking: "I'm secure now, since I've just
> updated giflib package". Who'll stand up and say: "I want to make
> users of my software feel safe while my software is actually unsafe"?
> - Noone will, right? But it happens.

This is a very valid concern. Qt upstream has done some work on unbundling 
libraries, but:
1. There are libraries where Chromium does not support unbundling.
2. There are a few libraries that Chromium allows to unbundle, but
   QtWebEngine doesn't yet.
3. The unbundling in QtWebEngine does not run replace_gyp_files.py, so the
   unbundling is not complete.
2. and 3. are easy to fix, this patch works for me:
http://copr-dist-git.fedorainfracloud.org/cgit/kkofler/qtwebengine/qt5-qtwebengine.git/tree/qtwebengine-opensource-src-5.6.0-beta-linux-pri.patch?id=849178c1d044af50e13552490c81801565aef547

I'm looking into upstreaming it to Qt, but I'll have to add configure checks 
for the use_system_* flags (point 2.) that I hardcoded to "=1".

But issue 1. is the bigger issue.

That said, your example is actually a bad example because 
Chromium/QtWebEngine does not actually bundle giflib. (It uses its own GIF 
decoder, which is forked from WebKit's, which is forked from Mozilla's.)

Kevin Kofler

Re: Policy regarding QtWebKit and QtScript

[Kevin Kofler]

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/config/*.pri file.

>  - Same applies to most of the bundled stuff. A lot of the FreeBSD patches
>  for Chromium itself are, indeed, unbundlings.

Actually, a lot of the FreeBSD patches are adding BSD #ifdefs (or the gyp 
equivalent), I don't see much unbundling there. I see a fix for unbundling 
libusb1/libusbx (which is not needed for QtWebEngine because QtWebEngine 
does not use libusb*, by the way), maybe I'm missing 1 or 2 things, but 
unbundling doesn't seem to be the main focus. And the reason there are so 
many patches is because they produced a different patch for EVERY SINGLE 
source file they modified! (That, and the fact that they're only named after 
the source files and not after the modifications actually done, also makes 
it really hard to decide at a glance what those patches really do. IMHO, 
this is an example of how NOT to manage downstream patches.)

>  But those need to be re-done for webengine, because who knows how the
>  versions differ.

The Chromium patches should mostly work as is. Some will not be needed 
because QtWebEngine does not build everything from Chromium, but they 
shouldn't hurt either.

>  - The qmake and gyp (horse pucky!) are strongly tied into
>  linux/mac/boot2qt, so finding all the bits and pieces that need adjusting
>  is tricky.

The hardcoded list of operating systems is indeed a hindrance to 
portability. (Basically, "linux" should really be "any working OS, i.e. 
anything other than the broken Window$ and Mac crap".)

>  - Example, I thought I had bunged freebsd-clang into the system properly,
>  but gyp is still trying to discover the assembler version by calling gcc.

Are you already setting the:
GYP_CONFIG += clang=1 host_clang=1 clang_use_chrome_plugins=0 \
  make_clang_dir=/usr
flags that desktop-linux.pri sets when building for a linux-clang target?

>  - Example from qt3d (so external to this discussion), using a broken
>  OffsetOf in a bundled third party library.

Yes, bundled libraries suck and this kind of issues is another reason why.

Kevin Kofler

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

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 different patch for EVERY SINGLE
> source file they modified! (That, and the fact that they're only named after
> the source files and not after the modifications actually done, also makes
> it really hard to decide at a glance what those patches really do. IMHO,
> this is an example of how NOT to manage downstream patches.)

Yeah. I find that a terrible confusing policy in FreeBSD ports too. But that's 
not my department, I'm afraid.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Kevin Kofler]

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 
have the even harder task porting to *BSD. Don't give up, it can be done.

Kevin Kofler

Re: Policy regarding QtWebKit and QtScript

[Allan Sandfeld Jensen]

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, unbundlings. But those need to be
> > > re-done for webengine, because who knows how the versions differ.
> > 
> > We have already done third-party library unbundling in Qt 5.6.
> 
> Allan: are sqlite3 and leveldatabase still embedded?

Yes, but they are patched to provide extra API for Chromium. Those APIs are 
not really upstreamable, so Chromium have to use their own version.

`Allan

Re: Policy regarding QtWebKit and QtScript

[Vadim Zhukov]

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 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 a bit - it
>> > > > doesn't really improve reputation. Distros will virtually *have* to
>> > > > provide
>> > > > downstream webkit solutions to cover 3rd party installs and we'll get
>> > > > "somthing broke" reports on this all over the place.
>> > >
>> > > What we distro packagers are going to do is to recompile QtWebkit for as
>> > > long  ans possible/necessary.
>> >
>> > If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what
>> > the new thing is called) is an absolute terror to get building in FreeBSD.
>> > There are apparently source-compatibility issues and it takes a great big
>> > stonkin' machine to compile it at all.
>>
>> 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?
>
> Please don't focus on *one* single part of what I explicitly indicated was at-
> that-time-hearsay. Since then I've actually tried to compile Qt 5.6 beta.
>
>> Qt WebEngine is far easier to compile than Qt WebKit in my experience, and
>> it certainly doesn't take significantly longer. And of course the former is
>> far superior than the latter.
>
> This bit makes it harder:
>
> ./tools/qmake/mkspecs/features/functions.prf:skipBuild("Qt WebEngine can
> currently only be built for Linux (GCC/clang), Windows (MSVC 2013 or 2015), OS
> X (10.9/XCode 5.1+) or Qt for Device Creation.")
>
> So from the FreeBSD packagers' side, it *is* a big deal, because they not only
> have to get KDE software to work (which has traditionally been very cross-
> platform, and is easy to work with), and Qt to work (which has traditionally
> been very cross-platform, and is generally easy to work with), but also deal
> with 975MB of Chromium. That is, as they say, quite a lump of coal in the
> stocking.

At first, I should note that I don't have anything against idea of
having modern web engine in Qt and/or KDE apps. And I really like Qt
and KDE design in general, especially nowadays. But Chromium, and thus
QtWebEngine is not portable, really. I don't have any win-win solution
here, sorry. That's just a description of what I see from my point of
view of OpenBSD porter.

Same applies to OpenBSD. QtWebEngine uses its own, qmake-based, build
system, so at least 50% of effort of porting Chromium should be
repeated.

Next thing is that chromium already requires some tricks to allow it
being compiled (or, more technically, linked) on 32-bit platforms. In
fact, on OpenBSD it currently packages on i386 and amd64; it's going
to became amd64 soon:
http://betanews.com/2015/11/30/google-killing-chrome-for-32-bit-linux/
. QtWebkit is large enough, too, but still fits into 32-bit address
space. That's not about trashing swap partition; that's about being
able to link stuff at all.

KDE4 runs on OpenBSD/sparc64 (I had successful reports from users).
Chromium doesn't work there due to (at least) memory alignment bugs.
QtWebEngine is out of SPARC game, therefore, too. Adoption of
QtWebEngine will mean no modern KDE for sparc64. And it's a 64-bit
platform, not limited by 2/3/4GB of address space! I'm not ever
talking about MIPS world...

And, as it was already mentioned many times, Chromium/QtWebEngine
bundles a lot of software, often outdated. What happens when a
security flaw is found in, say, giflib? - The packager adds an
upstream patch or rolls a new release from upstream. What happens in
case of bundled copy? - Nothing, because chromium developers don't
want to break things and thus do not care about updating software
ASAP. And if they do, those updates are delayed because the
chromium/Qt packages need to be redone (reviewed, rebuilt, repackaged
and verified). And that's far less trivial and takes far more time
than patching and repackaging giflib. End users get unsecure software
as a result, possible even thinking: "I'm secure now, since I've just
updated giflib package". Who'll stand up and say: "I want to make
users of my software feel safe while my software is actually unsafe"?
- Noone will, right? But it happens.

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 already big enough task for me.

So, again, it was my seeing, both for today and tomorrow. Now I'm back
to porting other KDE5 stuff. Thank you for 

Re: Policy regarding QtWebKit and QtScript

[Lisandro Damián Nicanor Pérez Meyer]

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.
> 
> We have already done third-party library unbundling in Qt 5.6.

Allan: are sqlite3 and leveldatabase still embedded?


-- 
firmaware: soft cuya licencia pagas enviando un autografo
  StucKman en #grulic, irc.freenode.net

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Policy regarding QtWebKit and QtScript

[Lisandro Damián Nicanor Pérez Meyer]

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. 
Sadly my available time and build power has proven to not be enough to 
properly test this fact :(

-- 
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.
  Anonymous

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

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 already big enough task for me.
> 
> So, again, it was my seeing, both for today and tomorrow. Now I'm back
> to porting other KDE5 stuff. Thank you for reading!

Thank you, Vadim. I spent an hour or two on qtwebengine today. I got the 
feeling that the motto is "y0 dawg, i hear you like build systems so i put a 
buildsystyem in your buildsystem so you can buildsystem while you 
buildsystem". It is a frustrating experience.

I'm trying hard to not make this sound like whining, really.

 - Why am I building ninja when it's already packaged externally?
 - Why am I building yasm?
 - 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.
 - The qmake and gyp (horse pucky!) are strongly tied into linux/mac/boot2qt, 
so finding all the bits and pieces that need adjusting is tricky.
 - Example, I thought I had bunged freebsd-clang into the system properly, but 
gyp is still trying to discover the assembler version by calling gcc.
 - Example from qt3d (so external to this discussion), using a broken OffsetOf 
in a bundled third party library.

This sounds like a case where the unbundling OSsen -- OpenBSD, FreeBSD, 
probably some of the Linuxen -- can and should get together to help make more 
of Qt 5.6 a truly cross-platform development environment. (Randa?)

[ade]

Re: Policy regarding QtWebKit and QtScript

[Allan Sandfeld Jensen]

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: handling a few hundreds of KDE ports +
> > ports of Qt itself is already big enough task for me.
> > 
> > So, again, it was my seeing, both for today and tomorrow. Now I'm back
> > to porting other KDE5 stuff. Thank you for reading!
> 
> Thank you, Vadim. I spent an hour or two on qtwebengine today. I got the
> feeling that the motto is "y0 dawg, i hear you like build systems so i put
> a buildsystyem in your buildsystem so you can buildsystem while you
> buildsystem". It is a frustrating experience.
> 
> I'm trying hard to not make this sound like whining, really.
> 
>  - Why am I building ninja when it's already packaged externally?
a) That is a how Chromium does it and b) it is really convenient on platforms 
that doesn't have package managers that can easily download a prebuild version 
of ninja (most platforms). Adding that Chromium tend to depend on specific 
versions, it not affecting the shipped result, and is relatively fast to 
build, it is probably not worth the trouble.

>  - Why am I building yasm?
>  - 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.
We have already done third-party library unbundling in Qt 5.6.

>  - The qmake and gyp (horse pucky!) are strongly tied into
> linux/mac/boot2qt, so finding all the bits and pieces that need adjusting
> is tricky.
The linux parts probably just need to be split into general posix/unix parts 
and linux parts, but yes it has to happen several places.

Best regards
`Allan

Re: Policy regarding QtWebKit and QtScript

[Niels Ole Salscheider]

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 time to compile?
> 
> How demanding is it exactly?
> Considering Gentoo users, it could be quite a problem if it takes 32GB RAM
> or something.

It's not THAT bad. It works fine for me on Exherbo (also source based) on my 
notebook 
(AMD Llano APU, 8GB RAM).

> Cheers,
> Thomas

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

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

There is a chromium port. I took a look at it, there's 380 patches that it 
applies. I don't know how much of that is related to the application or how 
much applies to the underlying engine. I have no idea if the application works 
(well). I'll kick off a build just before I leave for Xmas dinner.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Thiago Macieira]

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 haven't tried because I wasn't sure if FreeBSD was even
> > support by Chromium.
> 
> There is a chromium port. I took a look at it, there's 380 patches that it
> applies. I don't know how much of that is related to the application or how
> much applies to the underlying engine. I have no idea if the application
> works (well). I'll kick off a build just before I leave for Xmas dinner.

Some of those changes may be only to unbundle some libraries and cause 
chromium to link to system-provided ones.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Policy regarding QtWebKit and QtScript

[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 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 a bit - it
> > > > doesn't really improve reputation. Distros will virtually *have* to
> > > > provide
> > > > downstream webkit solutions to cover 3rd party installs and we'll get
> > > > "somthing broke" reports on this all over the place.
> > > 
> > > What we distro packagers are going to do is to recompile QtWebkit for as
> > > long  ans possible/necessary.
> > 
> > If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what
> > the new thing is called) is an absolute terror to get building in FreeBSD.
> > There are apparently source-compatibility issues and it takes a great big
> > stonkin' machine to compile it at all.
> 
> 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?

Please don't focus on *one* single part of what I explicitly indicated was at-
that-time-hearsay. Since then I've actually tried to compile Qt 5.6 beta.
 
> Qt WebEngine is far easier to compile than Qt WebKit in my experience, and
> it certainly doesn't take significantly longer. And of course the former is
> far superior than the latter.

This bit makes it harder:

./tools/qmake/mkspecs/features/functions.prf:skipBuild("Qt WebEngine can 
currently only be built for Linux (GCC/clang), Windows (MSVC 2013 or 2015), OS 
X (10.9/XCode 5.1+) or Qt for Device Creation.")

So from the FreeBSD packagers' side, it *is* a big deal, because they not only 
have to get KDE software to work (which has traditionally been very cross-
platform, and is easy to work with), and Qt to work (which has traditionally 
been very cross-platform, and is generally easy to work with), but also deal 
with 975MB of Chromium. That is, as they say, quite a lump of coal in the 
stocking.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Nicolás Alvarez]

> 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 to compile?
> 
> How demanding is it exactly?
> Considering Gentoo users, it could be quite a problem if it takes 32GB RAM or 
> something.
> 
> Cheers,
> Thomas

The linking step needs 4GB of RAM, which means it takes 40 minutes of 
swap-thrashing just to link if you're on a 4GB RAM system that can't dedicate 
100% to ld alone (the OS and disk cache need memory too!). I ended up renting 
an 8GB VPS for a few hours to compile a personally-patched Chromium.

But 4GB is not too much in this day and age. My computer is outdated.

Re: Policy regarding QtWebKit and QtScript

[Milian Wolff]

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 5.6 and still have
> > > (not
> > > recompiled) client code that is now gonna crash scares me a bit - it
> > > doesn't really improve reputation. Distros will virtually *have* to
> > > provide
> > > downstream webkit solutions to cover 3rd party installs and we'll get
> > > "somthing broke" reports on this all over the place.
> > 
> > What we distro packagers are going to do is to recompile QtWebkit for as
> > long  ans possible/necessary.
> 
> If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what
> the new thing is called) is an absolute terror to get building in FreeBSD.
> There are apparently source-compatibility issues and it takes a great big
> stonkin' machine to compile it at all.

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 my experience, and it 
certainly doesn't take significantly longer. And of course the former is far 
superior than the latter.

And talking about compile times: Ever compiled LLVM + Clang? It takes ages, 
but it's simply worth it...

-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.

Re: Policy regarding QtWebKit and QtScript

[Thomas Lübking]

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, it could be quite a problem if it takes 32GB RAM or 
something.

Cheers,
Thomas

Re: Policy regarding QtWebKit and QtScript

[Allan Sandfeld Jensen]

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 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 a bit -
> > > > > it doesn't really improve reputation. Distros will virtually
> > > > > *have* to provide
> > > > > downstream webkit solutions to cover 3rd party installs and we'll
> > > > > get "somthing broke" reports on this all over the place.
> > > > 
> > > > What we distro packagers are going to do is to recompile QtWebkit for
> > > > as long  ans possible/necessary.
> > > 
> > > If I recall correctly, the FreeBSD guys say that QtWebEngine (is that
> > > what the new thing is called) is an absolute terror to get building in
> > > FreeBSD. There are apparently source-compatibility issues and it takes
> > > a great big stonkin' machine to compile it at all.
> > 
> > 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?
> 
> Please don't focus on *one* single part of what I explicitly indicated was
> at- that-time-hearsay. Since then I've actually tried to compile Qt 5.6
> beta.
> 
> > Qt WebEngine is far easier to compile than Qt WebKit in my experience,
> > and it certainly doesn't take significantly longer. And of course the
> > former is far superior than the latter.
> 
> This bit makes it harder:
> 
> ./tools/qmake/mkspecs/features/functions.prf:skipBuild("Qt WebEngine
> can currently only be built for Linux (GCC/clang), Windows (MSVC 2013 or
> 2015), OS X (10.9/XCode 5.1+) or Qt for Device Creation.")
> 
> So from the FreeBSD packagers' side, it *is* a big deal, because they not
> only have to get KDE software to work (which has traditionally been very
> cross- platform, and is easy to work with), and Qt to work (which has
> traditionally been very cross-platform, and is generally easy to work
> with), but also deal with 975MB of Chromium. That is, as they say, quite a
> lump of coal in the stocking.
> 
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 Chromium.

`Allan

Re: Policy regarding QtWebKit and QtScript

[Adriaan de Groot]

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 a bit - it
> > doesn't really improve reputation. Distros will virtually *have* to
> > provide
> > downstream webkit solutions to cover 3rd party installs and we'll get
> > "somthing broke" reports on this all over the place.
> 
> What we distro packagers are going to do is to recompile QtWebkit for as
> long  ans possible/necessary.

If I recall correctly, the FreeBSD guys say that QtWebEngine (is that what the 
new thing is called) is an absolute terror to get building in FreeBSD. There 
are apparently source-compatibility issues and it takes a great big stonkin' 
machine to compile it at all.

But .. I haven't tried it myself. I probably should so I can replace the 
'apparently's above with 'defiitely'.

[ade]

Re: Policy regarding QtWebKit and QtScript

[Thiago Macieira]

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 releases and should get fixed in updated qtwebkit source packages.

qtquick1 is a whole other story. Its life ends now.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Re: Policy regarding QtWebKit and QtScript

[Thiago Macieira]

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 and that is 
simply too much to ask for, for a module that needs security updates we are 
hardly getting from upstream.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
 

Re: Policy regarding QtWebKit and QtScript

[Christoph Cullmann]

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 is useless for it

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

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234


qjs.diff.gz
Description: GNU Zip compressed data

Re: Policy regarding QtWebKit and QtScript

[Lisandro Damián Nicanor Pérez Meyer]

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 in a *minor* Qt release. Should
> generally not happen. Period.
> 
> It should still be released and everytime you try to build against it
> (include it) and didn't "#define
> I_KNOW_WEBKIT_IS_BITROT_AND_AM_PORTING_TO_QT_WEBENGINE_ALREADY" you get a
> compiler error.
> 
> 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 a bit - it
> doesn't really improve reputation. Distros will virtually *have* to provide
> downstream webkit solutions to cover 3rd party installs and we'll get
> "somthing broke" reports on this all over the place.

What we distro packagers are going to do is to recompile QtWebkit for as long 
ans possible/necessary.

IIRC Thiago said that it didn't use private stuff, so recompiling should be 
more than enough (in case it is really needed).

-- 
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
  Unknown - http://www.linfo.org/q_unix.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Policy regarding QtWebKit and QtScript

[Ivan Čukić]

> 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, http://cukic.co/
gpg key id: 850B6F76

Re: Policy regarding QtWebKit and QtScript

[Allan Sandfeld Jensen]

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
> should be some porting tools?)
> 
> About QtWebkit - what exactly does "disappear" mean in this context?
> Will it be impossible to link QtWebKit 5.5 to Qt 5.6 ?
> For if it would, that would be one giant ABI break and the answer would be
> to fork Qt... :-P
> 
No, probably not, it uses private Qt modules, so it cases the version mismatch 
assert. But currently it looks like there will be a source-only qtwebkit 5.6, 
but not as part of the official release.

Best regards
`Allan

Re: Policy regarding QtWebKit and QtScript

[Thomas Lübking]

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 should still be released and everytime you try to build against it (include it) and 
didn't "#define I_KNOW_WEBKIT_IS_BITROT_AND_AM_PORTING_TO_QT_WEBENGINE_ALREADY" 
you get a compiler error.

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 a bit - it doesn't 
really improve reputation.
Distros will virtually *have* to provide downstream webkit solutions to cover 3rd party 
installs and we'll get "somthing broke" reports on this all over the place.

Sigh.
Thomas

Re: Policy regarding QtWebKit and QtScript

[Lisandro Damián Nicanor Pérez Meyer]

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?
> > 
> > Isn't the designated successor for QtScript QJSEngine (I even assumed
> > there
> > should be some porting tools?)
> > 
> > About QtWebkit - what exactly does "disappear" mean in this context?
> > Will it be impossible to link QtWebKit 5.5 to Qt 5.6 ?
> > For if it would, that would be one giant ABI break and the answer would be
> > to fork Qt... :-P
> 
> No, probably not, it uses private Qt modules, so it cases the version
> mismatch assert. But currently it looks like there will be a source-only
> qtwebkit 5.6, but not as part of the official release.

And should be compilable for some time, indeed.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Policy regarding QtWebKit and QtScript

[Luigi Toscano]

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 is much less of a problem.
> 
> As far as I understand they are just going to be stopped from releasing, 
> this
> doesn't mean we can't keep using them, no?
> 
>  
> IMHO they will break sooner than later. They are going unsupported and IIRC
> also getting out of CI. It's just a matter of time.
> 
> The 6-12-18 months they will still be buildable and usable are the time to
> look for an alternative, or to enhance QJSEngine/QWebEngine, so that they are
> good for KDE. According to qt-interest, some commercial and LGPL users seem to
> face the same problems, therefore The Qt Company is probably open to 
> enhancements.

Shouldn't it be the other way around? Workable solution first and drop the old
one later?

But yeah, maybe too late, sadly.

Ciao
-- 
Luigi

Re: Policy regarding QtWebKit and QtScript

[Thomas Lübking]

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 does "disappear" mean in this context?
Will it be impossible to link QtWebKit 5.5 to Qt 5.6 ?
For if it would, that would be one giant ABI break and the answer would be to 
fork Qt... :-P

Cheers,
Thomas

Re: Policy regarding QtWebKit and QtScript

[Ivan Čukić]

> 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 to run javascript with kjs
and similar, and that is mostly what we needed from QtScript.


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

> Currently, the only backend is a JavaScript backend powered
> by the QtScript library (which is part of Qt).

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


Cheers,
Ivan

Re: Policy regarding QtWebKit and QtScript

[Albert Astals Cid]

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 be stopped from releasing, this 
doesn't mean we can't keep using them, no?

Cheers,
  Albert

> 
> I'd say we need a plan to figure out what to do with these
> dependencies. I don't think assuming that they will stay around is
> very wise, so I'd suggest to come up collectively or specifically on
> each project how to deal with those.
> 
> I'd say it's especially pressing on KDE Frameworks where Qt5::Script
> is still quite widely used (kio, ki18n, ktexteditor,
> plasma-framework).
> 
> Aleix

Re: Policy regarding QtWebKit and QtScript

[Pau Garcia i Quiles]

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 stopped from releasing,
> this
> doesn't mean we can't keep using them, no?
>
>
IMHO they will break sooner than later. They are going unsupported and IIRC
also getting out of CI. It's just a matter of time.

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

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Policy regarding QtWebKit and QtScript

[Pau Garcia i Quiles]

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 common features that would be
broken, the deprecation was delayed by 6 months (maybe 12, I cannot really
remember and time flies).

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

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Policy regarding QtWebKit and QtScript

[Alexander Potashev]

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

[Ivan Čukić]

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, but is
> included in Qt 5.6 release.**

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

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

Cheerio,
Ivan

--
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key id: 850B6F76