KDE applications need kfmclient to open links, which is not shipped with kdebase/runtime

David Faure faure at kde.org
Tue Dec 2 10:25:55 GMT 2008


On Wednesday 26 November 2008, Armin Berres wrote:
> On Tue, 25 Nov 08 21:44, David Faure wrote:
> > Hmm. Can't find a good example for a case where this might happen though
> > (a misconfigured webserver wouldn't make konq load khtml, anyway,
> > and an image or anything else would be opened just as well in konq and in
> > a standalone app anyway)... 
> > But this made me grep for invokeBrowser and I found that knetattach 
> > was abusing invokeBrowser in order to launch konqueror on a ftp/fish/smb url.
> > This is wrong, it should use KRun instead...
> 
> But using "kioclient exec" instead of "kfmclient openUrl" wouldn't
> really break knetattach -- the difference would be that instead of
> Konqueror Dolphin will be used.

Yes (or rather it should use KRun since it's C++ code, but yes that's the
same thing as "kioclient exec" does). My point was that there might be other
pieces of code calling invokeBrowser for directories right now, and for
compatibility reasons we shouldn't break that, i.e. invokeBrowser has
to keep being able to do that. Otherwise after upgrading kdelibs people
would get new bugs from such code.

> > I would say "no in theory", but in practice it has been abused to do so, so 
> > changing it will break some apps... Using kioclient exec would make knetattach
> > launch e.g. dolphin, which is fine, while using xdg-open would make knetattach
> > launch some browser like firefox and the user gets an error, right?
> > Of course knetattach has to be fixed (any maintainer for it???), but this
> > abuse could exist elsewhere.
> > 
> > This was for the pragmatic answer. In theory I agree that xdg-open (if present)
> > would be a solution. Hmm, wait.
> 
> The real Problem here is, that xdg-open calls "kfmclient openUrl" when
> it finds a KDE environment

Indeed it does, my former testing where I said it didn't was a bit wrong.
What happens is: inside a KDE session it does, but if I ssh -X to another machine
then it doesn't, even though I'm only using KDE on both machines and
never configured any other browser to be used.
$ ssh -X othermachine
$ unset BROWSER
$ xdg-open http://www.kde.org   -> mozilla.

> Seems as if this is also not really what we want.

It is, but the issue is the default browser when not "really" in a KDE session
(even though I'm doing this ssh -X inside a KDE session........ is there a way
to detect that?)
Some users want firefox then, that's fine, but what if I want konq even then? ;)
I guess kubuntu should export BROWSER=konqueror, at least, to be consistent
with the k in its name ;)

> I guess once we know for sure how to replace the kfmclient call,

The kfmclient call is fine (as Thiago says it uses compat code, but that's
fine for now, for compat with kde3).  (kioclient didn't exist in kde3)

> KDE simply should call it

Yes, I agree with this now. Sorry for my bad testing earlier, I didn't realize I
was in fact testing the ssh -X case.

> What about kioexec?

How about doing kioexec --help to understand what it's about? ;-)

-- 
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list