mimetype problems...

[Dawit A]

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

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

Right. I meant KRun in general...

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

I now understand the reason behind doing those look ups, but here is where
the problem starts. The behavior of invokeBrowser is completely different
depending on whether or not the KDE_FULL_SESSION environment variable is set
and a a preferred service that handles text/html or a user specified
BrowserApplication config option could be found. If these criteria are not
met for one reason or another, then invokeBrowser resorts to opening an
image viewer or whatever application is associated to handle the specified
content. That is at least inconsistent, no ?


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

Not really. I have no problem with the image being embedded in the browser
shell (kparts) so long as the request is correctly handled as an image in
this particular case or the correct content-type in the general.


>
> [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?
>

Neither rekonq or konqueror+kwebkitpart or any other kdewebkit browsers for
that matter will show this bug since it is not possible to tell QtWebkit to
use a pre-determined mime-type. IOW, it will unfortunately do the look up
again and as a result obtain the correct mime-type. A double look up we
cannot really do anything about, at least not one I can think of. At least
with the kfmclient fix, it is doing two instead of three look ups for this
kind of cases...


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

Ah... if I count the the many famous last words, I have to take back.. :)


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


Well since we are brain storming, I have another possible solution or
suggestion for consideration. Why not add another desktop file like
"kfmclient_html.desktop" with a lower initial preference and a specific
constraint to be used from invokeBrowser ? That way the
KMimeTypeTrader::self()->preferredService call can be changed to
KMimeTypeTrader::self()->query to take advantage of the constraint parameter
? Would not such a solution be fitting in this case ? If not, then what you
suggest it is the best option we have...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20110120/8ae9d225/attachment.htm>