There have been recent regressions in Qt's Assistant which make it much less appealing as a help/documentation browser, and it has always had the habit of resetting the documentation list on version upgrades. It is also prone to crashing if its database becomes corrupted, and doesn't support opening a .qch file from the commandline. I have been testing an alternative that uses the free kchmviewer (on SourceForge) and FreePascal's chmcmd (which technically can be distributed on its own). This works really nicely; there's a rich browsable content table and index, and doxygen's layout is much better preserved than Qt's Assistant does, currently. Icing on the cake: the .chm files can be up to about twice smaller. The only drawback is that doxygen's SEARCHENGINE feature is turned off (which means that generator.py has to cope with a missing searchdata.xml file), but is that feature actually used in .qch files? For now I've "hacked in" the .chm generation; my Python knowledge is a bit too rusty for kapidox's code to propose a quick, elegant patch that enables optional .chm generation. (Evidently it can be an advantage to load a browsable collection of documentation files, like Qt's Assistant does.)
I'm trying to attach an example but BKO currently won't let me.
Hello, Actually, the qch file doesn't take advandatage of the generator.py thing, nor of the searchdata.xml. It's quite unfortunate, but I have no idea how to deal with this. Currently, the only thing that KApidox does is generating the website at api.kde.org. Everything else is generated by shady bash-scripts that you can find in the repo websites/quality-kde-org Kapidox is supposed to slowly take over those, but as I'm starting my new job, I have to delay that a bit.
kapidox also contains the kapidox_generate script, which allows users (and packagers) to generate their own copy of the API documentation. That's where qch and chm files can come in. To which option does this "generator.py thing" (and thus searchdata.xml) correspond, --searchengine, --api-searchbox or --indexing? Those are all supposed to be off by default from what I understand, but searchdata.xml is apparently generated and used regardless of those options.
This is very true, because my focus was to have the apidoc website up and working. Currently, I wouldn't trust any other function than the website as shown on api.kde.org (that you can, of course, generate at home if you want to). Other features are to be added / enhanced / corrected.
That's the nice thing of using doxygen: if it generates the HTML for a website correctly, anything that bundles this same HTML into some kind of archive for perusing with a dedicated browser ought to provide the same information. Those qch and chm files are basically just websites in a single document. Qt's assistant used to be built on QtWebkit, kchmviewer still is (and is transitioning to QtWebEngine). I'm pretty sure that the Assistant regressions I mentioned are due to it no longer using QtWebkit. I'll put it on my list to see if I can add optional support for generating chm in kapidox. Fixing the missing searchdata.xml issue is easy and a matter of putting the corresponding code block in a try: ... except: pass block.