<table><tr><td style="">rjvbb added a comment.
</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><div><p>I'm tempted to think that anything too complex to be rendered correctly is probably not really meant to be used in a simple embedded browser anyway.</p>

<p>Qt have considered QTextBrowser sufficient to be used as the default render backend in the Assistant. In practice, the only things in QtHelp documentation I've encountered that didn't render properly with QTB were the inline copies of source files. <br />
If that's a concern, well, just use QWE or QWK instead of QTB...</p>

<p>BTW, don't the quick help tooltips use QTB?</p>

<p>Why did I bother? Because the idea of running what's essentially a full-blown webbrowser bothers me, knowing that KDevelop is already resource hungry enough as it is and that the documentation in question can be rendered well enough with QTB.</p>

<p>The implementation is indeed a bit more complicated than I thought it would be in the beginning but can probably be optimised. And as far as I'm concerned we could remove the QtWebKit support if this goes in.</p></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>apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger<br /></div>