Please see the latest revision update message.
This patch adds a method documentation plugins can use to open requested documentation in an external browser and inform the caller about thatprovides a means for documentation plugins to use an external browser and inform the caller about that with an implementation for the QtHelp plugin (the standard documentation plugin where the feature makes most sense).
When such an external viewer is used, the embedded documentation toolview isn't opened or even initialised when you use the "Show documentation for" link in a QtHelp context help popup. The external browser is only called when necessary and its window can be configured (or minimised) independently from KDevelop). This means that the embedded documentation toolview isn't opened or even initialised when you use the "Show documentation for" link in a QtHelp context help popup.
The idea is to make use of the Assistant's remote control mode,e result is less interface clutter and a work area that doesn't have to compromise between coding space and space for supporting features, while gaining access to a more powerful documentation browser dedicated to and designed for this task. spawning a single instance per session which receives commands through its stdin.Users preferring to use an external viewer could thus also build KDevelop without linking to huge dependencies like WebKit or WebEngine; I have added a configuration opQTextBrowser is powerful enough for the other standard documentation to en/disable the featureplugins (for manpages and cmake docs).
Currently there is no GUI for selecting the assistant executable or to provide additional arguments (like a .qhc collection file corresponding to the Qt help directory): when active the feature tries to launch an executable called `kdevelop-qthelp-viewer` from the path.The Assistant's remote control mode is used, spawning a single instance per session which receives commands through its stdin. I have added a configuration option to en/disable the feature as well as to configure the path to the Assistant executable. This can of course be a wrapper script that adds additional arguments, It should not be hard to implement an application pickerlike `-collectionFile` or even a different application that understands the same control protocol.
The intended use is via the "Show documentation for" link in QtHelp balloons. Since there is only a single lowlevel `showDocumentation` method, which means that the external viewer is always triggered, even when you do open the embedded docu toolview and click on a QtHelp link in there. This is in accordance with the UI option name.