Discussion:
Distros and QtWebEngine
(too old to reply)
Lisandro Damián Nicanor Pérez Meyer
2015-04-20 16:28:59 UTC
Permalink
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to
the problem that QtWebEngine poses for us distros (in this case, at least
Debian and Fedora).

I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a
hard (very hard) piece of software to package.

It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium is
not available for them.

Moreover we can't build debugging symbols on most archs due to the enormous
amount of RAM+swap it involves in the linking process (more than 8GB last time
I checked). This is at least the same as QtWebKit, but seems to be getting
worse.

Yes, we do understand that QtWebEngine is technically superior to any other
thing out there but making that code an acceptable package is another thing.

So basically what I'm trying to say is: don't expect us down streamers to
easily package QtWebEngine soon, if we ever get to it.

I'm really sorry if this comes as "bad news", but the reality is currently
this :(
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Albert Astals Cid
2015-04-20 18:17:13 UTC
Permalink
El Dilluns, 20 d'abril de 2015, a les 13:28:59, Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to
the problem that QtWebEngine poses for us distros (in this case, at least
Debian and Fedora).
I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a
hard (very hard) piece of software to package.
It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium
is not available for them.
IMHO the duty of a distro is providing software to their users to use, if the
rules of the distro make providing software hard/impossible they need to be
updated or these distros need to understand they will lose users to more
flexible distros.

Cheers,
Albert
Lisandro Damián Nicanor Pérez Meyer
2015-04-20 18:52:12 UTC
Permalink
On Monday 20 April 2015 20:17:13 Albert Astals Cid wrote:
[snip]
Post by Albert Astals Cid
IMHO the duty of a distro is providing software to their users to use, if
the rules of the distro make providing software hard/impossible they need
to be updated or these distros need to understand they will lose users to
more flexible distros.
Let me begin that I acknowledge you have a fair point there. But using the
same reasoning users can also switch to using other apps.

I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in
the same position as us) is also a large userbase for KDE to loose.

But *it's not really* about which distro or app is going to loose more user
base, it's about keeping the current one. I don't want Debian nor KDE to loose
users, in the same way I do not want to ship something that's unmaintainable.

So if any of us with with an upstream hat is going to code something, please
consider that having a hard dependency on QtWebEngine might mean his/her code
might not get available to everyone as it used to be, that's all.
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Albert Astals Cid
2015-04-20 19:56:05 UTC
Permalink
El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
[snip]
Post by Albert Astals Cid
IMHO the duty of a distro is providing software to their users to use, if
the rules of the distro make providing software hard/impossible they need
to be updated or these distros need to understand they will lose users to
more flexible distros.
Let me begin that I acknowledge you have a fair point there. But using the
same reasoning users can also switch to using other apps.
Users are free to do what they want, that's obvious, but if the user switches
is not because we used QtWebEngine in an app, sane users could not care the
less which technologies we use.

If the user switches is because for some reason the distro decided that their
rules are more important than the user and forced him either to switch distro
or to switch apps by not packaging something.
Post by Lisandro Damián Nicanor Pérez Meyer
I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in
the same position as us) is also a large userbase for KDE to loose.
But *it's not really* about which distro or app is going to loose more user
base, it's about keeping the current one. I don't want Debian nor KDE to
loose users, in the same way I do not want to ship something that's
unmaintainable.
Maybe you guys should just trust the Qt project to maintain QtWebEngine and
just run with what they provide instead of needing 3 people to "maintain" it
yourselves?

What's wrong with that besides it going against your rules?

That you need to provide longer maintaince times than what Qt upstream
provides?

Just state that there's no such long maintaince time for that package or just
install the newer version of Qt. And yes again that probably goes against your
rules, but it's your rules, so you can just improve them for everyone's
benefit :)

Cheers,
Albert
Post by Lisandro Damián Nicanor Pérez Meyer
So if any of us with with an upstream hat is going to code something, please
consider that having a hard dependency on QtWebEngine might mean his/her
code might not get available to everyone as it used to be, that's all.
Luigi Toscano
2015-04-20 20:16:34 UTC
Permalink
Post by Albert Astals Cid
El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
I could also say that Fedora+Debian+Debian derivatives (Ubuntu is mostly in
the same position as us) is also a large userbase for KDE to loose.
But *it's not really* about which distro or app is going to loose more user
base, it's about keeping the current one. I don't want Debian nor KDE to
loose users, in the same way I do not want to ship something that's
unmaintainable.
Maybe you guys should just trust the Qt project to maintain QtWebEngine and
just run with what they provide instead of needing 3 people to "maintain" it
yourselves?
Qt project can maintain their bits, sure. Are they looking "inside" the big
block, or do they import the core engine as it is? If the latter, well, it's
not that simple as trusting them.
Post by Albert Astals Cid
What's wrong with that besides it going against your rules?
The rules are there not because someone wants to have unhappy users; think
about the rule about untangling tons of embedded libraries and patching issues.
Post by Albert Astals Cid
That you need to provide longer maintaince times than what Qt upstream
provides?
Just state that there's no such long maintaince time for that package or just
install the newer version of Qt. And yes again that probably goes against your
rules, but it's your rules, so you can just improve them for everyone's
benefit :)
Even Firefox ended up providing an yearly stable release for make it easier,
and it's not an hard dependency (and they don't even provide a stable API).


