> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > Subject: [Development] Assistant WebKit/WebEngine support > > Hi, > > I am prepared to do some work on Qt Assistant, and I'd like to know how that > will be received.
Cool, great you want to tackle this 😊 I'm sure Jarek (the official maintainer) will also share his thoughts, but he's out of office this week. > [...] > I have been looking into the plugin idea, and although it is not straight > forward > I think it is doable. Some larger refactoring is needed to achieve a clean > border > between Assistant and the viewer plugin interface. My goal is to eliminate > calls > from the viewer plugin back into the Assistant application, which would > otherwise require some classes to be in a common shared library. I can > implement the QTextBrowser based viewer in a plugin that is statically linked, > so that Assistant will work out of the box whether it is being deployed with > or > without WebEngine. Plugins can be selected based on priority. That sounds like a good approach to me. Another abstraction you might consider is using Qt WebView as universal backend: https://doc.qt.io/qt-5/qwebengineview.html Qt WebView is an abstraction for showing web content, using different backends on different platforms. It is currently geared towards the mobile platforms, using Qt WebEngine as default backend on the desktop. Anyhow, it has already an (experimental) backend on macOS using Safari, and my hope is that we can make it also work with the new Chromium based Edge browser on Windows, see https://bugreports.qt.io/browse/QTBUG-75747 . Anyhow, I'm not sure the QtWebView API is actually capable enough to cater for Qt Assistant. One obvious challenge is that you've to pass a url to the engine that it can actually resolve. This probably means either extracting the html in the .qch files to a local directory, or even running a minimal local web server. There might be even more functionality missing ... But Qt WebView has already a plugin infrastructure, so you can at least take inspiration from there 😊 > Having the viewer back end be separated from the application with a plugin > interface may be an advantage regardless, whether WebKit comes back or > WebEngine is being removed from the Qt distribution in the future. At least > users will have a possibility to replace the default viewer with whatever > alternative is available. > > Does this sound like a good idea? I think your approach makes sense, but I'd wait for Jarek to comment first. Also, would you mind creating a JIRA item for this ? This way it's easier to track... Regards Kai _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
