[kio] : khelpcenter no longer works on OS X

[René J.V. Bertin]

On Thursday June 02 2016 10:58:43 David Faure wrote:

>We both use an install prefix for the KF5-based code which is different from 
>the kde4 install prefix. 

Hah, I'm not the only one on here who still has enough reason to stick to a KDE4 (or at least, non-Plasma5) desktop! :)

>So how can kde4-khelpcenter find the docs which are in 
>the kf5 install prefix? I assume it uses $KDEDIRS, which doesn't contain my kf5 
>install prefix.

On Linux I do indeed, but not on OS X. I've been setting up my MacPorts ports such that KDE4 and KF5 versions can co-exist as far as that's possible.
One of the measures to achieve that is to omit the KF5 documentation through a "kde4compat" installation variant, and then it's clear that khelpcenter4 won't find any KF5 documentation for that package :) But even for packages kwalletmanager/kf5 which installs docs into share/doc/HTML/en/kwallet5 and thus doesn't have any conflict at this level, khelpcenter4 won't see or show the documentation.

khelpcenter5 behaves/d differently: it'd show multiple entries for kwallet for instance, but always show the same documents for each entry.
BTW, khelpcenter5 does seem to find the KDE4 documentation from the main prefix on Linux for me.

Luigi Toscano wrote on 20160602::11:16:02 re: "Re: [kio] : khelpcenter no longer works on OS X"

>If they are installed in the same prefix, as some distributions do, AND you have kdelibs4support which provides the old DTD, kio_help should find them.

That'd be for khelpcenter5, and confirms my impression above.

>Debian and Kubuntu use a different prefix but there is a patch that I don't like which searches also in the other patch. 
>The proper solution is a cmake to set custom search paths, which would help a future migration to /usr/share/help, but I couldn't work on it yet.

Wouldn't the really proper solution be to provide a settings dialog that allows you to add local documentation locations? I'd also love to see a possiblity to open a docbook directly. Good FOSS docbook viewers aren't very easy to find (in fact I found none) so that could really be an opportunity.

Besides, KF5 applications provided as standalone app bundles on OS X would currently have to provide their own embedded copy of the help centre if they want to be able to show the handbook. I had a quick look: converting the documentation to Apple's format isn't currently feasible without quite a bit of manual labour, and since standalone app bundles can be run from any location it won't be feasible to add their doc location to khelpcentre's search path.
So the easiest solution in this scenario would be to use LaunchServices to start khelpcentre and tell it to open /path/to/index.docbook . I can provide the necessary eventFilter() glue to handle the corresponding QEvents, but I think someone else will have to do the remaining work to actually open that docbook (if the code doesn't exist already).

R.