Hi, I think this discussion belongs to the development@ mailing list, since this is not solely about Qt Creator.
Br, Eike > On Nov 21, 2016, at 21:40, Friedrich W. H. Kossebau <[email protected]> wrote: > > Hi, > > 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 > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin [email protected] http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
