Hi, (resending here instead of qt-creator@, as hinted to by Eike)
two questions to anyone working on/with QCH files: Q1: what would be a good system path pattern (on *nixoid systems) for Qt-based libraries to install their QCH files to? Q2: And would/could there be some way to have 3rd-party QCH files automatically added to Qt Assistant, Creator & Co. on installation, to spare the user the additional manual step? For Q1, I see all the Qt ones are on my system at /usr/share/doc/packages/qt5/*.qch So far I would have guessed /usr/share/doc/$lib/$lib.qch might be a good location. So what patterns do people use for their QCH files when delivering to others as part of an install? For Q2, having to manually add all QCH files one-by-one to Qt Assistant & Co. does not nicely scale if there are a dozen and more 3rd-party QCH files (think e.g. all the non-KF5 and KF5 libs created in the KDE community). Would it perhaps make sense to have some registration system, so QCH files can register themselves somewhere, so Qt Assistant/Creator & other documentation viewers know what is present on the system? Would some simple sym-linking into some generic dir make sense for a start? The /usr/share/doc/packages/qt5 perhaps should be reserved to original Qt ones, but perhaps some separate generic dir like /usr/share/doc/qch would work? Or something based on ENV vars, which would avoid hardcoding such dirs into Qt Assistant & Co.? Actually it would be nice if an installed QCH file would be automatically added to Qt Assistant & Co., after all one installed it for a purpose. Are there any plans with regard to that? Background: I am currently working on adding QCH support to the buildsystem for all the libraries of the KDE Frameworks (and other (KDE) library products), for the generation of QCH files during builds (https://phabricator.kde.org/D2854). This is done with the goals that the API documentation of KDE Frameworks libraries can be viewed/used offline with e.g. Qt Assistant, Qt Creator or KDevelop, and that packagers/distributors of those libraries automatically from the build also have a QCH file matching the very API version of the library for packaging (& inclusion into in any package update mechanism). The implementation of this support is done by new CMake macros which for now make use of the QCH generation feature of doxygen. The macros even support the automatic qthelp:// linking to documentation of base libraries, like the Qt ones. So once that support works, there will be dozens of QCH files which currently would each need manual work by the user to have them added to Qt Assistant & Co. Not perfect! Cheers Friedrich _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development