Change Details

I filed a ticket a while back about implementing a standalone window in KDevelop's documentation plugin, which was flagged as a potential junior job: https://bugs.kde.org/show_bug.cgi?id=373950 I already attached a patch that provides a bare-bones implementation of using Qt's assistant as an external viewer for the Qt help plugin. I've polished up that code a bit and feel it's now at a stage where I can put it up for review. The basic idea is still to make use of the Assistant's remote control mode, spawning a single instance per session which receives commands through its stdin. I have added a configuration option to en/disable the feature. 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. That configurability enough for me, but maybe not for everyone. It'd also be nice to have a way to toggle the feature on and off without going to the settings dialog, either via the context popup menu or a toolbar item.

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 that. 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, spawning a single instance per session which receives commands through its stdin. I have added a configuration option to en/disable the feature. 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. It should not be hard to implement an application picker. There is only a single lowlevel `showDocumentation` method, which means that the external viewer is always triggered, even when you open the embedded docu toolview and click on a QtHelp link in there.

I filed a ticket a while back about implementing a standalone window in KDevelop's documentation plugin, which was flagged as a potential junior job: https://bugs.kde.org/show_bug.cgi?id=373950Please see the latest revision update message. I already attached a patch that provides a bare-bones implementation of using Qt's assistant as an external viewer for the Qt help pluginThis patch adds a method documentation plugins can use to open requested documentation in an external browser and inform the caller about that. I've polished up that code a bit and feel it's now at a stage where I can put it up for reviewThis 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 basic idea is stills to make use of the Assistant's remote control mode, spawning a single instance per session which receives commands through its stdin. I have added a configuration option to en/disable the feature. 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. That configurability enough for me, but maybe not for everyoneIt should not be hard to implement an application picker. It'd also be nice to have a way to toggle the feature on and off without going to the settings dialogThere is only a single lowlevel `showDocumentation` method, which means that the external viewer is always triggered, either viaeven when you open the context popup menu or a toolbar itemembedded docu toolview and click on a QtHelp link in there.