On 21/05/2019 12:24, Kai Köhne wrote:
-----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.
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.
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
