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

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In https://phabricator.kde.org/D8211#157173, @rjvbb wrote:
  
  > >   BTW, have you tested already how this change works with kdev-php?
  >
  > No, I don't "do" php. Doc plugins don't have to use the new API, in which case they get basically the same toolview behaviour as with the QtWebKit backend. This is what happens for the manpage and cmake documentation plugins (there are some minor rendering differences for the former, none that I noticed for the latter).
  
  
  Sorry, no excuse :) You do not need to do "php" to test the documentation. By default the PHP documentation plugin uses online docs from http://php.net.
  
  >> - adds another variant which is not covered by CI
  > 
  > That shouldn't be hard to fix for someone who knows how to do that and has the required access.
  
  "Should not"... can you tell if it is? If so, how would it be fixed IYHO?
  
  >>   As developer, I actually would prefer it all three variants could be built and installed in parallel (given deps are available).
  > 
  > This could be a secondary step, because it'll require separating the backend code into something properly standalone. I don't like the additional complexity though. Why would you want to have QWK and QWE backends available, for instance?
  
  Hu? Please re-read slowly again what you replied to, I gave the reason there.
  
  > As a developer and user I'd much rather see only a QTextBrowser backend. As Friedrich implied, it's more than sufficient for embedded documentation viewing. Anything requiring more advanced rendering code is probably best perused in a dedicated browser.
  
  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.
  And "more advanced rendering code" still makes sense in an integrated development environment, at least to me, I see rendering power orthogonal to being part of IDE. Actually I consider a separate general browser application an inferior solution, as it does not allow to be properly integrated into kdevelop project/session management (project/session specific bookmarks, browsing history, tight control about location in UI etc).

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/6042bfca/attachment.html>