From kde-core-devel Wed Nov 19 18:02:04 2008 From: Albert Astals Cid Date: Wed, 19 Nov 2008 18:02:04 +0000 To: kde-core-devel Subject: Re: KDE applications need kfmclient to open links, Message-Id: <200811191902.04649.aacid () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=122711776805436 A Dimecres 19 Novembre 2008, Armin Berres va escriure: > Heyya! > > After reading the following Debian bug report [0] Pino Toscano and me > discovered the following: To be able to open links most KDE applications > rely on an installed available kfmclient executable [1]. The problem is > now: kfmclient is shipped with Konqueror. This means: If Konqueror is > not installed a lot of applications are not able to open links even with > another configured browser. For KDE user this isn't such a big problem, > but a Gnome user e.g. doesn't want to install Konqueror just to be able > to open external links. > The question is now: How can we solve this problem? I guess in theory > kfmclient should be a part of kdebase/runtime and not kdebase/apps, but > I don't know if this is feasible in pratice. I didn't check yet how > coupled kfmclient and Konqueror are and when distributed -runtime > and -apps are two different tarballs. > > Anyway this problem really must be addressed somehow soon. IMHO the correct fix is making ktoolinvocation use kio::krun because otherwise you are not respecting users preferred browser and are always opening kfmclient, but kdecore can not depend on kio so one would need some kind of smart trickery. Albert > > Greetings, > Armin > > > [0] http://bugs.debian.org/506125 > [1] See kdelibs/kdecore/kernel/ktoolinvocation.cpp for KDE 4 or > kdelibs/kdecore/kapplication.cpp for KDE 3. > KToolInvocation::invokeBrowser(...) respectively > KApplication::invokeBrowser(...) both execute > "startServiceByDesktopName("kfmclient", url, &error, 0, 0, startup_id, > false)" which fails for sure when kfmclient is not around.