[Interest] [Development] Short/medium term evolution of the Assistant?

[René J. V. Bertin]

Kai Koehne wrote:

>> 1) make qttools depend on qtwebengine

---
I'm clearly not alone in thinking that QWE is serious overkill for documentation 
browsing. I'd rather explore solutions that involve using a HTML-rendering 
framework that's even leaner than QtWebkit in a "minimal" configuration. Khtml, 
maybe? Possibly limiting the use of that framework to local documentation (from 
qch files?) that can be considered vetted against potential security issues.

>> 2) make Assistant load a plugin that is provided by qtwebengine (and
>> qtwebkit)

Or any other suitable library. That'd work too.

> 3) Make assistant use the system browser.
> 
> 
> I've been wondering since a while how hard this would be - most platforms
> support embedding a browser in some way (see also Qt WebView). The obvious
> obstacle is that Qt Help / Qt Assistant right now serves the .html in memory,
> out of the .qch file. But we might as well just extract the .html as files,
> and work from there...

I've been thinking alone similar lines. I'm not aware that you can embed the 
system browser on Mac (even Apple's own Safari) but in a way Safari is a wrapper 
around the system copy of a more-or-less uptodate WebKit. I'm pretty certain MS 
Windows has a similar framework in place (MSHTML as mentioned by Konstantin).

Those could probably be used in combination with Qt's support for native 
windows. On Mac that'd still be using a framework that's way more powerful than 
should be necessary, of course.

I had another idea: rather than embedding a browser into the Assistant, embed 
the Assistant into the browser. It's more than likely that the user has a 
browser running most of the time, and most browsers nowadays have support for 
extensions. As far as I'm concerned the actual Qt Assistant as a standalone app 
could be simplified to use only QTB, in that case.

A QtAssistant extension would
1. provide access to and manage the user's QCH collection
2. provide a UI comparable to the current Assistant GUI (sidebar containing 
either the documentation sections or the glossary view with a search field)
3. hand off the selected, uncompressed HTML to the host application for 
rendering.
4. extend the host browser's URI scheme with a qthelp: scheme

The unknown here (for me) is how easily extensions can depend on a given Qt 
install and how complicated it would be to build it from source, and even to 
what extent all browser extension "stores" would accept plugins that are built 
on Qt. But maybe QCH access and collection support could be implemented purely 
in QML (aka JS)?