[Development] Assistant WebKit/WebEngine support

[Volker Hilsheimer]

> On 21 Jun 2019, at 15:05, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
> 
> 
> 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?


Perhaps. But then, how many of us run dockerd on our local workstation? Or libvrtd?

Why not a Qt service that serves the Qt documentation? Why bother with shutting it down?


> Either way, this requires developing either a new frontend application 
> first or a back-end that can do the index searches, etc.


Indeed.


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



Personally I think the “external browser”, as in “the browser that I read all other development documentation in”, should be a first choice for displaying Qt documentation.


Volker