| Summary: | kcmultidialog/kcmshell5 help buttons broken; depend on khelpcenter | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kcmutils | Reporter: | Harald Sitter <sitter> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | a.samirh78 |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
For help:/ urls, I agree. For man:/ and info:/ we'll have to add handlers because currently UrlHandler only works with help:/. For man:/ and info:/ urls there is KHelpCenter, and Konqueror o/ The plot thickens. |
khelpcenter lives in applications and as such cannot be expected to be available for frameworks. yet kcmultidialog wants to always launch it for documentation paths which aren't absolutely specifying a scheme. e.g. kinfocenter's memory module sets X-DocPath=kinfocenter/index.html#kcm_memory which kcmmultidialog will QUrl as 'help:/kinfocenter/index.html#kcm_memory' and as a help:/ URL then *always* runs through khelpcenter, which may not be installed (and the help button will be enabled but do nothing because of this). Kcmmultidialog probably should run all urls through QDesktopServices, which should have an url handler installed by kguiaddons (see UrlHandler.cpp in kguiaddons). IOW: drop the explicitly call to khelpcenter void KCMultiDialog::slotHelpClicked() { ... const QUrl docUrl = QUrl(QStringLiteral("help:/")).resolved(QUrl(docPath)); // same code as in KHelpClient::invokeHelp const QString docUrlScheme = docUrl.scheme(); if (docUrlScheme == QLatin1String("help") || docUrlScheme == QLatin1String("man") || docUrlScheme == QLatin1String("info")) { QProcess::startDetached(QStringLiteral("khelpcenter"), QStringList() << docUrl.toString()); } else { QDesktopServices::openUrl(docUrl); } }