[Development] Assistant WebKit/WebEngine support

[Volker Hilsheimer]

> On 21 Jun 2019, at 16:45, Konstantin Tokarev <annulen at yandex.ru> wrote:
> 21.06.2019, 17:36, "Simon Hausmann" <simon.hausmann at qt.io>:
>> Am 21.06.19 um 15:42 schrieb Volker Hilsheimer:
>>>>  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.
>> 
>> I think that applies in particular content wise. On the other hand, I'm
>> a regular user of the ? mode in the locator in Qt Creator. That is SO
>> convenient in quickly looking up a topic and then getting back to code
>> just by pressing escape. The ability to view documentation "inline" is
>> great. Why should we remove the feature when we can make it work with
>> modern web content at our finger tips?
> 
> If think Qt Creator would benefit a lot from using separate help server process,
> as issues like [1] would be impossible, and one could just restart help server
> when things go wrong.
> 
> [1] https://bugreports.qt.io/browse/QTCREATORBUG-18456
> 
>> 
>> I don't see inline doc viewing or Qt assistant mutually exclusive with a
>> great documentation web app - I think that they could co-exist very well
>> (and should). However the former can be improved today with minimal
>> effort, while developing a Qt docs web app will take longer.
>> 
>> Simon

Yes, I think architecturally, a dedicated process to deal with content delivery, and a dedicated component to render that content, makes a lot of sense.

And I agree Simon that all those things don’t exclude each other. In fact, with a service that provides indexed searching and other high-level APIs to retrieve documentation content would make it a lot easier to develop some innovative interactions with the documentation, without having to worry about the “backend” stuff.

While it might formally be less work to improve the inline doc-viewing today, it is evidently quite hard just to get stuff to build.

Anyway, good to know that nobody seems to object to the idea of a documentation server in principle.

Cheers,
Volker