[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: mimetype problems...
From: Dawit A <adawit () kde ! org>
Date: 2011-01-20 23:19:09
Message-ID: AANLkTinAx6Jq4rFei0reZpf-4iHiUAYUMxfMvnNNQxwd () mail ! gmail ! com
[Download RAW message or body]
On Thu, Jan 20, 2011 at 2:39 PM, David Faure <faure@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...
[Attachment #3 (text/html)]
<div class="gmail_quote">On Thu, Jan 20, 2011 at 2:39 PM, David Faure <span \
dir="ltr"><<a href="mailto:faure@kde.org" \
target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div>On Thursday 20 January 2011, Dawit A wrote:<br>
</div><div>> My original reaction when I discovered the issue was to simply \
document the<br> > behavior invokeBrowser and force application developers to do \
the right<br> > thing, i.e call the appropriate KRun method, e.g. runUrl, when \
they are not<br> > sure that the url is actually html page.<br>
<br>
</div>runUrl is for when the mimetype is known, the right way when one wants to \
just<br> "open a URL which could be anything" is: new \
KRun(url).<br></blockquote><div><br></div><div>Right. I meant KRun in general... \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div><br>
> After all invokeBrowser does exactly what its namesake suggests!<br>
<br>
</div>This is very true. It should open a webbrowser.<br>
Which means: not an image viewer. Read on...<br>
<div><br>
> so why not simply use xdg-open and kde-open only and remove everything else?<br>
<br>
</div>That's the same as using "new KRun", which is what kde-open calls \
:-)<br> But that will open an image viewer. </blockquote><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br>
> Why is there a need to do a preferred service [for text/html]<br>
<br>
to get a webbrowser, not an image viewer.<br>
<div><br>
> and/or the "BrowserApplication" setting look ups ?<br>
<br>
</div>Because that one is defined as "the application where all http urls should \
be<br> opened", for people who want all their http urls in firefox (that's \
how Waldo<br> implemented this, on purpose, long ago, and that's what the \
componentchooser<br> says about this setting).<br>
So here again: to get a webbrowser.<br></blockquote><div><br></div><div>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 ?</div> \
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br> > From my tests, \
calling either xdg-open or kde-open seems<br> > to do the right thing, even when \
the user overrides the default browser<br> > using the default app chooser from \
the system settings.<br> <br>
</div>But "the right thing" in your mind, is opening an image viewer, for a \
PNG, and<br> that's exactly NOT what invokeBrowser should do. That's what \
kde-open/KRun do.<br></blockquote><div><br></div><div>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.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[Note that KRun also honours BrowserApplication if set, for all http urls, so<br>
these types of users are covered too.]<br>
<div><br>
> > d) I can only think of a hack in invokeBrowser that would say "if \
the<br> > > preferredService for text/html is kfmclient_html.desktop then \
use<br> > > kfmclient.desktop instead". This would work. It just puts back \
a special<br> > > case<br>
> > for konqueror into invokeBrowser which the last change made finally<br>
> > generic...<br>
><br>
> Though sometimes necessary I really dislike exceptions like this option,<br>
> specially since such hacks have a nasty habit of coming back to bite us at<br>
> some point down the road...<br>
<br>
</div>Yep. However it would actually be correct here, since it would also fulfill \
the<br> contract where "invokeBrowser starts a webbrowser". Except that \
this time,<br> konqueror would show an imageviewer part. The only trouble here is \
that it<br> assumes that all webbrowsers can show non-html files embedded, and while \
this<br> is true of konqueror and iirc firefox, I wonder if e.g. rekonq can do \
that?<br></blockquote><div><br></div><div>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...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> To conclude:<br>
<br>
* If most browser can "handle almost anything", then OK, people can \
expect<br> invokeBrowser to work with image urls, and we should do the hack<br>
(kfmclient_html is just an optimization after all, I can't see how this would<br>
break in the future (famous last words)).<br></blockquote><div><br></div><div>Ah... \
if I count the the many famous last words, I have to take back.. :)</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<br>
* If some browsers can't handle image urls, or urls to other kinds of<br>
documents (PDF, etc.), then konversation shouldn't use invokeBrowser on \
random<br> urls.</blockquote><div><br></div><div>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...</div> <div><br></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic