Review Request: Make kfmclient honor the user configured browser settings for local resources

[David Faure]

> On Dec. 24, 2011, 8:38 a.m., David Faure wrote:
> > konqueror/client/kfmclient.cpp, line 386
> > <http://git.reviewboard.kde.org/r/103524/diff/1/?file=44675#file44675line386>
> >
> >     The code later on uses "new KRun" for the case of a user-defined browser, given that KRun can handle that. Why not factorize this and call that code for local files too? It would make the code shorter and easier to maintain.
> 
> Dawit Alemayehu wrote:
>     Well that would be nice and that was my first choice, but unfortunately that is not possible because KRun::init would need to be modified to use the user defined browser settings for local URLs too. Right now it does not. However, doing that would mean hard coding the check for whether or not "konqueror/kfmclient" is the service configured to handle the given request (mimetype). I doubt we would want to do that. Without that change using the "new KRun" call for the local file case would cause an infinite recurssion where KRun will end up calling kfmclient to handle the local html page.
>     
>     However, the other way around is viable. That is we can use "KRun::run" for the "http" case too. It would absolve kfmclient from using "new KRun" which itself might end up calling it back under certain circumstances. Otherwise, unless I am missing something those two scenarios have to be handled differently.

The infinite loop issue can't happen if we only call KRun (from kfmclient) when a BrowserApplication is set (so it won't call back kfmclient).

Something is clear to me: if BrowserApplication should apply to local html files too, then KRun should use it for local html files. Otherwise other users of KRun won't do the right thing (well, ok, or via kfmclient, but that's a runtime dependency that they might not want -- we've had cases of people without konqueror installed at all).

IMHO the best fix is to let KRun handle http and local-html files the same way, and just call new KRun from kfmclient, for these two cases.

For krun this would mean something like this... hmm ok requires factorizing some code to avoid a goto...
http://www.davidfaure.fr/2011/krun.diff
Feel free to apply and test :-)
(I only tested that it doesn't break default (no-browser-app) usage)


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103524/#review9228
-----------------------------------------------------------


On Dec. 24, 2011, 10:16 p.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103524/
> -----------------------------------------------------------
> 
> (Updated Dec. 24, 2011, 10:16 p.m.)
> 
> 
> Review request for KDE Base Apps and David Faure.
> 
> 
> Description
> -------
> 
> The attached patch changes kfmclient so that it
> 
> * honors the user configured browser setting when the specified URL is a local page that is to be handled by a browser.
> * honors the user configured browser setting when the user specified url is ftp.
> 
> 
> This addresses bug 182591.
>     http://bugs.kde.org/show_bug.cgi?id=182591
> 
> 
> Diffs
> -----
> 
>   konqueror/client/kfmclient.cpp 339ba31 
> 
> Diff: http://git.reviewboard.kde.org/r/103524/diff/diff
> 
> 
> Testing
> -------
> 
> Change the browser in the default application list to "firefox" and make sure all of the following commands open the URL in firefox:
> 
> * kfmclient openURL http://www.kde.org 
> * kfmclient openURL /usr/share/doc/qt/html/index.html
> * kfmclient openURL ftp://ftp.kde.org
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111225/b64f34c8/attachment.htm>