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

Thu Oct 19 21:28:54 UTC 2017

kossebau added a comment.

  In https://phabricator.kde.org/D8211#157206, @rjvbb wrote:

  > >   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.

  Fetching, building and installing kdev-php is a matter of minutes in this case. There are no complicated extra deps, quick check at https://cgit.kde.org/kdev-php.git/tree/CMakeLists.txt
  Discussing this here takes more time.

  Sorry but it has to be you to test this, as the other persons interested in this build option seem to have no time. Such is life, do not complain to me :) I already invested some of my time to help you, despite having my own projects with higher priority.

  >> 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.

  "That would allow CI to build all variants, unit tests to be run for all (if ever written) and developers having less work to build and test things."

  >>   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.

  My not-so-incorrect claim is based on months of usage experience with and development work on doxygen generated docs. There are functional elements in the document (driven by JavaScript), e.g, the "Properties inherited from" & Co. stuff. Content behind such elements is hidden/visible by random after loading (from what I experienced), and cannot be toggled. Then with newer doxygen version the default CSS results in unreadable titles e.g. on method sections. Which makes the docs rather unusable.

  The screenshot of the ECM docs linked above shows that content is rendered, indeed. But really, does it qualify as "fine"? Please take another look and even more try to make use of the document during development. I doubt you will keep that qualifier. Besides, kapidox does some custom processing and if those are docs fetched via GHNS, they are from api.kde.org server which runs a rather old doxygen version. So not representative of average doxygen generated docs.
  For some QCH file with recent doxygen version with no custom CSS or processing see e.g. https://share.kde.org/index.php/s/UhVPFAy2cTb8cBL and class docs for e.g.  KUiServerJobTracker

  For more background info grep "Doxygen bugs" at https://frinring.wordpress.com/2017/06/19/adding-api-dox-qch-files-generation-to-kde-frameworks-builds/ and see especially the first two bugs in that list.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D8211

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/5c009769/attachment-0001.html>