Summary: | khelpcenter should fetch the documentation from the application's website if its not installed locally | ||
---|---|---|---|
Product: | [Applications] khelpcenter | Reporter: | alancio <lameventanas> |
Component: | general | Assignee: | Documentation Editorial Team <kde-doc-english> |
Status: | REPORTED --- | ||
Severity: | wishlist | CC: | lueck |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
alancio
2011-08-11 14:10:24 UTC
You get your reported error message "There is no ... akregator/index.html" because: 1) You did not install all necessary components for khelpcenter like eg the documentation. With a full install of khelpcenter you get since kde 4.5 this page if a documentation was not found: http://docs.kde.org/stable/en/kdebase-runtime/documentationnotfound/index.html On this page you find hints how to solve a problem with missing documentation (search online on docs.kde.org, install missing docs, online help resources) 2) You did not install the akregator documentation You missed the point completely. This is not a bug report about being unable to read akregator's documentation. Its an improvement suggestion to fetch the documentation from the Internet if its not installed in the local system. (In reply to comment #2) > You missed the point completely. No, the documentation not found page was exactly introduced for your requested purpose. Compiling/maintaining/keeping up to date a list of all online help resources / webpages for an application and use that in khelpcenter if a local help is not installed is impossible. That's why the documentation not found page has only general links to docs.kde.org, userbase and forum. (In reply to comment #3) > Compiling/maintaining/keeping up to date a list of all online help resources / > webpages for an application and use that in khelpcenter if a local help is not > installed is impossible. How about: http://docs.kde.org/?application=<appname> (In reply to comment #4) > > How about: http://docs.kde.org/?application=<appname> Yes that is indeed a good improvement for khelpcenter. And this is in principle manageable, the <appname> can be retrieved either from the url or from the X-DocPath entry in the *desktop files. I'd like to see this as additional action in khelpcenters menu or toolbar. It would be even usefull in case of a translated documentation because the english help on docs.kde.org is sometimes more up to date. But my development skills are near to zero, so to make this happen needs someone to step in. What about you? Btw. what do you think about changing the bug title (eg "Additional action to open english/language documentation local and on docs.kde.org")? I'm glad you acknowledged this is a good improvement. I can code, but unfortunately I don't have time nor KDE4 API knowledge, but this should be really easy for a KDE developer to pick and do. I don't know why you think that the bug's title is wrong, it describes what I am suggesting. I also don't understand why you focus so much on the fact that the documentation is in english. Perhaps you have KDE running in some other language and you were surprised by the fact that the website opened in english? The documentation is written for every language (to a different degree). For example, take a look at the kmail documentation in spanish: http://docs.kde.org/?language=es&application=kmail The URL scheme seems to be: http://docs.kde.org/?language=<language>&application=<appname> Where language is one of: en, ca, cs, da, de, en_GB, el, es, et, fr, gl, hu, it, ja, lt, nb, nl, nn, pl, pt, pt_BR, ro, ru, sr, sr@latin, sv, uk, zh_CN I suggest this bug to be assigned to the developer of khelpcenter, it should be relatively easy to implement. (In reply to comment #6) > > I suggest this bug to be assigned to the developer of khelpcenter, it should > be relatively easy to implement. Sadly there is no active developer for khelpcenter sing a long time :-( |