That said, let's talk for a moment on real use cases: how many applications
can need an *hard* dependency on the beast, apart from mail apps?

Ciao
--
Luigi
Jeremy Whiting
2015-04-20 20:31:24 UTC
Permalink
Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word. It was disabled because QtWebKit at the time was crashing.
I'd like to use something light and secure, but am not sure what options we
have going forward tbh.
Post by Lisandro Damián Nicanor Pérez Meyer
El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor
Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
I could also say that Fedora+Debian+Debian derivatives (Ubuntu is
mostly in
Post by Lisandro Damián Nicanor Pérez Meyer
the same position as us) is also a large userbase for KDE to loose.
But *it's not really* about which distro or app is going to loose more
user
Post by Lisandro Damián Nicanor Pérez Meyer
base, it's about keeping the current one. I don't want Debian nor KDE to
loose users, in the same way I do not want to ship something that's
unmaintainable.
Maybe you guys should just trust the Qt project to maintain QtWebEngine
and
just run with what they provide instead of needing 3 people to
"maintain" it
yourselves?
Qt project can maintain their bits, sure. Are they looking "inside" the big
block, or do they import the core engine as it is? If the latter, well, it's
not that simple as trusting them.
What's wrong with that besides it going against your rules?
The rules are there not because someone wants to have unhappy users; think
about the rule about untangling tons of embedded libraries and patching issues.
That you need to provide longer maintaince times than what Qt upstream
provides?
Just state that there's no such long maintaince time for that package or
just
install the newer version of Qt. And yes again that probably goes
against your
rules, but it's your rules, so you can just improve them for everyone's
benefit :)
Even Firefox ended up providing an yearly stable release for make it easier,
and it's not an hard dependency (and they don't even provide a stable API).
That said, let's talk for a moment on real use cases: how many applications
can need an *hard* dependency on the beast, apart from mail apps?
Ciao
--
Luigi
Thomas Lübking
2015-04-20 20:54:26 UTC
Permalink
Post by Jeremy Whiting
Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word.
Ouch, sounds like giant overhead =)
Shouldn't the basic html subset support in QTextView provide anything for this? (in doubt: fetch the xml and htmlify that locally?)

Cheers,
Thomas
Jeremy Whiting
2015-04-20 21:00:44 UTC
Permalink
Yeah, that's probably a better idea. is there a QML ui for QTextview? or
maybe some other QML component that renders html.
Post by Thomas Lübking
Post by Jeremy Whiting
Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word.
Ouch, sounds like giant overhead =)
Shouldn't the basic html subset support in QTextView provide anything for
this? (in doubt: fetch the xml and htmlify that locally?)
Cheers,
Thomas
Thomas Lübking
2015-04-20 21:26:57 UTC
Permalink
Post by Jeremy Whiting
Yeah, that's probably a better idea. is there a QML ui for QTextview? or
maybe some other QML component that renders html.
The Text item defaults textFormat to Text.AutoText - you can enforce
Text.RichText or rely on the detection (if it starts w/ <html>)

Cheers,
Thomas
Kai Uwe Broulik
2015-04-20 21:30:51 UTC
Permalink
‎Note that QtQuick Text never uses RichText unless told, AutoText only enables StyledText when it finds something that looks like a tag before the first line break. 

  Originalnachricht  
Von: Thomas Lübking
Gesendet: Montag, 20. April 2015 23:27
An: Jeremy Whiting
Cc: kdelibs
Betreff: Re: Distros and QtWebEngine
Post by Jeremy Whiting
Yeah, that's probably a better idea. is there a QML ui for QTextview? or
maybe some other QML component that renders html.

The Text item defaults textFormat to Text.AutoText - you can enforce
Text.RichText or rely on the detection (if it starts w/ <html>)

Cheers,
Thomas
Alexander Neundorf
2015-04-20 21:11:49 UTC
Permalink
Post by Thomas Lübking
Post by Jeremy Whiting
Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word.
Ouch, sounds like giant overhead =)
Shouldn't the basic html subset support in QTextView provide anything for
this?
probably not.
You very quickly hit the limits of that.
Using a QWebView doesn't "feel" like giant overhead, displaying a few kB of
html is instant, and you have all HTML features ate your hand.

Alex
Thomas Lübking
2015-04-20 21:30:33 UTC
Permalink
Post by Alexander Neundorf
Post by Thomas Lübking
Post by Jeremy Whiting
Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word.
Ouch, sounds like giant overhead =)
Shouldn't the basic html subset support in QTextView provide anything for
this?
probably not.
You very quickly hit the limits of that.
Yeah, but they want to show a word definition... (I assume?) - there's not much limit pushing in that.
Post by Alexander Neundorf
Using a QWebView doesn't "feel" like giant overhead
Depends on whether
- kanagramm is the only user
- it crashes

Maybe I meant "overengineered"

