[Development] Assistant WebKit/WebEngine support

[Kai Köhne]

> -----Original Message-----
> From: Development <development-bounces at 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