On FreeBSD we still do not have QtWebengine (it's rather hard to port). So we would like if would not be a replacement but selectable. I.e. that one can choose between WebKit and WebEngine (the latter being default).

In D5042#94866, @tcberner wrote:

On FreeBSD we still do not have QtWebengine (it's rather hard to port). So we would like if would not be a replacement but selectable. I.e. that one can choose between WebKit and WebEngine (the latter being default).

Are you sure? Seems like chromium has been ported:
https://wiki.freebsd.org/Chromium

Yes, I'm sure, unfortunately :) -- chromium is ported that is true. However, it requires lots of patches (500ish files need to be patched), most of which have to be modified and adapted to work with the version shipped inside the WebEngine tarball.

Considering how many security bugs are constantly fixed in Gecko and WebKit, I would dare say that any unmaintained HTML engine has known security bugs.

How does one embed a maintained HTML engine into a graphical application in FreeBSD, regardless of GUI toolkit?

The same way one does on Linux... I probably don't quite understand your question.

QtWebEngine is how we want to do it on Linux, hence the question ;)

Well, then the answer would be "WebKit" :) which is why I want to still have the option if possible -- you can add a cmake warning about "WebKit being less secure than WebEngine".
As for unmaintained, there is the hope for the fork at [1].

[1] https://github.com/annulen/webkit

In D5042#94915, @tcberner wrote:

Yes, I'm sure, unfortunately :) -- chromium is ported that is true. However, it requires lots of patches (500ish files need to be patched), most of which have to be modified and adapted to work with the version shipped inside the WebEngine tarball.

I think that it's possibly work worth doing... :/ we can delay the merge of this thing but as I see it, it's the way to go.
Right now we're already relying on a piece of software that possibly requires 500ish patches, i.e. qtwebkit.

Sorry that my comment is a rather philosophical one, and maybe a bit disconnected from reality, but ...
Do we really need a full web browser engine for this purpose? Effectively, we render text, links, and maybe ocassionaly a simple table and an image. Isn't there something simpler than a web browser engine (which is half an operating system these days) which provides us with these capabilities? What about the Qt Rich Text stuff?

I feel like QtWebEngine will have the same problem in five years all over again ...

What about the Qt Rich Text stuff?

I agree that in a perfect world that should be enough. After all Qt Assistant has a QTextBrowser-only build variant already since ages.

Sadly doxygen currently screws this perfect world though, as it generates QCH files with stuff inside which fails with QTextBrowser: https://bugzilla.gnome.org/show_bug.cgi?id=773715
So using QTextBrowser means any custom documentation created with doxygen will not be supported.

In D5042#95303, @brauch wrote:

Sorry that my comment is a rather philosophical one, and maybe a bit disconnected from reality, but ...
Do we really need a full web browser engine for this purpose? Effectively, we render text, links, and maybe ocassionaly a simple table and an image. Isn't there something simpler than a web browser engine (which is half an operating system these days) which provides us with these capabilities? What about the Qt Rich Text stuff?

I feel like QtWebEngine will have the same problem in five years all over again ...

Well, I do quite see how QtWebEngine is easier to maintain than QtWebKit.

If we use QTextEditor instead of this it will work for many things then some it won't and we'll be sad.

If you want, I can look into changing the StandardDocumentationView into a QTextEditor then we just use QtWebEngine for QtHelp and whatever plugin wants to do something fancier. This will duplicate some logic though, obviously.

QTextDocument won't be enough for our purposes. We actually embed e.g. the remote PHP documentation here. And even simple HTML features are not supported by QTextDocument.

I personally would vote in favor of a really thin abstraction around the webview features we use. Then allow building against either webkit or webengine. For our use cases, either should be good.

I personally would vote in favor of a really thin abstraction around the webview features we use. Then allow building against either webkit or webengine. For our use cases, either should be good.

That would be great, as it could also be used in other parts of KDE tempted to switch to WebEngine only.

In D5042#95355, @tcberner wrote:

I personally would vote in favor of a really thin abstraction around the webview features we use. Then allow building against either webkit or webengine. For our use cases, either should be good.

That would be great, as it could also be used in other parts of KDE tempted to switch to WebEngine only.

Like kmail bits - there is a lot of potential for sharing.

Then please, let me submit this change and as soon as there's something we can share with Kontact I'll do the port myself.