Cheers,
Thomas
Thomas Lübking
2015-04-20 20:52:31 UTC
Permalink
Post by Luigi Toscano
That said, let's talk for a moment on real use cases: how many applications
can need an *hard* dependency on the beast, apart from mail apps?
Everybody. Nobody. Depends.

The API doesn't look quite exchangeable w/ QWebKit, so one would require a (ONE) compile and/or runtime shim, what raises the questions
a) is that worth it, given (assuming) that QWebKit will at some point become unmaintained (and the insecure)
b) wtf is gonna happen when, let's say, QWebKit is gonna be dropped in Qt6?
I know nothing about the trouble w/ QWebEngine¹, but what is insinuated here is that it's completely unusable, unmaintainable, undistributable - ie. Qt then simply won't have any full blown web engine, resp. has one that nobody uses?
That issue would seem -a tiny bit- faaaar beyond kdepim or anything KDE related, to me those claims read: "Qt now has no longer a web kit/engine".

Cheers,
Thomas

[1] Google more Evil than Apple? WebKit blob trustworthy, but Blink blob isn't? Arch just rolled that on my disk, am I now tracked or what?!?
Kevin Kofler
2015-04-21 13:44:35 UTC
Permalink
Post by Thomas Lübking
I know nothing about the trouble w/ QWebEngine¹, but what is insinuated
here is that it's completely unusable, unmaintainable, undistributable
- ie. Qt then simply won't have any full blown web engine, resp. has
one that nobody uses? That issue would seem -a tiny bit- faaaar beyond
kdepim or anything KDE related, to me those claims read: "Qt now has no
longer a web kit/engine".
That's exactly the problem. I have objected to the QtWebKit deprecation on
those exact grounds on the upstream Qt mailing list, but my complaints have
fallen on deaf ears.
Post by Thomas Lübking
[1] Google more Evil than Apple? WebKit blob trustworthy, but Blink blob
[isn't? Arch just rolled that on my disk, am I now tracked or what?!?
The main problem is not about the trustworthiness of Chromium itself, but
about its bundling of many system libraries. Packages in Fedora and Debian
MUST build against the system version of libraries, for many practical
reasons:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

That said, Google is a web-centric company and as such more likely to put
evil stuff into their browser than Apple. In fact, Chromium and Chrome
already have the reputation of hiding spyware (mis)features in their code.

Kevin Kofler
Thiago Macieira
2015-04-21 16:55:04 UTC
Permalink
Post by Kevin Kofler
Post by Thomas Lübking
I know nothing about the trouble w/ QWebEngine¹, but what is insinuated
here is that it's completely unusable, unmaintainable, undistributable
- ie. Qt then simply won't have any full blown web engine, resp. has
one that nobody uses? That issue would seem -a tiny bit- faaaar beyond
kdepim or anything KDE related, to me those claims read: "Qt now has no
longer a web kit/engine".
That's exactly the problem. I have objected to the QtWebKit deprecation on
those exact grounds on the upstream Qt mailing list, but my complaints have
fallen on deaf ears.
I think that's not a fair characterisation that they fell on deaf ears. They
were heard, but it's simply a matter of fact that WebKit is no longer a
possible target, since Apple removed the necessary bits out of WebKit and
they're a much harder group to work with than Google.

So it's simply not an option to continue to develop WebKit.

If someone has 100 full-time developers to spare, I'm sure un-deprecation
could happen. (I'm not exaggerating)
Post by Kevin Kofler
That said, Google is a web-centric company and as such more likely to put
evil stuff into their browser than Apple. In fact, Chromium and Chrome
already have the reputation of hiding spyware (mis)features in their code.
I'm not sure about spyware, but they do have a history of inserting things of
theirs, like the HTTP-over-QUIC they recently talked about.
--
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
Sune Vuorela
2015-04-20 21:02:34 UTC
Permalink
Just state that there's no such long maintaince time for that package o=
r just=20
install the newer version of Qt. And yes again that probably goes again=
st your=20
rules, but it's your rules, so you can just improve them for everyone's=
=20
benefit :)
Let's just try to follow that thru.

A new QtWebEngine pulls in a new Qt. The newer Qt breaks somehow Plasma,
because relying on internals. Then a newer Plasma is pulled in. THat
requires a newer KDE Frameworks, and a newer Wayland and a newer Mesa.
Those two components requires a newer kernel. The newer KDE frameworks
also has a couple of extra requirements. Some of those extra
requirements happens to break parts of the Gnome stack. So a update of
that is needed too. That requires a newer systemd, that discovers issues
with apache. The newest apache has a changed plugin api that requires
changes to all the apache extensions. Including php, ruby and python.

You can likely continue the story yourself from here.

Unfortunately, I haven't really used my imagination here.

/Sune
Thomas Lübking
2015-04-20 21:41:07 UTC
Permalink
Post by Sune Vuorela
Let's just try to follow that thru.
A new QuigleyImageView pulls in a new Qt. The newer Qt breaks somehow Plasma,
because relying on internals. Then a newer Plasma is pulled in. THat
...
You can apply that on really *anything* - the obvious (claimed) failure is "Qt breaks somehow Plasma" because either
a) a client relied on undocumented behavior (client bug) or
b) a foundation broke documented API/ABI/Behavior (foundation bug)

