mimetype problems...

David Faure faure at kde.org
Thu Jan 20 19:39:59 GMT 2011


On Thursday 20 January 2011, Dawit A wrote:
> 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.

runUrl is for when the mimetype is known, the right way when one wants to just 
"open a URL which could be anything" is: new KRun(url).

> After all invokeBrowser does exactly what its namesake suggests! 

This is very true. It should open a webbrowser.
Which means: not an image viewer. Read on...

> so why not simply use xdg-open and kde-open only and remove everything else?

That's the same as using "new KRun", which is what kde-open calls :-)
But that will open an image viewer.

> Why is there a need to do a preferred service [for text/html] 

to get a webbrowser, not an image viewer.

> and/or the "BrowserApplication" setting look ups ? 

Because that one is defined as "the application where all http urls should be 
opened", for people who want all their http urls in firefox (that's how Waldo 
implemented this, on purpose, long ago, and that's what the componentchooser 
says about this setting).
So here again: to get a webbrowser.

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

But "the right thing" in your mind, is opening an image viewer, for a PNG, and 
that's exactly NOT what invokeBrowser should do. That's what kde-open/KRun do.

[Note that KRun also honours BrowserApplication if set, for all http urls, so 
these types of users are covered too.]

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

Yep. However it would actually be correct here, since it would also fulfill the 
contract where "invokeBrowser starts a webbrowser". Except that this time, 
konqueror would show an imageviewer part. The only trouble here is that it 
assumes that all webbrowsers can show non-html files embedded, and while this 
is true of konqueror and iirc firefox, I wonder if e.g. rekonq can do that?

To conclude:

* If most browser can "handle almost anything", then OK, people can expect 
invokeBrowser to work with image urls, and we should do the hack 
(kfmclient_html is just an optimization after all, I can't see how this would 
break in the future (famous last words)).

* If some browsers can't handle image urls, or urls to other kinds of 
documents (PDF, etc.), then konversation shouldn't use invokeBrowser on random 
urls.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).




More information about the kfm-devel mailing list