--0015175caaf6643212049a4f5c63 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 20, 2011 at 2:39 PM, David Faure 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... --0015175caaf6643212049a4f5c63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 sim= ply document the
> behavior invokeBrowser and force application developers to do the righ= t
> thing, i.e call the appropriate KRun method, e.g. runUrl, when they ar= e not
> sure that the url is actually html page.

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

Right. I meant KRun in general...=C2=A0

> 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.=C2=A0

> 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 u= rls 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 componentch= ooser
says about this setting).
So here again: to get a webbrowser.

I n= ow understand the reason behind doing those look ups, but here is where the= problem starts. The behavior of invokeBrowser is completely different depe= nding on whether or not the=C2=A0KDE_FULL_SESSION environment variable is s= et and a a=C2=A0preferred service that handles text/html or a user specifie= d BrowserApplication config option could be found. If these criteria are no= t met for one reason or another, then invokeBrowser resorts to opening an i= mage viewer or whatever application is associated to handle the specified c= ontent. 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 browse= r
> using the default app chooser from the system settings.

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

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

[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 &qu= ot;if the
> > preferredService for text/html is kfmclient_html.desktop then use=
> > kfmclient.desktop instead". This would work. It just puts ba= ck a special
> > case
> > for konqueror into invokeBrowser which the last change made final= ly
> > generic...
>
> Though sometimes necessary I really dislike exceptions like this optio= n,
> specially since such hacks have a nasty habit of coming back to bite u= s at
> some point down the road...

Yep. However it would actually be correct here, since it would also f= ulfill the
contract where "invokeBrowser starts a webbrowser". Except that t= his time,
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 th= is
is true of konqueror and iirc firefox, I wonder if e.g. rekonq can do that?=

Neither rekonq or konqueror+kwebkitpar= t 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 corr= ect mime-type. A double look up we cannot really do anything about, at leas= t 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...
=C2=A0
To conclude:

* If most browser can "handle almost anything", then OK, people c= an 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.. := )
=C2=A0

* 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 h= ave another possible solution or suggestion for consideration. Why not add = another desktop file like "kfmclient_html.desktop" with a lower i= nitial preference and a specific constraint to be used from invokeBrowser ?= That way the KMimeTypeTrader::self()->preferredService call can be chan= ged to KMimeTypeTrader::self()->query to take advantage of the constrain= t parameter ? Would not such a solution be fitting in this case ? If not, t= hen what you suggest it is the best option we have...

--0015175caaf6643212049a4f5c63--