Also your list implies that one never can update KDE, because that breaks GNOME, requires a kernel update and whatnot.
Post by Sune Vuorela
Unfortunately, I haven't really used my imagination here.
That implies the Linux SW stack is crap. Point taken.

Cheers,
Thomas
Matthias Klumpp
2015-04-20 22:12:19 UTC
Permalink
Post by Thomas Lübking
Post by Sune Vuorela
Let's just try to follow that thru.
A new QuigleyImageView pulls in a new Qt. The newer Qt breaks somehow Plasma,
because relying on internals. Then a newer Plasma is pulled in. THat ...
You can apply that on really *anything* - the obvious (claimed) failure is
"Qt breaks somehow Plasma" because either
a) a client relied on undocumented behavior (client bug) or
b) a foundation broke documented API/ABI/Behavior (foundation bug)
Also your list implies that one never can update KDE, because that breaks
GNOME, requires a kernel update and whatnot.
(Taking my Debian developer hat)

Yes, stuff like that happens and is absolutely common - that's why we
have a development cycle, where we tune the distribution to have all
parts working well together. If we make a huge update on one part, we
might end up breaking more things than we solve issues.
Post by Thomas Lübking
Post by Sune Vuorela
Unfortunately, I haven't really used my imagination here.
That implies the Linux SW stack is crap. Point taken.
Well, it's not crap, but... ;-) Different upstreams care for different
things: Some care very much for backward compatibility and never break
API or ABI. Others, however, break API/ABI with every single release,
remove features and add new ones or even decide to rewrite the whole
application. They might also drop support for lower versions of
dependency X at any time.
I don't say this behaviour is bad, but it makes it impossible to plan
for changes, and to be 100% certain that a change does not break other
unrelated software.
When we release a new version of Debian, users expect the current
feature set to remain stable, so they can tune their workflow to it
and be sure it does not randomly break because a software decided to
e.g. remove command-line flag which became unsupported upstream. The
same way, the quick webbrowser updates are a huge issue in the
enterprise.

In order to keep the whole thing we call a "distribution" sane, we
have a set of rules, like "do not duplicate code in the archive". This
ensures that we do not need to patch the same thing over and over
again, in case there is a security hole in the respective code block.

So, in summary: The free software stack is a mess, and distributors
align it to produce a working compilation of software. This is simply
because there is no central authority coordinating the development of
Mesa, Plasma, GNOME, GCC, systemd, etc., so incompatibilities can
arise at any time.

Cheers,
Matthias
Sune Vuorela
2015-04-21 17:12:44 UTC
Permalink
Post by Thomas Lübking
You can apply that on really *anything* - the obvious (claimed) failure is "Qt breaks somehow Plasma" because either
a) a client relied on undocumented behavior (client bug) or
b) a foundation broke documented API/ABI/Behavior (foundation bug)
a) is happening quite a lot. Just look for usages of Qt private headers
across our modules.
Post by Thomas Lübking
Also your list implies that one never can update KDE, because that breaks GNOME, requires a kernel update and whatnot.
No. One can update things, but it is not "just" update Qt.
Post by Thomas Lübking
Post by Sune Vuorela
Unfortunately, I haven't really used my imagination here.
That implies the Linux SW stack is crap. Point taken.
Or .. fast moving.

/Sune
Sune Vuorela
2015-04-20 19:14:51 UTC
Permalink
IMHO the duty of a distro is providing software to their users to use, =
if the=20
rules of the distro make providing software hard/impossible they need t=
o be=20
updated or these distros need to understand they will lose users to mor=
e=20
flexible distros.
Unless distros and KDE work together somehow, it is going to be a
lose/lose situation for both KDE and and for the distros in question.
And maybe even for the free software desktop.

The exact problem here is that packaging chromium in Debian is something
that needs at least 2 skilled dedicated people to. Packaging QtWebEngine
is like packaging chromium (because it is chromium) + a little bit more.

The rumors is that (K)Ubuntu is likely following Debian.

To the best of my knowledge, chromium aren't shipped at all in fedora
because maintenance nightmare.
And Red Hat is following Fedora.

That's likely half of the actual linux desktop landscape.

We (as KDE) can either insist saying "if you don't ship this technology
we won't deal with you" or we can try to work together with our
downstreams to find a way to somehow make everyone somehow happy.

We (as KDE) need to understand that if we don't have our software in
distributions, it is just as likely that people will switch
applications, as it is that they will switch distributions.

So, all in all, if everyone takes a hard stance, everyone will lose.

Let's find a way so we all can win.

/Sune
Jan Kundrát
2015-04-20 19:35:30 UTC
Permalink
Post by Sune Vuorela
And Red Hat is following Fedora.
RHEL might not be a good example here because they are a rather a strange
beast. RHEL has actually never shipped QtWebKit (!) and they also aren't
shipping Qt5 so far.

Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Luigi Toscano
2015-04-20 19:53:36 UTC
Permalink
Post by Jan Kundrát
Post by Sune Vuorela
And Red Hat is following Fedora.
RHEL might not be a good example here because they are a rather a strange
beast. RHEL has actually never shipped QtWebKit (!) and they also aren't
shipping Qt5 so far.
Just my guess, as I'm not involved in the operating system, but Qt5 was not
stable enough (and no applications) when RHEL7 was frozen.

