Distros and QtWebEngine

[Lisandro Damián Nicanor Pérez Meyer]

Sorry Milian, i've sent it to your personal address by mistake.

Resending to the list.

On Monday 20 April 2015 23:02:35 you wrote:
[snip] 
> Have you notified the Qt WebEngine developers about this? I have not seen
> any email in that regard to the official upstream mailing list at
> qtwebengine at qt- project.org .

Yes we have, but on the main devel mailing list, development at qt-project.org
It has been troughly discussed, the thread is actually very long.

> Previously, many of the 3rd party stuff was just hardcoded and shipped
> internally because it was easier to get stuff done.

At least in Qt (not mentioning the web engines) they have been added to easier 
the development in platforms that do not have a coherent way to handle system 
libs (like Windows). They are also quite open to add code to detect and use 
the system lib when required, and I'm really thankful for that :)

Sadly that's not the case with the webengine, read: the part the Qt guys don't 
code.

> Now with things settling
> a bit, afaik one could start working on the build system to use a system-
> provided version of "the 3rd party stuff". Some stuff will probably always
> be shipped internally, but at least this could help things a bit. In all
> cases, its sadly sometimes simply not possible to make different FOSS code
> work together without custom patches for a certain project. Yes, this is
> against the ideal utopia we all dream of, but with limited man power there
> will always be problems like this.

Actually when it comes to the web engine it's not true. When I suggested to 
use an external ffmpeg and libv8 (javascript engine) the answer was directly 
no, simply because they are too entangled to be possible. And ffmpeg tends to 
be quite a source of CVEs...

> Regarding debug symbols, it certainly works with ld as others have
> mentioned. And it is definitely easier to build than QtWebKit.
> 
> Anyhow, I won't judge distros when they won't package software that is
> against their principals. But I hope you guys also understand that for some
> developers a good solution for some people is better than a half baked
> broken solution for some more people. I'm not a KDE PIM maintainer, but
> with my KDevelop hat on (that uses a web view to display documentation
> pages, currently QtWebKit), I could understand a projects decision to just
> make a certain feature optional. Certainly less maintenance effort than
> supporting different implementations.

Right. And now I know at least you know the implicants of making QtWebEngine a 
hard (or not) dependency.

-- 
Hiroshima '45,
Chernobyl '86,
Windows   '95.
 Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario Gallo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150420/9f8b918c/attachment.sig>