[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: mimetype problems...
From:       David Faure <faure () kde ! org>
Date:       2011-01-20 18:35:05
Message-ID: 201101201935.06213.faure () kde ! org
[Download RAW message or body]

> Context:
> In Konversation, post a URL of an image and click on it.
> Konqueror will open and display the image as text.

On Thursday 20 January 2011, Dawit A wrote:
> Unfortunately, the call to preferred service for "text/html" results in
> "kfmclient_html.destop" being returned and causing this issue due to the
> fixes to kfmclient. Anyhow, I guess the proper fix here would be to either
> change the initial preference levels in these two desktop files to favor
> "kfmclient.desktop" (*)
> or change the preferredService call to
> KService::serviceByDesktopPath and hard code kfmclient.desktop in
> invokeBrowser. What do you think david ?

Ah I see. invokeBrowser used to hardcode kfmclient, but I changed it to 
"preferred service for text/html" recently (r1208671) because some people want 
to use another kde browser (like rekonq) instead. (Your 2nd suggestion would 
mean basically reverting that change, so that's not a possibility.)

And your 1st suggestion wouldn't work either: kfmclient.desktop is _not_ 
associated to text/html, so it is not found at all by preferredService. This 
is on purpose, since it's the job of kfmclient_html.desktop to be associated 
with text/html. The comment is confusing because it predates r1208671.

The new invokeBrowser logic leads to a very strange situation indeed, where we 
are calling a service associated to text/html (kfmclient_html.desktop) for a 
URL that is not necessarily text/html (because invokeBrowser is being abused 
for images...), and this breaks the optimization in kfmclient_html where we 
pass text/html to save an additional mimetype determination in the cases where 
(unlike invokeBrowser) we already just found out that the mimetype is 
text/html!

Brainstorming about possible solutions:

a) hardcoding kfmclient and from kfmclient's code calling the preferred-app-
for-text/html would work fine, but it would still require that konqueror is 
installed, even to use rekonq, so in terms of dependencies it's not that 
great.

b) removing text/html from kfmclient_html.desktop would fix invokeBrowser but 
would make every other case slower, since we normally look up the apps for 
"text/html" only when we actually do have a text/html URL in the first place.

c) so maybe invokeBrowser shouldn't use text/html to find out the preferred 
browser, but I can't think of another solution, since we're talking about the 
case where the user changed the app order (to move up rekonq) in the mimetype 
settings (the componentchooser module is not used for this, it's for choosing 
a BrowserApplication (e.g. "all http links in firefox") setup).

d) I can only think of a hack in invokeBrowser that would say "if the 
preferredService for text/html is kfmclient_html.desktop then use 
kfmclient.desktop instead". This would work. It just puts back a special case 
for konqueror into invokeBrowser which the last change made finally generic...

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
[prev in list] [next in list] [prev in thread] [next in thread]