[Qt-creator] Recommendations for 3rd-party QCH file installation folder for easy discovery?

[Friedrich W. H. Kossebau]

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