As for QtWebKit, problem of maintainability (count the CVE).

Ciao
--
Luigi
Franz Fellner
2015-04-20 19:12:44 UTC
Permalink
Post by Albert Astals Cid
El Dilluns, 20 d'abril de 2015, a les 13:28:59, Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to
the problem that QtWebEngine poses for us distros (in this case, at least
Debian and Fedora).
I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a
hard (very hard) piece of software to package.
It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium
is not available for them.
IMHO the duty of a distro is providing software to their users to use, if the
rules of the distro make providing software hard/impossible they need to be
updated or these distros need to understand they will lose users to more
flexible distros.
Or they will switch PIM applications. Or even the DE. Don't think users are married
with your application...
Is it really necessary to use a multiprocess web framework just to view HTML mails?
Can't this be done with different backends, so users/distros have the option to
simply use KHTML?
Post by Albert Astals Cid
Cheers,
Albert
Jan Kundrát
2015-04-20 19:49:20 UTC
Permalink
Post by Franz Fellner
Is it really necessary to use a multiprocess web framework just to view HTML mails?
I suppose that it is necessary to use an HTML content renderer which:

- is still supported,
- remains reasonably secure and up-to-date,
- provides sufficient features to make sure that users' privacy is not
compromised.

Whether it implies using multiprocess architecture or not is an internal
implementation detail. We might think that it's an overengineered beast,
but our opinion is not as important as the opinion of the guys who are
doing the actual work.
Post by Franz Fellner
Can't this be done with different backends, so users/distros
have the option to simply use KHTML?
I cannot speak for KDEPIM, but I can speak for Trojita which is currently
using QtWebKit.

Based on a quick glance through the KHTMLPart's public API, I cannot use it
in Trojita. One of the reasons is that HTML e-mails use the cid: URL scheme
for accessing data from other MIME parts in the same message. I don't see
any way to implement custom URL schemes *and* to disable arbitrary network
access on a per-message basis at the same time.

The e-mail clients unfortunately ar especial; their use case is much
different from a web browser model, they cannot work through a "just render
this HTML you read from this QIODevice", and at the same time thay are
expected to render rich HTML with full support for modern CSS. I'm not
surprised that KHTML's API is not sufficient; the QML-based API of Qt's
WebKit2 wasn't sufficient, either.

Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Eike Hein
2015-04-21 11:11:16 UTC
Permalink
Post by Albert Astals Cid
IMHO the duty of a distro is providing software to their users to use
But not under any circumstance: Enforcing some level of hygiene and
quality in the software provided is a service rendered in my interest
and protects me as a user. A lot of good has come from Debian forcing
projects to play nice with others.
Post by Albert Astals Cid
Cheers,
Albert
Cheers,
Eike
David Edmundson
2015-04-20 19:02:35 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Moreover we can't build debugging symbols on most archs due to the enormous
amount of RAM+swap it involves in the linking process (more than 8GB last time
I checked). This is at least the same as QtWebKit, but seems to be getting
worse.
gold linker seems to handle this a /lot/ better than normal ld.
It made my little laptop able to cope.

