<table><tr><td style="">rjvbb edited the summary of this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-7mirzbuyy5sdg5s/" rel="noreferrer">(Show Details)</a><br />rjvbb edited the test plan for this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-uiq2epqxwgy7x4d/" rel="noreferrer">(Show Details)</a><br />rjvbb set the repository for this revision to R32 KDevelop.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8211" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>CHANGES TO REVISION SUMMARY</strong><div><div style="white-space: pre-wrap; color: #74777D;"><div style="padding: 8px 0;">...</div>Qt's Assistant uses QtTextBrowser by default; I have been adapting its implementation to KDevelop's document viewer.<br />
<br />
<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">This is a first working draft patch, to be considered a work-in-progress or even just a proof-of-concept. It can probably be optimised some more,</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">As far as I can tell it works more than well enough to peruse the documentation the way I would in an embedded viewer.</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">but as far as I can tell it works well enough to peruse the documentation the way I would in an embedded viewer.</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">The layout is somewhat simpler,</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">In fact,</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">more in line with use in an embedded viewer;</span> I find it distracts less from the source<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);"> (I normally use dedicated documentation viewers)</span>.<br />
<br />
Using QTextBrowser is implemented as a fallback, you have to disable WebEngine and WebKit support (or not have either component installed) to activate this mode. I<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">'d prefer to add a build option for this,</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);"> would suggest to make this the default mode since it doesn't require extra dependencies, and focus on adding proper support for opening links in an external browser of choice at least for the QtHelp documentation. I currently have a working implementation that adds a contextmenu action to achieve this, using a remotely controlled instance of Qt's Assistant.</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">evidently.</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">I am looking into modifying the "Show documentation for" action in the context-help popups to trigger that external viewer also.<br />
</span></div></div></div><br /><div><strong>CHANGES TO TEST PLAN</strong><div><div style="white-space: pre-wrap; color: #74777D;">HTML rendering aside this seems to work as well as the QtWebKit-based mode. Links to different QtHelp sections <span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">(.qhc files) </span>don't work in either mode (e.g. the link to the QMake docs in the QtCore "Getting Started" section).<span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);"> I think that's simply a limitation of the QtHelp plugin design.<br />
<br />
Testing has been done on Mac and Linux,</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">I think that's simply a limitation of the QtHelp plugin design</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">with all 3 rendering backends</span>.<br />
<br />
<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">If this is considered of interest I'd probably appreciate a more collaborative approach on this one,</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">Backend comparison (QWK and QWE behaviour isn't modified by this patch):<br />
- QWK: links aren't followed; the contextmenu "Copy" action copies the link text, not the link address.<br />
- QWE: links are followed, contextmenu idem QWK. Tested on Mac only, where I get continuous errors that suggest inappropriate cross-thread calling, warnings about rejected JavaScript resources and a systematic crash on exit (also without this patch).<br />
- QTB: links work except across .qch files; links can be copied to the clipboard. "Lean and mean";</span> <span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);">supposing it still needs a lot of work</span><span style="padding: 0 2px; color: #333333; background: rgba(151, 234, 151, .6);">the QtHelp plugin is prewired to support opening links in an external full-fledged doc browser</span>.</div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8211" rel="noreferrer">https://phabricator.kde.org/D8211</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop<br /><strong>Cc: </strong>aaronpuchert, flherne, arichardson, apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger<br /></div>