mimetype problems...

[Dawit A]

On Thu, Jan 20, 2011 at 1:35 PM, David Faure <faure at kde.org> wrote:

> > 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.
>

Ahhh right. kfmclient.desktop does indeed not have a text/html mimetype
association.

>
> 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).
>

My original reaction when I discovered the issue was to simply document the
behavior invokeBrowser and force application developers to do the right
thing, i.e call the appropriate KRun method, e.g. runUrl, when they are not
sure that the url is actually html page. After all invokeBrowser does
exactly what its namesake suggests! However, realistically speaking, such
expectations from developers are not really plausible in practise ; so why
not simply use xdg-open and kde-open only and remove everything else ? Why
is there a need to do a preferred service and/or the "BrowserApplication"
setting look ups ? From my tests, calling either xdg-open or kde-open seems
to do the right thing, even when the user overrides the default browser
using the default app chooser from the system settings.


> 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...
>

Though sometimes necessary I really dislike exceptions like this option,
specially since such hacks have a nasty habit of coming back to bite us at
some point down the road...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20110120/bc310823/attachment.htm>