[Development] Assistant WebKit/WebEngine support

[Bastiaan Veelo]

On 21/05/2019 12:24, Kai Köhne wrote:

>> -----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.

Thanks for letting me know.

>
>> [...]
>> 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 😊

Although I haven't looked at QtWebView's API yet, it seems that indeed 
the best solution would be to add support for the qthelp scheme to 
QtWebView, possibly in a plugin to it? Konstantin mentioned that this 
has been discussed before. I think the abstraction could be taken from 
Qt Creator, 
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/help/webenginehelpviewer.cpp#n123, 
class HelpUrlSchemeHandler. I just had a glance at Qt Creator like 
Konstantin suggested. From what I can see, the help viewer itself is 
implemented as a Creator plugin, but the backend is determined at 
compile time much like Assistant is doing it currently. There is a lot 
of code duplication between Assistant and Creator, so it would be good 
to unify that code somewhere.

Assistant's challenge compared to Creator is the build order. Creator is 
built independently from Qt so it has no problems using QtWebEngine. 
Within a clean Qt clone however, Assistant is built before QtWebEngine, 
which is the main reason why 
https://codereview.qt-project.org/c/qt/qttools/+/111559 can't be pulled. 
So that is the main motivation for a plugin system. I am assuming that 
the same issue would exist if Assistant were to use QtWebView, as I 
assume the latter depends on QtWebEngine as well? In that case there 
would still be a build order problem. Can you confirm that?

I don't know enough about Qt's build system to know what is necessary to 
defer the build of Qt Assistant until after QtWebEngine/QtWebView has 
finished building. If that's necessary for using QtWebView then it would 
be good to focus on that first. When that's done then the existing 
WebEngine support PR can simply be merged into Assistant, which would 
close the long standing issue 
https://bugreports.qt.io/browse/QTBUG-55866. Then refactoring backend 
details from Creator and Assistant into WebView could be done at leisure.

[...]

>
> Also, would you mind creating a JIRA item for this ? This way it's easier to track...

There's this: https://bugreports.qt.io/browse/QTBUG-55866, that will do, 
right?

Thanks,
Bastiaan.