[Development] Assistant WebKit/WebEngine support

[Konstantin Tokarev]

21.06.2019, 16:07, "Simon Hausmann" <simon.hausmann at qt.io>:
> Am 21.06.19 um 14:57 schrieb Volker Hilsheimer:
>>>  On 21 Jun 2019, at 11:08, Bastiaan Veelo <Bastiaan at Veelo.net
>>>  <mailto:Bastiaan at Veelo.net>> wrote:
>>>
>>>  On 21/05/2019 12:24, Kai Köhne wrote:
>>>>>  -----Original Message-----
>>>>>  From: Development <development-bounces at qt-project.org
>>>>>  <mailto: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.
>>>
>>>  Jarek, could you please review this thread[1] and share your thoughts?
>>>
>>>  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.
>>>
>>>  Bastiaan.
>>>
>>>  [1]
>>>  https://lists.qt-project.org/pipermail/development/2019-May/035920.html
>>>  [2] https://codereview.qt-project.org/c/qt/qttools/+/111559
>>
>>  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:
>>
>>  * move the Qt Assistant functionality for searching and qch support
>>  into a locally executed HTTP server
>>  * use any proper webbrowser to display the help that this web service
>>  serves
>>
>>  What would be arguments against such a solution?
>
> I think it's a good alternative option. In practice, how would this look
> like?
>
> Would we provide a menu in the start menu for "Qt documentation" that
> would launch the web server and then the user preferred web browser with
> that url? How is the server terminated?
>
> Either way, this requires developing either a new frontend application
> first or a back-end that can do the index searches, etc.
>
> To me it seems easier to solve this first by making the Qt Assistant use
> WebEngine and when we later have a better doc "frontend" (as web app)
> switch to that and potentially an external browser.

Or just build Qt Assistant with enabled QtWebKit backend

-- 
Regards,
Konstantin