Description of problem: khelpcenter does not find or display documentation for Gnome applications, specifically those that store their docs in /usr/share/help/C/. These use the same Docbook format as the KDE documentation in /usr/share/doc/HTML/ so I would expect it to be displayed. When choosing the Help function in these applications they even run khelpcenter, so that's a pretty solid reason that this should be working. However, khelpcenter just displays "Documentation not Found" when said help function is chosen. Version-Release number of selected component (if applicable): khelpcenter-23.04.3-1.mga9 How reproducible: All Gnome apps I've tried with their documentation in /usr/share/help/C/ exhibit this. Steps to Reproduce: 1. Install a Gnome application with help, e.g. gparted, viking, five-or-more 2. Note that "ls -R /usr/share/help/C/" shows that documentation exists 3. Run and choose the "Help→Help" or "Help→Contents" option from the program 4. Note the "Documentation not found" error message
Did You know if this works as you expect in other distro? Because this sound to me as lack of consensus between kde and gnome
I haven't tried it on another distro. I would expect it to work because 1) the underlying document format is Docbook in both cases, so there doesn't seem to be a technical reason it *shouldn't* work, but more importantly 2) when I choose the Help option from those Gnome programs, they load khelpcenter to show their help. If in the unlikely case that khelpcenter isn't expected to show this help, then this bug changes to "Gnome apps open wrong help program in KDE environment". But my educated guess is that's not it.
I discovered that yelp is already installed on my KDE system so I tried running gnome-help only to discover that it also had no idea of the application manuals installed in /usr/share/help/C/ when I searched for them. Starting it with a path like "gnome-help /usr/share/help/C/five-or-more/index.page" showed me the manual just fine. Trying the equivalent with khelpcenter "khelpcenter /usr/share/help/C/five-or-more/index.page" caused it to show an introductory paragraph on the program and no more. Trying "khelpcenter /usr/share/doc/HTML/en/dolphin/index.docbook" caused it to open my default text editor on the docbook file. Trying "khelpcenter help:/dolphin" opened that latter same file just fine. So, maybe there's an index cache file or a path that needs to be updated so "khelpcenter help:/viking" would work.
https://lists.snapcraft.io/archives/ubuntu-doc/2007-February/008176.html
Interesting history, but I'm not sure it's still relevant 17 years later. khelpcenter today supports the ghelp:/ URL scheme for accessing Gnome manuals, but that's not working for me either. See https://github.com/KDE/khelpcenter
I've been digging into some of the code and, as usual, it's not straightforward. It seems that whatever is going wrong isn't khelpcenter's fault directly, as it uses a KIO slave to access help files. It looks like it's kio_help.so's fault it's not finding the documentation, and that seems like it's because kdoctools isn't giving it the correct path. kio_help calls KDocTools::documentationDirs() to get the directories to search for docs, and that appears to only provide it the two directories /usr/share/doc/HTML/ and /usr/share/doc/kde/HTML/, plus (presumably) some local variants of those two (I'm guessing /usr/local/..something and ~/.local/share/...something). If I create a symlink "sudo ln -s /usr/share/help/C/viking /usr/share/doc/HTML/en" then run "khelpcenter help:/viking" I get the documentation just fine. This doesn't work for other programs like five-or-more, presumably because viking supplies an index.docbook file but the other doesn't. It also looks like the main difference between kio_help and kio_ghelp is that the latter looks for an index.html file by default (whereas the former looks for index.docbook), and it treats .xml files specially. It seems that they both look for their files in the same places. Does the Gnome help system on Mageia find the documentation files fine? If not, then maybe the Gnome docs should be moved into a location that KDE can also find them. If it *does* work fine, then Gnome apps should be changed to use gnome-help to load help instead of loading khelpcenter.
This is a crazy discovery: that Gnome applications uses KdeHelpCentre for showing help (which does not work because of different paths). Do we know whether a Gnome-only installation does this? I have played with gnome-help (not found in any menu), and you *can* make it display relevant help by this devious route: * start gnome-help. * at its introduction screen, titled 'GNOME help', look in *its* menu and select 'All Help' * which then changes the window title to 'Help', and lists all applications known to it (presumably /usr/share/help/C/*). * They work as expected. Following Dan, Gnome help also works directly for a known application: $ gnome-help /usr/share/help/C/<application help directory name> This is very unsatisfactory. How has it survived so long? Is it inherent in Gnome, or due to our packaging? Does anyone have a Gnome-only installation to poke this? [CC'ing Ben, who might have]. I doubt that running the Gnome Live ISO would have its applications' help, but CC'ing Martin who might know. khelpcenter alone does not show non-KDE application help. Should it? Is it Gnome's or KDE's fault, or both?
CC: (none) => lewyssmith, mageia, westel
(In reply to Lewis Smith from comment #7) > Does anyone have a Gnome-only installation to poke this? [CC'ing Ben, who > might have]. indeed I do. It is a Live system on a HDD partition, booted by grub, so as released. gnome-help brings up Yelp. Yelp works as expected. (gnome user/age guide) opening a vterminal and entering: $kde+tab results in: $kdeDesktopCleanup only the one kde entry. ls /usr/share/help/C/ lists 57 applications. tried a random few: eog => help: ( contents & about ) both display the expected results. gparted => help: ( contents & about ) both display the expected results. vinagre => help: ( contents & about ) both display the expected results. anything else required?
Also no problem on my main system, which uses the Cinnamon DE. Tested using Brasero. Help->Contents brings up the help, via yelp.
Thank you both for looking. So it seems that at least with a Gnome-only system, application help works. @Martin: does the system you tried have Plasma as well? @Dan: same question! @katnatek: please say whether you see the fault, and what desktops you have installed. Because my M9 system - which exhibits the reported fault - has both Gnome & Plasma; and I played with it under LXDE anyay. My suspicion is that the problem might only happen if you have Plasma installed. Except, wait, I am running here Mageia 8 multi-desktop (incl Gnome & Plasma) to compare; LXDE again. All the Gnome application help works correctly, often from F1, always from the Help menu... It also lives in /usr/share/help/C/* So for me, this is a reversion from M8 to M9. We must pin this down.
Summary: khelpcenter does not see Gnome documentation => Gnome application help yields "Documentation not Found" because it is routed via khelpcenter
No Plasma on my systems. A quick test in VirtualBox: 1. Installed from GNOME Live and rebooted. Brasero help routed through yelp and displays correctly. 2. Installed task-plasma5-minimal. Brasero help now routed through khelpcenter, which fails to find the documentation. See also https://forum.manjaro.org/t/khelpcenter-shouldnt-be-used-for-opening-gtk-apps-help-documentation/155418 https://bugs.kde.org/show_bug.cgi?id=480045
The system I found this on is indeed running Plasma. I tried renaming /usr/bin/khelpcenter to get it out of the way temporarily, and, lo and behold, help in all the applications in my original description started working (through yelp). More surprisingly, KDE application still had help displayed, only now it was through Firefox viewing a remote web page. Renaming khelpcenter back to normal caused everything to revert back to the description in the bug. Whatever in Gnome is causing those apps to try to use khelpcenter to display its help is clearly expecting it to work. That leads me to believe khelpcenter is not configured quite right. But, I'm starting to suspect that somebody is patching khelpcenter to let it find the Gnome help files and allow it to work. For comparison, I tried this on another system with only a basic XFCE installation which has neither yelp nor khelpcenter installed. On that system, pressing Help in the various standard installed apps does either absolutely nothing (e.g. atril, engrampa) or starts Firefox on a remote web page with documentation (e.g. mousepad, deluge). Those in the first category all have documentation in /usr/share/help/C/ and so should be using either yelp or some XFCE equivalent to display docs, but aren't. This is really a separate issue so I'll open a new bug for it (#33352).
Help for GTK applications is displayed by looking up and using the first available 'help:' URL handler. You can find what that is by # grep x-scheme-handler/help /usr/share/applications/*.* which on a system with both GNOME and Plasma installed returns /usr/share/applications/mimeinfo.cache:x-scheme-handler/help=org.kde.khelpcenter.desktop;yelp.desktop; /usr/share/applications/org.kde.khelpcenter.desktop:MimeType=x-scheme-handler/help;x-scheme-handler/man;x-scheme-handler/info; /usr/share/applications/yelp.desktop:MimeType=x-scheme-handler/ghelp;x-scheme-handler/help;x-scheme-handler/info;x-scheme-handler/man; If you comment out that line in /usr/share/applications/org.kde.khelpcenter.desktop and run # update-desktop-database then the help will be displayed using yelp.
(In reply to Lewis Smith from comment #10) > Thank you both for looking. So it seems that at least with a Gnome-only > system, application help works. > > @Martin: does the system you tried have Plasma as well? > @Dan: same question! > @katnatek: please say whether you see the fault, and what desktops you have > installed. I really not use much the applications help, my participation here was more try to help to Dan As the help of Ben and Martin is more useful, I let in others hands :D
(In reply to Martin Whitaker from comment #11) > > https://forum.manjaro.org/t/khelpcenter-shouldnt-be-used-for-opening-gtk- > apps-help-documentation/155418 > > https://bugs.kde.org/show_bug.cgi?id=480045 after going down the rabbit-hole, it seems Manjaro found a workaround. see => https://github.com/wwmm/easyeffects/issues/2046
That workaround seems to be on a per-application basis, so it's not really a solution. Now that I see where the problem comes from, this seems like a system issue. Both yelp and khelpcenter register support for the help: URL scheme, and the system chooses one of them (somehow) if more than one is installed. But, yelp only supports Gnome help URLs (e.g. yelp help:viking) and khelpcenter only supports KDE help URLs (e.g. khelpcenter help:kcalc). Using the same URL on the "wrong" application gives you an error. That means in any system with both KDE and Gnome apps installed, you can only get help for half of them. That's totally broken, and I hope I'm wrong.
We are overlooking that this problem did not happen on Mageia 8... (In reply to Dan Fandrich from comment #16) > Using the same > URL on the "wrong" application gives you an error. That means in any system > with both KDE and Gnome apps installed, you can only get help for half of > them It is OK if Plasma application Help goes via khelpcenter, and GTK application Help via yelp. How to fix this? Thanks Martin for your detective work. > Help for GTK applications is displayed by looking up and using the first > available 'help:' URL handler. You can find what that is by > # grep x-scheme-handler/help /usr/share/applications/*.* > which on a system with both GNOME and Plasma installed returns > /usr/share/applications/mimeinfo.cache: > x-scheme-handler/help=org.kde.khelpcenter.desktop;yelp.desktop; > /usr/share/applications/org.kde.khelpcenter.desktop: > MimeType=x-scheme-> handler/help;x-scheme-handler/man;x-scheme-handler/info; > /usr/share/applications/yelp.desktop: > MimeType=x-scheme-handler/ghelp;x- > scheme-handler/help;x-scheme-handler/info;x-scheme-handler/man; > > If you comment out that line in Which line? > /usr/share/applications/org.kde.khelpcenter.desktop and run > # update-desktop-database > then the help will be displayed using yelp. For GTK applications? What about Plasma ones? For Mageia 8 (with both Plasma & Gnome): $ sudo grep x-scheme-handler/help /run/media/lewis/LINUX1/usr/share/applications/*.* [sudo] password for lewis: /run/media/lewis/LINUX1/usr/share/applications/mimeinfo.cache: x-scheme-handler/help=yelp.desktop; /run/media/lewis/LINUX1/usr/share/applications/yelp.desktop: MimeType=x-scheme-handler/ghelp;x-scheme-handler/help;x-scheme-handler/info;x-scheme-handler/man; My head is spinning!
> It is OK if Plasma application Help goes via khelpcenter, and GTK application > Help via yelp. How to fix this? yelp claims to support the ghelp: scheme but ghelp: doesn't seem to actually work. One solution could be to fix yelp so ghelp: is a synonym to help: then patch our libgtk to use ghelp: instead of help: when Gnome apps request help.