[Development] Assistant WebKit/WebEngine support

[Simon Hausmann]

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.


Simon