11.06.2020, 11:11, "René J.V. Bertin" <rjvber...@gmail.com>: > On Thursday June 11 2020 04:31:59 Konstantin Tokarev wrote: > >> Whole point of QtWebView is to use platform specific backends on platforms >> where they do exist, at the cost of limited API. If you need to use >> platform-specific backends and want to replace QtWebEngine on platforms with >> no "native" browser component, it might make sense. > > I couldn't yet find a description of the reason(s) behind QtWebView, but > given the similarity between the WebView classes from it and from QtWebkit > you'd almost think that QtWebView was written as a replacement that uses > QtWebEngine as a backend unless it shouldn't (and that seems to be only on > Mac).
Main reason behind QtWebView is described in the root page of its documentation, and it's about mobile platforms, namely Android, iOS, and also WinRT. There is similarity between QtWebView's and QtWebKit's WebView QML types, however it happens because all powerful features of QtWebKit's WebView are located in WebView.experimental. Note that QtWebEngine provides WebEngineView type which is also quite similar. > > There's no such thing as a native browser component on Linux. Maybe if you > look at the DE level that GNOME has such a thing ... and using that would > probably mean reopening a discussion we had before (about webkit2-gtk) ;) > > Is possible in QML to "proxy" QtWebkit's WebView class, adding just the few > missing things to it, without taking a significant performance hit? It's possible to extend any QML item in QML, or inherit from underlying C++ class and register it as a new QML type. Out of curiosity, what do you want to add there? _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
