Bug 980068

Indeed, I can reproduce this here on a basically default Leap 42.1 KDE installation.

Install khelpcenter5 to "fix" it.

The problem is that susehelp (only) tries to run khelpcenter5 inside a Plasma5 session, but we still only install the KDE4 version by default (that's what you have in the menu and can start successfully manually).

So we'd need to add a dependency to khelpcenter5 somewhere, or maybe modify susehelp-khelpcenter to use the KDE4 khelpcenter instead if khelpcenter5 is not installed.

Btw, it doesn't work in IceWM too, even with khelpcenter5 installed (which is not used anyway when run outside of KDE).
This is a similar problem, but not the same, susehelp does detect which desktop session is running and uses different methods to show the help accordingly.

*** Bug 1002443 has been marked as a duplicate of this bug. ***

(In reply to Wolfgang Bauer from comment #1)

> So we'd need to add a dependency to khelpcenter5 somewhere, or maybe modify
> susehelp-khelpcenter to use the KDE4 khelpcenter instead if khelpcenter5 is
> not installed.

If you insist on making KDE Help Centre mandatory, thereby overriding upstream, then you need to change the mechanism of loading libkdeinit5_khelpcenter5 from run-time to load-time.

(In reply to Christopher Yeleighton from comment #3)
> If you insist on making KDE Help Centre mandatory, thereby overriding
> upstream

What are you talking about?

I/we insist on nothing.
khelpcenter is already mandatory upstream to display the applications' help, and always was AFAIR.

Actually openSUSE patches the khelpcenter menu entry to run susehelp instead of khelpcenter, but in a KDE session this again just runs khelpcenter (and that's how it is since years too).

> then you need to change the mechanism of loading
> libkdeinit5_khelpcenter5 from run-time to load-time.

And what does that mean?
This sentence doesn't make sense at all to me.

(In reply to Wolfgang Bauer from comment #4)
> (In reply to Christopher Yeleighton from comment #3)
> > If you insist on making KDE Help Centre mandatory, thereby overriding
> > upstream
> 
> What are you talking about?
> 
> I/we insist on nothing.
> khelpcenter is already mandatory upstream to display the applications' help,
> and always was AFAIR.

That is not what KDE developers have to say about the problem.

> 
> Actually openSUSE patches the khelpcenter menu entry to run susehelp instead
> of khelpcenter, but in a KDE session this again just runs khelpcenter (and
> that's how it is since years too).
> 
> > then you need to change the mechanism of loading
> > libkdeinit5_khelpcenter5 from run-time to load-time.
> 
> And what does that mean?
> This sentence doesn't make sense at all to me.

You can load a shared library into an application in two ways: at load time or at run time.  If you load it at load time, the application is bound to the library and will not start when the library is missing; if you load it at run time, the application can circumvent the problem of the missing library and do something else instead.  That is what KDE handbook command does by design: if the library is not present and it cannot execute khelpcenter(5), it launches the browser with online handbook instead.  Except that, in openSUSE, it does not.

Will this be an issue for LEAP 42.2 as well?

(In reply to Christopher Yeleighton from comment #5)
> You can load a shared library into an application in two ways: at load time
> or at run time.  If you load it at load time, the application is bound to
> the library and will not start when the library is missing; if you load it
> at run time, the application can circumvent the problem of the missing
> library and do something else instead.

So you mean linking to a library against loading it at runtime (like a plugin).
I don't see how this is relevant here. susehelp is a shell script.

And I was talking about changing that shell script to fallback to KDE4's khelpcenter instead if khelpcenter5 is not installed.

I meanwhile noticed that this won't work anyway, because KDE4's khelpcenter cannot find nor display the documentation of KF5 applications.

> That is what KDE handbook command
> does by design: if the library is not present and it cannot execute
> khelpcenter(5), it launches the browser with online handbook instead. 
> Except that, in openSUSE, it does not.

And what is the "KDE handbook command" please?

JFYI, libkdeinit5_khelpcenter5 is part of the package khelpcenter5.
If khelpcenter5 is not installed, the library is not there either.

But ok, I had a look at the code, and you're actually right.
kguiaddons does indeed start a web browser when the khelpcenter executable is not found.
We patch it to call susehelp instead though as mentioned (since years, before my time as contributor).
Uninstall susehelp, and it should open a web browser... ;-)

(In reply to Bo Simonsen from comment #6)
> Will this be an issue for LEAP 42.2 as well?

Well no, I will try to make sure that we install khelpcenter5 by default, if you install Plasma5 at least.

(In reply to Wolfgang Bauer from comment #7)
> (In reply to Christopher Yeleighton from comment #5)
> > You can load a shared library into an application in two ways: at load time
> > or at run time.  If you load it at load time, the application is bound to
> > the library and will not start when the library is missing; if you load it
> > at run time, the application can circumvent the problem of the missing
> > library and do something else instead.
> 
> So you mean linking to a library against loading it at runtime (like a
> plugin).
> I don't see how this is relevant here. susehelp is a shell script.
> 

It is relevant because if Konversation is load-time linked against a library, the package containing the library will be required for Konversation and the problem will be solved.  If you insist on overriding the KDE way, you may just load the library at load time because, unlike in KDE, it becomes required in openSUSE.

(In reply to Christopher Yeleighton from comment #8)
> (In reply to Wolfgang Bauer from comment #7)
> It is relevant because if Konversation is load-time linked against a
> library, the package containing the library will be required for
> Konversation and the problem will be solved.

konversation doesn't link nor load libkdeinit_khelpcenter5 at all (upstream).

Again, the KDE Frameworks try to run khelpcenter. Only if that command is not available, they start a web browser instead.

> If you insist on overriding
> the KDE way, you may just load the library at load time because, unlike in
> KDE, it becomes required in openSUSE.

That's nonsense.

We don't override the "KDE way" at all, as should be clear by now.
We merely patch the Frameworks to run susehelp instead of khelpcenter.
Again, try to uninstall susehelp, and you'll see that a web browser is started instead.

And there's no point in adding a link-time dependency to libkdeinit_khelpcenter5 either, it's much easier to just install khelpcenter5 by default.

Your comment gave me an idea on how to improve susehelp though.
It could just fall back to a web browser as well if khelpcenter5 is not installed. I will have a look at that too.

> konversation doesn't link nor load libkdeinit_khelpcenter5 at all (upstream).

So where does the error message come from?

(In reply to Christopher Yeleighton from comment #10)
> > konversation doesn't link nor load libkdeinit_khelpcenter5 at all (upstream).
> 
> So where does the error message come from?

What error message?

(In reply to Wolfgang Bauer from comment #11)
> (In reply to Christopher Yeleighton from comment #10)
> > > konversation doesn't link nor load libkdeinit_khelpcenter5 at all (upstream).
> > 
> > So where does the error message come from?
> 
> What error message?

Cannot load libkdeinit5_khelpcenter5.so: File not found.

(In reply to Christopher Yeleighton from comment #12)
> (In reply to Wolfgang Bauer from comment #11)
> > (In reply to Christopher Yeleighton from comment #10)
> > > > konversation doesn't link nor load libkdeinit_khelpcenter5 at all (upstream).
> > > 
> > > So where does the error message come from?
> > 
> > What error message?
> 
> Cannot load libkdeinit5_khelpcenter5.so: File not found.

And what are you doing exactly to get that error message?

When I try to open the manual in Konversation (Help->Konversation Handbook) without khelpcenter5 installed, I get this:
KDEInit could not launch khelpcenter5
(no reference at all to libkdeinit5_khelpcenter5.so or konversation trying to load it)

And that's coming from susehelp, when it tries to run khelpcenter5.
As I already wrote twice, uninstalling susehelp should make Frameworks open a web browser as fallback (and would also get rid of this error message).
Why don't you at least try that if you don't believe me?

And just to be clear: I'm 1000% sure that this comes from susehelp, because if I change the command to be run in /usr/bin/susehelp-khelpcenter, the error message changes accordingly too.

The only thing that needs/tries to load libkdeinit5_khelpcenter5.so is khelpcenter5 itself. But it does so at "load-time" (as you called it), and both are part of the same package anyway.

And even if konversation or the Frameworks would load libkdeinit5_khelpcenter5.so on runtime, it would be much easier to just add a package dependency manually than patching the code to load it on "load-time" instead. (And actually you claimed yourself that the upstream code should open a web browser if libkdeinit5_khelpcenter5.so cannot be found, so this should not be necessary at all then anyway...)

You're just totally overcomplicating (and maybe misunderstanding) things here.

(In reply to Wolfgang Bauer from comment #13)
> (In reply to Christopher Yeleighton from comment #12)
> > (In reply to Wolfgang Bauer from comment #11)
> > > (In reply to Christopher Yeleighton from comment #10)
> > > > > konversation doesn't link nor load libkdeinit_khelpcenter5 at all (upstream).
> > > > 
> > > > So where does the error message come from?
> > > 
> > > What error message?
> > 
> > Cannot load libkdeinit5_khelpcenter5.so: File not found.
> 
> And what are you doing exactly to get that error message?

I tell Konversation to show the handbook.

> 
> When I try to open the manual in Konversation (Help->Konversation Handbook)
> without khelpcenter5 installed, I get this:
> KDEInit could not launch khelpcenter5
> (no reference at all to libkdeinit5_khelpcenter5.so or konversation trying
> to load it)

Me too, but this message comes later.

> 
> And that's coming from susehelp, when it tries to run khelpcenter5.
> As I already wrote twice, uninstalling susehelp should make Frameworks open
> a web browser as fallback (and would also get rid of this error message).
> Why don't you at least try that if you don't believe me?

I am more interested in KDE handbook being broken in Leap than not working on my workstation, otherwise I would just install khelpcenter5.

> And even if konversation or the Frameworks would load
> libkdeinit5_khelpcenter5.so on runtime, it would be much easier to just add
> a package dependency manually than patching the code to load it on
> "load-time" instead. (And actually you claimed yourself that the upstream
> code should open a web browser if libkdeinit5_khelpcenter5.so cannot be
> found, so this should not be necessary at all then anyway...)

I got the impression that khelpcenter5 is required on Leap from what you said, and if it is required, there is no point in deferring loading the library.  Adding a dependency manually would be inappropriate in this situation.

But I understand that you have backed off now (in comment #9), so perhaps I can withdraw this suggestion too.

> 
> You're just totally overcomplicating (and maybe misunderstanding) things
> here.

Maybe I am, but we are failing to provide a decent product to the user, which is much more serious :-(

(In reply to Christopher Yeleighton from comment #14)
> > > > What error message?
> > > 
> > > Cannot load libkdeinit5_khelpcenter5.so: File not found.
> > 
> > And what are you doing exactly to get that error message?
> 
> I tell Konversation to show the handbook.

As I wrote, if I do that here, I only get 
"KDEInit could not launch khelpcenter5" which actually comes from susehelp.
So sorry, I cannot reproduce this.

> > 
> > When I try to open the manual in Konversation (Help->Konversation Handbook)
> > without khelpcenter5 installed, I get this:
> > KDEInit could not launch khelpcenter5
> > (no reference at all to libkdeinit5_khelpcenter5.so or konversation trying
> > to load it)
> 
> Me too, but this message comes later.

Not here.

Just to be clear: I do agree with you in that point that if somebody needs a library, it should require it on a package level. Whether that is figured out by rpmbuild automatically (which is when it is linked in at "load-time"), or we add a manual dependency (necessary if it is loaded at run-time) is secondary though.

But we'd need to know *what* something loads it. And I don't see anything except khelpcenter5.

Although, if we install khelpcenter5 by default, libkdeinit5_khelpcenter5.so will be installed as well anyway.

> > And that's coming from susehelp, when it tries to run khelpcenter5.
> > As I already wrote twice, uninstalling susehelp should make Frameworks open
> > a web browser as fallback (and would also get rid of this error message).
> > Why don't you at least try that if you don't believe me?
> 
> I am more interested in KDE handbook being broken in Leap than not working
> on my workstation, otherwise I would just install khelpcenter5.

But you seem to not want to believe me.
So uninstall susehelp as a test, and you will see that the web browser shows up instead.

> > And even if konversation or the Frameworks would load
> > libkdeinit5_khelpcenter5.so on runtime, it would be much easier to just add
> > a package dependency manually than patching the code to load it on
> > "load-time" instead. (And actually you claimed yourself that the upstream
> > code should open a web browser if libkdeinit5_khelpcenter5.so cannot be
> > found, so this should not be necessary at all then anyway...)
> 
> I got the impression that khelpcenter5 is required on Leap from what you
> said, and if it is required, there is no point in deferring loading the
> library.  Adding a dependency manually would be inappropriate in this
> situation.

It is not "required" really, at least not more than upstream requires it.

I try to explain the situation again:
- KDE Frameworks check whether the executable "khelpcenter" exists. If it does, it gets started, if not a web browser is run instead.
- We patch KDE Frameworks to use susehelp instead of khelpcenter. So in our case, KDE Frameworks check whether the executable (script) "susehelp" exists. If it does, it gets started, if not a web browser is run instead.
- susehelp tries to find out on which desktop it runs. In a Plasma5 session, it basically just runs khelpcenter5.

The problem now (on a standard installation) is that susehelp is installed by default, but khelpcenter5 isn't.

So KDE Frameworks do not fall back to a web browser, because susehelp is there.
But susehelp cannot run khelpcenter5 (because it isn't installed), and has no fallback, so it fails to open any documentation.

I hope the problem is finally clear now.

> But I understand that you have backed off now (in comment #9), so perhaps I
> can withdraw this suggestion too.

I have not "backed off" at all, from what anyway?

I still am of the opinion that *nothing at all* loads that library, except khelpcenter5 itself.

Actually I was already suggesting improvements to susehelp in comment#1 (as mentioned, falling back to the KDE4 khelpcenter won't work unfortunately though), opening a web browser (like KDE Frameworks do) if the help application cannot be run would be an option too.

> > You're just totally overcomplicating (and maybe misunderstanding) things
> > here.
> 
> Maybe I am, but we are failing to provide a decent product to the user,
> which is much more serious :-(

And?
This will be fixed by installing khelpcenter5 by default.
We will then have the same situation as we had in previous releases (with KDE4) for years.

The difference here is basically just that the KDE4 khelpcenter always was installed by default, it is in the package kdebase4-runtime which is pulled in by basically any KDE4 application. Now we'd need khelpcenter5 (which is in a separate package), but so far nobody thought of making sure it is installed.

This whole (IMHO pointless) "discussion" has already wasted far more time than actually fixing the problem would have taken...

plasma5-session requires khelpcenter5 now, so closing as fixed.

(In reply to Wolfgang Bauer from comment #15)
> (In reply to Christopher Yeleighton from comment #14)
> > > > > What error message?
> > > > 
> > > > Cannot load libkdeinit5_khelpcenter5.so: File not found.
> > > 
> > > And what are you doing exactly to get that error message?
> > 
> > I tell Konversation to show the handbook.
> 
> As I wrote, if I do that here, I only get 
> "KDEInit could not launch khelpcenter5" which actually comes from susehelp.
> So sorry, I cannot reproduce this.

The message appears in .xsession-errors.

> Just to be clear: I do agree with you in that point that if somebody needs a
> library, it should require it on a package level. Whether that is figured
> out by rpmbuild automatically (which is when it is linked in at
> "load-time"), or we add a manual dependency (necessary if it is loaded at
> run-time) is secondary though.
> 
> But we'd need to know *what* something loads it. And I don't see anything
> except khelpcenter5.

susehelp calls kshell5 and kshell5 probably talks to kinit5 (the utility is undocumented).  So yes, I was wrong.  Sorry about that.  I suppose kinit5 loads libraries at runtime on demand and it is by design.  

> I try to explain the situation again:
> - KDE Frameworks check whether the executable "khelpcenter" exists. If it
> does, it gets started, if not a web browser is run instead.
> - We patch KDE Frameworks to use susehelp instead of khelpcenter. So in our
> case, KDE Frameworks check whether the executable (script) "susehelp"
> exists. If it does, it gets started, if not a web browser is run instead.
> - susehelp tries to find out on which desktop it runs. In a Plasma5 session,
> it basically just runs khelpcenter5.
> 

So it seems that it would be appropriate to say that khelpcenter5 supplements susehelp and KF5.

> I hope the problem is finally clear now.

So do I :-)

(In reply to Christopher Yeleighton from comment #17)
> susehelp calls kshell5 and kshell5 probably talks to kinit5 (the utility is
> undocumented).  So yes, I was wrong.  Sorry about that.  I suppose kinit5
> loads libraries at runtime on demand and it is by design.  

Yes, kshell5 does talk to kinit5, it is even part of kinit (the package).

But actually it tries to run the executable first.
Apparently if the executable xxx is not found, it tries to load libkdeinit5_xxx instead.

See also "man kdeinit5".
(kshell5 and kwrapper5 are just different "frontends" to kdeinit5)

> So it seems that it would be appropriate to say that khelpcenter5
> supplements susehelp and KF5.

Not quite.
It would supplement susehelp and Plasma5, as susehelp only runs khelpcenter5 in a Plasma5 session.

Requiring it from plasma5-session should be good enough though as susehelp is installed by default anyway.

(In reply to Wolfgang Bauer from comment #15)
> (In reply to Christopher Yeleighton from comment #14)
> > But I understand that you have backed off now (in comment #9), so perhaps I
> > can withdraw this suggestion too.
> 
> I have not "backed off" at all, from what anyway?

<URL: https://bugzilla.opensuse.org/show_bug.cgi?id=1002443#c1 >

(In reply to Christopher Yeleighton from comment #19)
> (In reply to Wolfgang Bauer from comment #15)
> > (In reply to Christopher Yeleighton from comment #14)
> > > But I understand that you have backed off now (in comment #9), so perhaps I
> > > can withdraw this suggestion too.
> > 
> > I have not "backed off" at all, from what anyway?
> 
> <URL: https://bugzilla.opensuse.org/show_bug.cgi?id=1002443#c1 >

Hm?

I wrote there that "the expected behavior is to display the handbook in KDE's khelpcenter application".
Starting a web browser is just a fallback, and not the expected behavior... ;)

I admit that I wasn't aware of that fallback though.
It's new in Frameworks5, and it has only been added about a year ago:
https://quickgit.kde.org/?p=kguiaddons.git&a=commit&h=c61b3a8acfd013e50219e62da68f300ab43acfaf

Note that kdelibs4 does *not* have that fallback, so KDE4 applications (some are  still around) won't open a web browser at all if khelpcenter (or susehelp in our case) is not installed, but just display an error dialog.

(In reply to Wolfgang Bauer from comment #16)
> plasma5-session requires khelpcenter5 now, so closing as fixed.

As of KF5.32, it is possible to have plasma5 without plasma5-session and in that case KDE Help opens the browser as required.  Thank you.