| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T11588 Remove KDEWebKit | ||
| Open | None | T11607 Drop extragear/base/kwebkitpart | ||
| Open | gassaf | T11609 Port KTorrent away from WebKit | ||
| Open | None | T11610 Port choqok away from WebKit | ||
| Resolved | wrobelda | T11611 Drop WebKit support in KMyMoney | ||
| Open | None | T11612 Port libkvkontakte away from WebKit |
While I agree that removing QtWebKit and hence KDEWebKit from applications makes a lot of sense, there may still be a need for both in the future, in some niches.
Importantly, QWebEngine is not available for MinGW on Windows. RKWard happens to be bitten by this, because we also have a MinGW-only dependency.
At least for the time being, QtWebKit still seems to get some community support, and might (or might not) stay around for Qt6.
Perhaps a less harsh way of moving forward would be to block all non-local network requests in KDEWebKit by default, in order to mitigate the most obvious security concerns.
R.
To elaborate a bit, R _could_ be built with clang, as far as I know, but the official version is built with MinGW. And the problem is that we really need to build against that official version, because R's greatest asset is literally thousands of downloadable add-on packages. In theory each of these packages can be compiled from source, too, but on Windows they are distributed in binary form, for obvious reasons.
Now, in fact there are some emergency plans to deal with the situation, if QtWebKit goes away for good. The safer one of those will be to build only our backend with MinGW (fortunately, it is running in an all separate process, already), while building our frontend with MSVC (or clang). I'm not looking forward to making that build process work, though...
Anyway, I understand that active support for KDEWebKit would be too much to ask for. But perhaps active removal of the framework can be avoided.