David
Vadim Zhukov
2015-04-20 19:56:48 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to
the problem that QtWebEngine poses for us distros (in this case, at least
Debian and Fedora).
I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a
hard (very hard) piece of software to package.
It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium is
not available for them.
Moreover we can't build debugging symbols on most archs due to the enormous
amount of RAM+swap it involves in the linking process (more than 8GB last time
I checked). This is at least the same as QtWebKit, but seems to be getting
worse.
Yes, we do understand that QtWebEngine is technically superior to any other
thing out there but making that code an acceptable package is another thing.
So basically what I'm trying to say is: don't expect us down streamers to
easily package QtWebEngine soon, if we ever get to it.
I'm really sorry if this comes as "bad news", but the reality is currently
this :(
And if such large-community distros like Debian and Fedora have
issues, what to say about smaller ones? Also, QtWebEngine isn't ported
outside of Linux, Windows and MacOS X at all.

I'm an OpenBSD developer, maintaining almost all Qt and KDE ports for
now. And I can clearly say that I won't ever start working on
QtWebEngine: chromium port in OpenBSD (maintained by a different
person) already has 285 (sic!) local patches, so QtWebEngine will need
at least as much. That's, obviously, too much. So until something
changes, there will be no KF5-based PIM on OpenBSD.

I'm not in favor of using outdated QtWebkit module either: it's likely
full of security holes, so it's not the thing you want to throw
incoming email at.

Could some sa[fn]e, compact, non-JS engine be used for viewing mail
and other PIM activities? What options do KDE PIM people see?

--
WBR,
Vadim Zhukov
Allan Sandfeld Jensen
2015-04-20 22:01:58 UTC
Permalink
2015-04-20 19:28 GMT+03:00 Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due
to the problem that QtWebEngine poses for us distros (in this case, at
least Debian and Fedora).
I know that kdepim seems to depend on it now. Sadly QtWebEngine it's
quite a hard (very hard) piece of software to package.
It embeds quite a lot of 3rd party stuff which we distros don't accept
(in different grades depending on the distro) as we require to build
using the system versions. Fedora's Rex Dieter tells me that's actually
why chromium is not available for them.
Moreover we can't build debugging symbols on most archs due to the
enormous amount of RAM+swap it involves in the linking process (more
than 8GB last time I checked). This is at least the same as QtWebKit,
but seems to be getting worse.
Yes, we do understand that QtWebEngine is technically superior to any
other thing out there but making that code an acceptable package is
another thing.
So basically what I'm trying to say is: don't expect us down streamers to
easily package QtWebEngine soon, if we ever get to it.
I'm really sorry if this comes as "bad news", but the reality is
currently this :(
And if such large-community distros like Debian and Fedora have
issues, what to say about smaller ones? Also, QtWebEngine isn't ported
outside of Linux, Windows and MacOS X at all.
I'm an OpenBSD developer, maintaining almost all Qt and KDE ports for
now. And I can clearly say that I won't ever start working on
QtWebEngine: chromium port in OpenBSD (maintained by a different
person) already has 285 (sic!) local patches, so QtWebEngine will need
at least as much. That's, obviously, too much. So until something
changes, there will be no KF5-based PIM on OpenBSD.
I'm not in favor of using outdated QtWebkit module either: it's likely
full of security holes, so it's not the thing you want to throw
incoming email at.
QtWebKit is not outdated yet. And security is least of problems when it starts
getting older. The main problem is that it is slowly losing the ability to
show modern webpages. The first causality was YouTube TV mode and anything
else depending on Media Stream Extensions. More will join those once age sets
in, but for EMail or wikipedia; I think QtWebKit should be fine for a few
years yet, especially for applications that continued to use Qt4.8 QtWebKit
until recently.

Anyway, QtWebEngine runs a patched fork of chromium, and while we don't
support OpenBSD, you are welcome to contribute patches to us.

Regards
`Allan
Milian Wolff
2015-04-20 21:02:35 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to
the problem that QtWebEngine poses for us distros (in this case, at least
Debian and Fedora).
I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a
hard (very hard) piece of software to package.
It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium
is not available for them.
Moreover we can't build debugging symbols on most archs due to the enormous
amount of RAM+swap it involves in the linking process (more than 8GB last
time I checked). This is at least the same as QtWebKit, but seems to be
getting worse.
Yes, we do understand that QtWebEngine is technically superior to any other
thing out there but making that code an acceptable package is another thing.
So basically what I'm trying to say is: don't expect us down streamers to
easily package QtWebEngine soon, if we ever get to it.
I'm really sorry if this comes as "bad news", but the reality is currently
this :(
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 ***@qt-
project.org .

Previously, many of the 3rd party stuff was just hardcoded and shipped
internally because it was easier to get stuff done. 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.

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.

Bye
--
Milian Wolff
***@milianw.de
http://milianw.de
Luigi Toscano
2015-04-20 21:19:22 UTC
Permalink
Post by Milian Wolff
I'm not a KDE PIM maintainer, but with my KDevelop hat
on (that uses a web view to display documentation pages, currently QtWebKit),
kio_man uses khtml (why don't you use it)? But anyway, also khtml is
deprecated. On the other side, the html for manpages is pretty basic, and we
control the generation - are we sure it can't work with QText* things?
Same thing for khelpcenter, I can fix the generated html.
I think that sometime the full blown html viewer has been abused, hence my
question.

Ciao
--
Luigi
Milian Wolff
2015-04-21 07:47:21 UTC
Permalink
Post by Luigi Toscano
Post by Milian Wolff
I'm not a KDE PIM maintainer, but with my KDevelop hat
on (that uses a web view to display documentation pages, currently QtWebKit),
kio_man uses khtml (why don't you use it)? But anyway, also khtml is
deprecated. On the other side, the html for manpages is pretty basic, and we
control the generation - are we sure it can't work with QText* things? Same
thing for khelpcenter, I can fix the generated html.
I think that sometime the full blown html viewer has been abused, hence my
question.
I'm not (only) talking about man pages (for which one could argue even a
monospace plain-text view could be sufficient). I'm also talking about:

a) PHP online documentation
b) QtHelp documentation
c) Python documentation
d) anything else you could conceive

All of the above can contain arbitrary HTML and we did have problems before
with QTextDocument. I can't remember why we moved away from KHTML, but afaik
that was due to bugs and it being more or less unmaintained for ages.
Furthermore, since we also displayed Html from within a QML code path at some
point, we loaded in QtWebKit anyways. So the real bloat was having multiple
HTML engines pulled in. Now, we only have QtWebKit, no KHtml.

Bye
--
Milian Wolff
***@milianw.de
http://milianw.de
Lisandro Damián Nicanor Pérez Meyer
2015-04-20 22:02:40 UTC
Permalink
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]
Post by Milian Wolff
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
Yes we have, but on the main devel mailing list, ***@qt-project.org
It has been troughly discussed, the thread is actually very long.
Post by Milian Wolff
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.
Post by Milian Wolff
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...
Post by Milian Wolff
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/
Milian Wolff
2015-04-21 07:39:35 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Sorry Milian, i've sent it to your personal address by mistake.
Resending to the list.
[snip]
Post by Milian Wolff
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
It has been troughly discussed, the thread is actually very long.
When did this take place and what is the threads subject? I seem to have
missed it, and also can't find it in my recent mails. Sorry for that.

Thanks
--
Milian Wolff
***@milianw.de
http://milianw.de
Jeremy Whiting
2015-04-21 15:26:56 UTC
Permalink
The thread subject is "Deprecating modules with 5.5" on the qt development list.
Post by Milian Wolff
Post by Lisandro Damián Nicanor Pérez Meyer
Sorry Milian, i've sent it to your personal address by mistake.
Resending to the list.
[snip]
Post by Milian Wolff
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
It has been troughly discussed, the thread is actually very long.
When did this take place and what is the threads subject? I seem to have
missed it, and also can't find it in my recent mails. Sorry for that.
Thanks
--
Milian Wolff
http://milianw.de
Kevin Kofler
2015-04-21 16:24:18 UTC
Permalink
Post by Milian Wolff
When did this take place and what is the threads subject? I seem to have
missed it, and also can't find it in my recent mails. Sorry for that.
It was a subthread starting here:
http://lists.qt-project.org/pipermail/development/2015-February/019900.html
(It also overflowed into March.)

Kevin Kofler
Lisandro Damián Nicanor Pérez Meyer
2015-04-21 12:44:41 UTC
Permalink
On Tuesday 21 April 2015 09:39:35 Milian Wolff wrote:
[snip]
Post by Milian Wolff
Post by Lisandro Damián Nicanor Pérez Meyer
Yes we have, but on the main devel mailing list,
It has been troughly discussed, the thread is actually very long.
When did this take place and what is the threads subject? I seem to have
missed it, and also can't find it in my recent mails. Sorry for that.
Fair enough. One of them starts in [0], but there was another thread in which
even Lars participated. So far I haven't been able to find it, I'll keep
trying.


[0] <http://lists.qt-project.org/pipermail/development/2014-November/019333.html>
--
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/
Lisandro Damián Nicanor Pérez Meyer
2015-04-21 12:53:41 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
[snip]
Post by Milian Wolff
Post by Lisandro Damián Nicanor Pérez Meyer
Yes we have, but on the main devel mailing list,
It has been troughly discussed, the thread is actually very long.
When did this take place and what is the threads subject? I seem to have
missed it, and also can't find it in my recent mails. Sorry for that.
Fair enough. One of them starts in [0], but there was another thread in
which even Lars participated. So far I haven't been able to find it, I'll
keep trying.
[0]
<http://lists.qt-project.org/pipermail/development/2014-November/019333.htm
l>
Found the other one! The real thread begins in [1] when it was suggested to
deprecate QtWebkit with 5.5 (which doesn't means dropping). It contains some
interesting assertions, like Qt Creator people asking for an lightweight
alternative [2].

Then things get more interesting from the distro-side in [3].

[1] <http://lists.qt-project.org/pipermail/development/2015-February/019893.html>
[2] <http://lists.qt-project.org/pipermail/development/2015-February/019922.html>
[3] <http://lists.qt-project.org/pipermail/development/2015-February/019958.html>
--
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Stephen Kelly
2015-04-22 18:27:29 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Lisandro Damián Nicanor Pérez Meyer
Fair enough. One of them starts in [0], but there was another thread in
which even Lars participated. So far I haven't been able to find it, I'll
keep trying.
Found the other one!
FYI, if you provide a gmane link, you provide the whole thread:

http://thread.gmane.org/gmane.comp.lib.qt.devel/19929/focus=20000

Thanks,

Steve.

Kevin Kofler
2015-04-21 16:13:03 UTC
Permalink
Post by Lisandro Damián Nicanor Pérez Meyer
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...
Not to mention that we want our web browsers to not use FFmpeg at all (at
least not directly), but GStreamer 1. Sadly, due to how deeply FFmpeg is
entangled into Chromium, this does not look realistic for QtWebEngine. Using
GStreamer would mean that we could ship it only with unencumbered codecs
while still allowing our users to easily add patent-encumbered codecs, the
same codecs would work for all applications, and there would also be an
automated plugin installation mechanism. Chromium's hardcoded use of a
forked FFmpeg breaks all that.

We also want our web browsers to support a JavaScript engine that has a non-
JIT fallback, because the JIT does not work on our secondary architectures.
(For Debian, those are even PRIMARY architectures!) This is even less
realistic in Chromium, because V8 is hardcoded everywhere, and there is no
interest whatsoever in V8 upstream in supporting an interpreter fallback.
This issue means anything that requires QtWebEngine in KDE will NOT be
available on all those platforms, even if we were to package QtWebEngine.
(It would also increase our maintenance workload if we were to package
QtWebEngine, by requiring ExcludeArch or ExclusiveArch lists all over the
place.)

Kevin Kofler
Raymond Wooninck
2015-04-21 08:22:57 UTC
Permalink
On Monday, April 20, 2015 01:28:59 PM Lisandro Damián Nicanor Pérez Meyer
wrote:

(I am talking with my openSUSE packager hat on as I am the Chromium packager
and am part of the community team that packages KDE/Qt)
Post by Lisandro Damián Nicanor Pérez Meyer
It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium
is not available for them.
Isn't this the real main issue with the new QtWebEngine and Chromium itself ??
In the past I have been trying to get Chromium to build using system version
of the 3rd party stuff, but this only worked out for some of them. Google
didn't just included the 3rd party stuff, but also altered it to their needs
and some things never got upstreamed.

From what I understood the main reason for Fedora not to provide Chromium is
the inclusion of the ffmpeg sources. Fedora is not allowed to provide binaries
nor sources that contain stuff that could have legal implications. This was
also initially openSUSE's main concern, however the legal department of SUSE
accepted having the sourcecode on our BuildSercie, as long as we did not build
any codecs from it that could cause these legal issues.

This situation will not likely change as that there are old bug reports
regarding this situation and they were never resolved.

We followed the same approach for QtWebEngine and at the moment we are
providing both to our users.
Post by Lisandro Damián Nicanor Pérez Meyer
Moreover we can't build debugging symbols on most archs due to the enormous
amount of RAM+swap it involves in the linking process (more than 8GB last
time I checked). This is at least the same as QtWebKit, but seems to be
getting worse.
Switching to the gold linker would help quite a lot here. At least I am able
to build Chromium on armv7l with it :)

Regards

Raymond
Kevin Kofler
2015-04-21 16:33:01 UTC
Permalink
Post by Raymond Wooninck
Isn't this the real main issue with the new QtWebEngine and Chromium
itself ?? In the past I have been trying to get Chromium to build using
system version of the 3rd party stuff, but this only worked out for some
of them. Google didn't just included the 3rd party stuff, but also altered
it to their needs and some things never got upstreamed.
Yes, this is the main issue, for both Fedora and Debian.
Post by Raymond Wooninck
From what I understood the main reason for Fedora not to provide Chromium
is the inclusion of the ffmpeg sources. Fedora is not allowed to provide
binaries nor sources that contain stuff that could have legal
implications. This was also initially openSUSE's main concern, however the
legal department of SUSE accepted having the sourcecode on our
BuildSercie, as long as we did not build any codecs from it that could
cause these legal issues.
This is also a concern, but it could be fixed the same way as for other
affected packages, by ripping out the encumbered source code from the
tarball. That said, having maintained such a cleaning script for xine-lib
for a while, I am not looking forward to trying to clean FFmpeg that way
(FFmpeg is not in Fedora at all at this time; for some other packages that
bundle FFmpeg, we rm -rf the entire FFmpeg, but that is not doable for
Chromium/QtWebEngine), and the bundling of the forked FFmpeg is also against
Fedora policies to begin with.
Post by Raymond Wooninck
This situation will not likely change as that there are old bug reports
regarding this situation and they were never resolved.
And this is exactly why we urge KDE to not require QtWebEngine for anything.

Kevin Kofler
Sandro Knauß
2015-04-21 08:23:58 UTC
Permalink
Hey,

At the moment there is a discussion in kde-core-devel, that distros won't ship
QtWebEngine (at least Debian and Fedora). And ubuntu also will follow the
decision of debian.

The only part so far, that depends on QtWebEngine in kdepim is
KSieveUi::SieveEditorWebView

it only shows links like: http://tools.ietf.org/html/rfc5173
(some people said, that these kind of links should be easy to display with a
QText*)

Regards,

sandro

--
Am Montag, 20. April 2015, 13:28:59 schrieb Lisandro Damián Nicanor Pérez
Post by Lisandro Damián Nicanor Pérez Meyer
Hi everyone! I'm one of Debian's Qt maintainers and I'm writing here due to
the problem that QtWebEngine poses for us distros (in this case, at least
Debian and Fedora).
I know that kdepim seems to depend on it now. Sadly QtWebEngine it's quite a
hard (very hard) piece of software to package.
It embeds quite a lot of 3rd party stuff which we distros don't accept (in
different grades depending on the distro) as we require to build using the
system versions. Fedora's Rex Dieter tells me that's actually why chromium
is not available for them.
Moreover we can't build debugging symbols on most archs due to the enormous
amount of RAM+swap it involves in the linking process (more than 8GB last
time I checked). This is at least the same as QtWebKit, but seems to be
getting worse.
Yes, we do understand that QtWebEngine is technically superior to any other
thing out there but making that code an acceptable package is another thing.
So basically what I'm trying to say is: don't expect us down streamers to
easily package QtWebEngine soon, if we ever get to it.
I'm really sorry if this comes as "bad news", but the reality is currently
this :(
--
Sandro Knauß
Software Developer

Kolab Systems AG
ZÃŒrich, Switzerland

e: ***@kolabsystems.com
t: +41 43 501 66 91
w: https://kolabsystems.com

pgp: CE81539E Sandro Knauß
Bèrto ëd Sèra
2015-04-21 09:52:28 UTC
Permalink
This post might be inappropriate. Click to display it.
Continue reading on narkive:
Loading...