D8211: KDevelop/Documentation : support using QTextBrowser (WIP/PoC)
René J.V. Bertin
noreply at phabricator.kde.org
Mon Oct 9 15:17:17 UTC 2017
rjvbb updated this revision to Diff 20519.
rjvbb edited the test plan for this revision.
rjvbb added a comment.
I've been cleaning up the code a bit, getting rid of unnecessary methods and improving things:
- external links are now handed off to QDesktopServices::openUrl() to be opened by the user's webbrowser (like Qt's assistant does)
- clicking on a link that fails to load now triggers a reload of the current URL (e.g. the "qmake" link, `qthelp://org.qt-project.qtcore.580/qmake/qmake-manual.html` on the QtCore doc homepage, `qthelp://org.qt-project.qtcore.580/qtcore/qtcore-index.html`)
That reload is delayed, the only way I found to ensure that clicking on a relative link to another topic in the current section (e.g. the "QPointer" link) will be resolved w.r.t. the correct base URL. It turns out to be tricky to determine whether QTextBrowser::setSource() will have the intended effect; I think that the call has no effect when a load is still in progress.
The only obvious improvement I see is to add a way for `HelpViewer::loadResource()` to load other kinds of resources. I'm thinking of a callback that one hands off to `StandardDocumentationViewer`. How generic should such a callback have to be (should the client also provide a QPointer to itself, for instance?) because how useful could such a function be for other dependent plugins? I notice for instance that the manpage plugin fails to display its navigation buttons.
CHANGES SINCE LAST UPDATE
To: rjvbb, #kdevelop
Cc: flherne, arichardson, apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the KDevelop-devel