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)? _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
