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

[Friedrich W. H. Kossebau]

Hi Uwe,

Am Donnerstag, 24. November 2016, 07:38:20 CET schrieb Uwe Rathmann:
> On Tue, 22 Nov 2016 18:05:20 +0100, Friedrich W. H. Kossebau wrote:
> > Q1: what would be a good system path pattern (on *nixoid systems) for
> > Qt-based libraries to install their QCH files to?
> 
> Qwt ( http://qwt.sf.net ) offers a qch file and is available for quite
> some time. So you could check, what is common practice among distro
> packagers.
> 
> F.e. on my box ( OpenSusSE 12.2 ) it is simply not part of qwt6-devel-
> doc. But the OpenSuSE package maintainer seems in general not being aware
> of these Qt specific files as the installation of the feature files is
> also broken.

>From a quick look I would guess the reason for no qwt.qch being part of any 
package with openSUSE is that it is only available as a separate download, so 
not part of the sourcecode tarball. Best file a bug about this, most packagers 
do not eat all their dog food, at least not until the last bit(e), and if no-
one has told them they will not know. Been there, done that :)

That is also why I started this thread, to make sure that those QCH files for 
all the KDE Framework libs and the other libs from KDE also can make it all 
the way to the end-user, and are not lost on the track or end up unseen in the 
corner.

So let's join forces here as creators of 3rd-party QCH files and form an 
interest group :)

BTW, seeing you have used doxygen 1.8.11 for creating the latest 
qwt-6.1.3.qch, you might be interested in this patch to doxygen perhaps:
https://github.com/doxygen/doxygen/pull/541
"Fix: Add missing jquery.js, dynsections.js & optional svgpan.js to QCH file"

And this bug report about the hardcoded JavaScript in QCH files from doxygen:
https://bugzilla.gnome.org/show_bug.cgi?id=773715

Seems things have regressed a little since https://blog.qt.io/blog/2009/01/15/
creating-qch-files-from-doxygen-revisited/ :(

> But the rest of the docs can be found below /usr/share/doc/packages/qwt6-
> devel-doc and IMO this is where I would expect to find qwt.qch as well.
> 
> Maybe other distros can give you a better hint.

Okay, thanks for this info.

> > 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?
> 
> To me one of the most error prone things is loading 3rd party plugins to
> the creator. This has mostly to do with binary incompatibilities between
> the libraries used for development and the one used by the Creator
> ( Assistant is less bad as being built together with Qt libs ) , but the
> fact, that plugins are loaded "automatically" from some directories is
> part of the problem.
> 
> Coming from having experienced maximal user frustration with this
> approach I wouldn't recommend to establish such an automatism.

? I was talking about the QCH files only, so no code/binaries involved :)

Though your comment points to the issue of multiple versions of some libs 
being installed at the same time: if their respective QCH files are all being 
automatically added in Qt Assistant & Co., this will result in some confusion, 
especially when it comes to resolving version-less qthelp:// urls. That needs 
more thinking.

One wild idea I had was to have IDEs know which QCH files belong to which 
libraries, and using the info they can get from the buildsystem about the used 
libs in the current project automatically activate the respective QCH files in 
the API documentation viewer module, or at least have them available as 
proposals. Might be handy when starting or joining a project :) Some long-term 
idea for now.

Cheers
Friedrich