[Development] Assistant WebKit/WebEngine support

Edward Welbourne edward.welbourne at qt.io
Fri Jul 5 12:38:40 CEST 2019


Catching up with mail discussions that have happened while I've been
away, so sorry if I've missed some relevant part that covers this
already ...

On 25. Jun 2019, at 23:53, Konrad Rosenbaum <konrad at silmor.de> wrote:
>> Option 6: use plain platform browser to show local files
>> Pros: minimal footprint; assistant can be retired; guaranteed good
>> rendering
>> Cons: you never know which browser the user installs; abandon QCH
>> format; implementing search becomes a horrible mess of JS and other
>> files - requires extensive tool support to generate this - doubtful
>> that it will always work; forget embedded viewers - this would
>> require WebEngine or WebKit again; some users will hate the fact that
>> assistant is missing or at least unsupported
>>

>> Option 7: platform browser plus server process to deliver help via
>> local HTTP
>> Pros: like Option 6, but search becomes easier to implement
>> Cons: like Option 6, except search; someone needs to implement a
>> simple HTTP server (not that hard, but requires some work)

In fact, someone *has* done so, see QTBUG-60105 and the qthttpserver
module, which aims to provide embeddable HTTP serving as a service from
within arbitrary Qt apps.

https://bugreports.qt.io/browse/QTBUG-60105

It's a work in progress and I won't promise it's yet ready to fill all
your needs here; but, equally, it's in development and those needs would
probably serve as an excellent test-case to help guide the design of
what we do end up implementing.

>> and a search engine (slightly harder, but solvable)

Eike Ziller (26 June 2019 10:09) replied:
> Also I see usability issues (for 6+7), since we probably cannot
> control where the documentation opens when we request the browser to
> do so.  Opening a new tab/window any time the user presses F1 in Qt
> Creator would be pretty bad.

One solution to that would be for the client (Qt Creator) to open an URL
to a container-page that then opens a web-socket [*] back to the client,
which the client subsequently uses to load pages into the container.
The client would open the container page once, the first time it wants
to display something in the browser, and subsequently use the web socket
to say which pages it wants to open for browsing.

[*] Qt already includes web socket support; and, IIRC, qthttpserver
knows how to serve it.

	Eddy, still recovering from a post-holiday cold.


More information about the Development mailing list