In D6181#117136, @tbaumgart wrote:

Does printing still work? I am asking, because I see a message that says that WebEngine (is that the same?) printing is currently not working in KMail.

I don't know what you're asking about. This is the how timeline for html renderers looks like.
KHTML -> QWebKit -> QWebEngine

For printing I use this function but I have no real printer to check whether it works. PDF printer works for sure.
Maybe printer isn't working in KMail because this function is relatively fresh (since Qt 5.8) and isn't implemented there yet.

In D6181#117156, @wojnilowicz wrote:

For printing I use this function but I have no real printer to check whether it works. PDF printer works for sure.
Maybe printer isn't working in KMail because this function is relatively fresh (since Qt 5.8) and isn't implemented there yet.

If printing to PDF works, then printing to printers should be OK. The problem I would have: my Qt version is 5.6 from a stock distro. So I don't know if the patch is a good idea at this point in time.

In D6181#118016, @tbaumgart wrote:

In D6181#117156, @wojnilowicz wrote:

For printing I use this function but I have no real printer to check whether it works. PDF printer works for sure.
Maybe printer isn't working in KMail because this function is relatively fresh (since Qt 5.8) and isn't implemented there yet.

If printing to PDF works, then printing to printers should be OK. The problem I would have: my Qt version is 5.6 from a stock distro. So I don't know if the patch is a good idea at this point in time.

Mine Qt version is 5.7 and it works. See what's your version of QWebEngine. Mine is 5.8, so different from Qt.

I want to get my hands on this bug, but first I need to commit this patch.

I don't want this work to be lost or rebased endlessly, so maybe I will temporarily switch printing off, so vast of this patch can be useful for everybody. What do you think?

In D6181#118021, @wojnilowicz wrote:

In D6181#118016, @tbaumgart wrote:

In D6181#117156, @wojnilowicz wrote:

For printing I use this function but I have no real printer to check whether it works. PDF printer works for sure.
Maybe printer isn't working in KMail because this function is relatively fresh (since Qt 5.8) and isn't implemented there yet.

If printing to PDF works, then printing to printers should be OK. The problem I would have: my Qt version is 5.6 from a stock distro. So I don't know if the patch is a good idea at this point in time.

Mine Qt version is 5.7 and it works. See what's your version of QWebEngine. Mine is 5.8, so different from Qt.

I want to get my hands on this bug, but first I need to commit this patch.

I don't want this work to be lost or rebased endlessly, so maybe I will temporarily switch printing off, so vast of this patch can be useful for everybody. What do you think?

I understand, but printing is issential. This is on my stock openSUSE Leap 42.2

thb@thb-nb:~/devel/kmymoney/build (master)$ rpm -qa | grep webeng
libqt5-qtwebengine-5.6.1-4.2.x86_64

A bit late to the party but: the KDevelop team discussed a wrapper to be able to use QtWebEngine or QtWebKit (which is reborn), even if they ended up not using it (if I remember correctly). As other applications have the same need, would it make sense to coordinate over a wrapper?

In D6181#122312, @ltoscano wrote:

A bit late to the party but: the KDevelop team discussed a wrapper to be able to use QtWebEngine or QtWebKit (which is reborn), even if they ended up not using it (if I remember correctly). As other applications have the same need, would it make sense to coordinate over a wrapper?

KMM depends on Qt 5.6 and there is no QtWebKit there, so what would be the advantage of proposed solution?

In D6181#122338, @wojnilowicz wrote:

KMM depends on Qt 5.6 and there is no QtWebKit there, so what would be the advantage of proposed solution?

I said that it's reborn separately:
https://github.com/annulen/webkit

Currently it's being packaged in Fedora, for example, and it's drop-in replacement of the last version shipped with Qt 5.

In D6181#122339, @ltoscano wrote:

In D6181#122338, @wojnilowicz wrote:

KMM depends on Qt 5.6 and there is no QtWebKit there, so what would be the advantage of proposed solution?

I said that it's reborn separately:
https://github.com/annulen/webkit

Currently it's being packaged in Fedora, for example, and it's drop-in replacement of the last version shipped with Qt 5.

I understand, but why use QtWebKit, when QWebEngine is available in the Qt version we require and QtWebKit was never used in KMM and currently fades away?

In D6181#122342, @wojnilowicz wrote:

In D6181#122339, @ltoscano wrote:

In D6181#122338, @wojnilowicz wrote:

KMM depends on Qt 5.6 and there is no QtWebKit there, so what would be the advantage of proposed solution?

I said that it's reborn separately:
https://github.com/annulen/webkit

Currently it's being packaged in Fedora, for example, and it's drop-in replacement of the last version shipped with Qt 5.

I understand, but why use QtWebKit, when QWebEngine is available in the Qt version we require and QtWebKit was never used in KMM and currently fades away?

Because QtWebEngine is a beast to maintain, while QtWebKit is easier to port (for example FreeBSD has not QtWebEngine yet). The point is to have a evaluate whether wrapper to use both would be enough (if you migrated from KHTML, the features that you are using are probably common to both engines).

In D6181#122346, @ltoscano wrote:

In D6181#122342, @wojnilowicz wrote:

In D6181#122339, @ltoscano wrote:

In D6181#122338, @wojnilowicz wrote:

KMM depends on Qt 5.6 and there is no QtWebKit there, so what would be the advantage of proposed solution?

I said that it's reborn separately:
https://github.com/annulen/webkit

Currently it's being packaged in Fedora, for example, and it's drop-in replacement of the last version shipped with Qt 5.

I understand, but why use QtWebKit, when QWebEngine is available in the Qt version we require and QtWebKit was never used in KMM and currently fades away?

Because QtWebEngine is a beast to maintain, while QtWebKit is easier to port (for example FreeBSD has not QtWebEngine yet). The point is to have a evaluate whether wrapper to use both would be enough (if you migrated from KHTML, the features that you are using are probably common to both engines).

I see now - thanks for explanation. Sadly we don't have releases for FreeBSD, but it would be nice feature to have the wrapper. Maybe someone will undertake such a wish.

In D6181#122347, @wojnilowicz wrote:

In D6181#122346, @ltoscano wrote:

In D6181#122342, @wojnilowicz wrote:

In D6181#122339, @ltoscano wrote:

In D6181#122338, @wojnilowicz wrote:

KMM depends on Qt 5.6 and there is no QtWebKit there, so what would be the advantage of proposed solution?

I said that it's reborn separately:
https://github.com/annulen/webkit

Currently it's being packaged in Fedora, for example, and it's drop-in replacement of the last version shipped with Qt 5.

I understand, but why use QtWebKit, when QWebEngine is available in the Qt version we require and QtWebKit was never used in KMM and currently fades away?

Because QtWebEngine is a beast to maintain, while QtWebKit is easier to port (for example FreeBSD has not QtWebEngine yet). The point is to have a evaluate whether wrapper to use both would be enough (if you migrated from KHTML, the features that you are using are probably common to both engines).

I see now - thanks for explanation. Sadly we don't have releases for FreeBSD, but it would be nice feature to have the wrapper. Maybe someone will undertake such a wish.

There is a packager for KMyMoney and AqBanking who is packaging (or at least did package) for FreeBSD