After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773715 - Enabling QCH files without any JavaScript, for viewers without such support
Enabling QCH files without any JavaScript, for viewers without such support
Status: RESOLVED OBSOLETE
Product: doxygen
Classification: Other
Component: general
1.8.13-GIT
Other Linux
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
[moved_to_github]
Depends on:
Blocks:
 
 
Reported: 2016-10-31 09:36 UTC by kossebau
Modified: 2018-07-30 10:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description kossebau 2016-10-31 09:36:40 UTC
There are two problems with JavaScript in QCH files:
a) QCH viewers might not support JavaScript
b) JavaScript code implements viewer functionality which might conflict with the functionality of the QCH viewer

Currently some JavaScript usage is hard-coded into the HTML generation of doxygen. QCH viewers though might not support JavaScript in QCH files. So when creating QCH files for an unknown user group, it would be good to have the option to create JavaScript-less QCH files.

While there seems no official spec about the content allowed in QCH files, the implementation of at least Qt Assistant & Qt Creator allows their build with either QtWebKit or QTextBrowser. With QtWebKit no longer official part of Qt >=5.6, in some Linux distributions Qt Assistant/Creator indeed are built against QTextBrowser, so any QCH files with JavaScript cannot be properly viewed when it comes e.g. to dynamic sections.

With QTextBrowser one is limited to this HTML feature set: http://doc.qt.io/qt-5/richtext-html-subset.html

From what I saw all JavaScript usage is done to implement viewer app functionality, as needed with browser-based usage. QCH files on the other hand are done for explicit viewer applications, which have that functionality built-in. So any doxygen-injected functionality-by-JavaScript might be duplicated or break the UI principles of the viewer app. Not nice.

I would be interested to work on a patch to improve the situation with doxygen, as these issues block some other work of me: I have developed some CMake macros to integrate the generation of QCH files using doxygen into builds of e.g. libraries created in the KDE community, like the KDE Frameworks (cmp. https://phabricator.kde.org/D2854, "ECMGenerateApiDox, for generating qch & tag files"). While I have been tempted to try some custom clang-based tool, I first would like to see what is possible with good-old doxygen :)

So what would be the favorite approach to this problems? So far I would tend to write a completely custom QchGenerator independent of the HtmlGenerator, so each can be optimized for the target format/usage and any improvements to either will not result in breakages of the other. Would such a patch with such an approach be conforming to the future development plans of doxygen and thus have a chance of getting merged, if otherwise okay? Or what else would you suggest?
Comment 1 André Klapper 2018-07-30 10:37:18 UTC
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to 

   https://github.com/doxygen/doxygen/issues

All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github.

Hence I am closing this GNOME Bugzilla ticket.
Please use the corresponding ticket in Github instead. Thanks a lot!