[Development] Assistant WebKit/WebEngine support
volker.hilsheimer at qt.io
Fri Jun 21 15:42:16 CEST 2019
> 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
>>>>> 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 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 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.
>>>  https://codereview.qt-project.org/c/qt/qttools/+/111559
>> I’m not Jarek, but I recall that Eddy made a suggestion  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
>> What would be arguments against such a solution?
> I think it's a good alternative option. In practice, how would this look
> 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.
> 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.
More information about the Development