<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>
<blockquote type="cite" class="">
<div class="">On 21 Jun 2019, at 11:08, Bastiaan Veelo <<a href="mailto:Bastiaan@Veelo.net" class="">Bastiaan@Veelo.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class=""><br class="">
On 21/05/2019 12:24, Kai Köhne wrote:<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">-----Original Message-----<br class="">
From: Development <<a href="mailto:development-bounces@qt-project.org" class="">development-bounces@qt-project.org</a>> On Behalf Of<br class="">
Subject: [Development] Assistant WebKit/WebEngine support<br class="">
<br class="">
Hi,<br class="">
<br class="">
I am prepared to do some work on Qt Assistant, and I'd like to know how that<br class="">
will be received.<br class="">
</blockquote>
Cool, great you want to tackle this 😊<br class="">
<br class="">
I'm sure Jarek (the official maintainer) will also share his thoughts, but he's out<br class="">
of office this week.<br class="">
</blockquote>
<br class="">
Jarek, could you please review this thread[1] and share your thoughts?<br class="">
<br class="">
One aspect to keep in mind is that although sharing code with QtCreator and/or using Qt WebView may sound like a better end solution than writing a WebEngine plugin to Assistant, it probably won't address the primary reason for writing the plugin, which is
 build order. Assistant is currently built before Qt WebEngine, which is why the existing patch[2] does not work in a clean checkout. If we were to switch to Qt WebView, I assume compilation of Assistant would have to be postponed just the same. The best solution
 would therefore be, in my opinion, to change the order of compilation, apply the existing patch, and consider refactorings and unifications thereafter.<br class="">
<br class="">
Bastiaan.<br class="">
<br class="">
[1] <a href="https://lists.qt-project.org/pipermail/development/2019-May/035920.html" class="">
https://lists.qt-project.org/pipermail/development/2019-May/035920.html</a><br class="">
[2] <a href="https://codereview.qt-project.org/c/qt/qttools/+/111559" class="">https://codereview.qt-project.org/c/qt/qttools/+/111559</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<div class=""><br class="">
</div>
<div class="">I’m not Jarek, but I recall that Eddy made a suggestion [1] which I think has been prematurely dismissed or at least not been discussed sufficiently, which is:</div>
<div class=""><br class="">
</div>
<div class="">* move the Qt Assistant functionality for searching and qch support into a locally executed HTTP server</div>
<div class="">* use any proper webbrowser to display the help that this web service serves</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">What would be arguments against such a solution?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Volker</div>
<div class=""><br class="">
</div>
<div class="">[1] <a href="https://lists.qt-project.org/pipermail/development/2019-May/036028.html" class="">https://lists.qt-project.org/pipermail/development/2019-May/036028.html</a></div>
<div class=""><br class="">
</div>
</body>
</html>