SUMMARY When I try to open an html file prepared by meinproc5 with khelpcenter, it displays an error message telling me to file a bug report. STEPS TO REPRODUCE 1. Enter a terminal command: khelpcenter ~/path/index.html (index.html created from index.docbook) 2. An error message is displayed. See attachment. OBSERVED RESULT I get an error. EXPECTED RESULT I should say the table of contents from the docbook I'm working with. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION This was working OK up until two or three days ago. And it still works OK on some platforms. I currently have five distros installed: Gentoo (updated daily), Artix Linux, Manjaro, openSUSE Tumbleweed. and openSUSE LEAP 15.3. This problem occurs with Gentoo, Artix, and Tumbleweed. Manjaro and LEAP 15.3 still work OK. I suspect a "Qt" module is to blame, because all three of the failing distros recently rolled some new Qt packages.
Created attachment 142122 [details] Screenshot of error message
As far as I know a generated html file can't be used directly, as khelpcenter only opens the docbook file (or the index.cache.bz2 files) from a known location.
I seem to recall just running khelpcenter against index.html created by meinproc5, but it's been quite a while, so it's likely that either something changed, or my memory is off. However, I just tried it now, and khelpcenter opened (with no help file) and then firefox launched index.html David - do you actually have firefox (or firefox-bin) installed? Separately, I also have a vague memory (confirmed by the man page) that there are some xsl stylesheets which can be mentioned as part of the meinproc5 invokation (with --stylesheet) to make the output display better with a standard browser rather than khelpcenter or konqueror (the man page just says "KDE browsers.") Final note - when invoking meinproc5, I do not get a index.cache.bz2 file generated. Does it somehow know when it is being invoked as part of a full build?
The change may be related to a recent change in kio and I guess going back would be tricky. About the index.cache.bz2 file, that's generated during the compilation, but if it's not found kio_help should process the docbook file directly.
OK, I figured out how to patch my way around it. I looked inside a couple of "index.cache.bz2" files, and realized that they're just all the little html files generated by meinproc5, rolled up into one big html file. So I tried renaming "index.html" to be "index.cache", and sure enough, khelpcenter opens the renamed file without a whimper. I can do that with any of the "chunks" generated by meinproc5. Can't follow links to other "pages" the way I used to, though. I still maintain that this is a bug no matter what others may believe. An application program ought not give a diddly do damn what the file name extension associated with a particular file is, or means. It ought to do what I tell it to do (e.g., open this file) and not try to second-guess my command. If it turns out that the program can't handle the file format, it ought to complain -- after it has tried to process the file. But it really ought not care about the file name, or the filename extension, and refuse to function on account of an irrelevant detail (like what I decided to call this particular file).
The problem with khelpcenter is apparently buried somewhere in "kio". For instance, I used to be able to open html files in Konqueror. Now (in my primary user account) Konqueror hands every html file I open from my hard disk to Kate. I can still view html files that are downloaded from the internet -- Konqueror renders them just fine. But if I try to open an html file from my hard disk, I'm left looking at the raw html code, rendered as text. I managed to get around this by creating a new user account. When logged in to the new account, Konqueror works correctly. So I suspect a problem with configuration files, somewhere. But I have no idea which ones.