D8211: KDevelop/Documentation : implementation of a QTextBrowser-based viewer

René J.V. Bertin noreply at phabricator.kde.org
Thu Oct 19 19:43:42 UTC 2017

rjvbb added a comment.

  >   Sorry, no excuse :)
  Look, I'm doing this to help make KDevelop lighter and make a huge external dependency optional so I'm not really motivated to install all kinds of new stuff just to do a few tests. It's been a lot of work already, it won't be hard for someone who uses kdev-php to apply the patch and see what happens. I may need to step up if there are issues (that can be resolved), but as I've said from the onset, I really think this change can be collaborative. With the turn things are taking now it begins to look like this is another thing I've been doing just for my own benefit.
  If your claim is correct that online documentation won't render correctly, then a QW backend will need to remain for users who rely on such documentation.
  > I gave the reason there.
  You did not give a reason why YOU would want QWE and QWK backends available. It's an either/or choice already (in the order listed) and that makes sense given that QWK is deprecated.
  >   Unless there is another "Friedrich" involved, the one writing here would have only said the opposite., and surely did: QTextBrowser is _not_ sufficient for anything generated by Doxygen (sadly) or online/web-centric docs like the PHP ones.
  Sorry, I meant Francis.
  Your claim is incorrect: the KF5 framework documentation built as QCH with kapidox renders just fine as you can see from the screenshot of the ECM docs. What doesn't work is the rendering of embedded sourcefiles. I think that's a limitation we can live with, esp. with the possibility to open a link in an external Qt Assistant viewer.
  That's what I mean with an external browser, btw: something controlled from the IDE (evidently). That means opening links (the "Show documentation for" link in the contextual help popups) but can also mean opening bookmarks stored in the IDE, or going back in the history. Tight control about location in the UI is something I want too: somewhere outside, independent from the main window = on my secondary screen where it can take all the space it needs. With its single window approach KDevelop's UI is cramped enough as it is.
  You're really positioning yourself as someone who should testdrive this patch and upload a few screenshots showing failures (I was going to add "how easy it is to induce failures" but you can't really see that from a picture, can you :)).

  R32 KDevelop


To: rjvbb, #kdevelop
Cc: kossebau, aaronpuchert, flherne, arichardson, apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171019/db6ffd50/attachment.html>

More information about the KDevelop-devel mailing list