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