--0015175caaf6f9f120049a4bfe75 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 20, 2011 at 1:35 PM, David Faure wrote: > > Context: > > In Konversation, post a URL of an image and click on it. > > Konqueror will open and display the image as text. > > On Thursday 20 January 2011, Dawit A wrote: > > Unfortunately, the call to preferred service for "text/html" results in > > "kfmclient_html.destop" being returned and causing this issue due to the > > fixes to kfmclient. Anyhow, I guess the proper fix here would be to > either > > change the initial preference levels in these two desktop files to favor > > "kfmclient.desktop" (*) > > or change the preferredService call to > > KService::serviceByDesktopPath and hard code kfmclient.desktop in > > invokeBrowser. What do you think david ? > > Ah I see. invokeBrowser used to hardcode kfmclient, but I changed it to > "preferred service for text/html" recently (r1208671) because some people > want > to use another kde browser (like rekonq) instead. (Your 2nd suggestion > would > mean basically reverting that change, so that's not a possibility.) > > And your 1st suggestion wouldn't work either: kfmclient.desktop is _not_ > associated to text/html, so it is not found at all by preferredService. > This > is on purpose, since it's the job of kfmclient_html.desktop to be > associated > with text/html. The comment is confusing because it predates r1208671. > Ahhh right. kfmclient.desktop does indeed not have a text/html mimetype association. > > The new invokeBrowser logic leads to a very strange situation indeed, where > we > are calling a service associated to text/html (kfmclient_html.desktop) for > a > URL that is not necessarily text/html (because invokeBrowser is being > abused > for images...), and this breaks the optimization in kfmclient_html where we > pass text/html to save an additional mimetype determination in the cases > where > (unlike invokeBrowser) we already just found out that the mimetype is > text/html! > > Brainstorming about possible solutions: > > a) hardcoding kfmclient and from kfmclient's code calling the > preferred-app- > for-text/html would work fine, but it would still require that konqueror is > installed, even to use rekonq, so in terms of dependencies it's not that > great. > > b) removing text/html from kfmclient_html.desktop would fix invokeBrowser > but > would make every other case slower, since we normally look up the apps for > "text/html" only when we actually do have a text/html URL in the first > place. > > c) so maybe invokeBrowser shouldn't use text/html to find out the preferred > browser, but I can't think of another solution, since we're talking about > the > case where the user changed the app order (to move up rekonq) in the > mimetype > settings (the componentchooser module is not used for this, it's for > choosing > a BrowserApplication (e.g. "all http links in firefox") setup). > 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. After all invokeBrowser does exactly what its namesake suggests! However, realistically speaking, such expectations from developers are not really plausible in practise ; so why not simply use xdg-open and kde-open only and remove everything else ? Why is there a need to do a preferred service and/or the "BrowserApplication" setting look ups ? 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. > 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... --0015175caaf6f9f120049a4bfe75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 20, 2011 at 1:35 PM, David Faure <faure@kde.org> wrote:
> Context:
> In Konversation, post a URL of an image and click on it.
> Konqueror will open and display the image as text.
On Thursday 20 January 2011, Dawit A wrote:
> Unfortunately, the call to preferred service for "text/html"= results in
> "kfmclient_html.destop" being returned and causing this issu= e due to the
> fixes to kfmclient. Anyhow, I guess the proper fix here would be to ei= ther
> change the initial preference levels in these two desktop files to fav= or
> "kfmclient.desktop" (*)
> or change the preferredService call to
> KService::serviceByDesktopPath and hard code kfmclient.desktop in
> invokeBrowser. What do you think david ?

Ah I see. invokeBrowser used to hardcode kfmclient, but I changed it = to
"preferred service for text/html" recently (r1208671) because som= e people want
to use another kde browser (like rekonq) instead. (Your 2nd suggestion woul= d
mean basically reverting that change, so that's not a possibility.)

And your 1st suggestion wouldn't work either: kfmclient.desktop is _not= _
associated to text/html, so it is not found at all by preferredService. Thi= s
is on purpose, since it's the job of kfmclient_html.desktop to be assoc= iated
with text/html. The comment is confusing because it predates r1208671.
<= /blockquote>

Ahhh right. kfmclient.desktop does indeed n= ot have a text/html mimetype association.

The new invokeBrowser logic leads to a very strange situation indeed, where= we
are calling a service associated to text/html (kfmclient_html.desktop) for = a
URL that is not necessarily text/html (because invokeBrowser is being abuse= d
for images...), and this breaks the optimization in kfmclient_html where we=
pass text/html to save an additional mimetype determination in the cases wh= ere
(unlike invokeBrowser) we already just found out that the mimetype is
text/html!

Brainstorming about possible solutions:

a) hardcoding kfmclient and from kfmclient's code calling the preferred= -app-
for-text/html would work fine, but it would still require that konqueror is=
installed, even to use rekonq, so in terms of dependencies it's not tha= t
great.

b) removing text/html from kfmclient_html.desktop would fix invokeBrowser b= ut
would make every other case slower, since we normally look up the apps for<= br> "text/html" only when we actually do have a text/html URL in the = first place.

c) so maybe invokeBrowser shouldn't use text/html to find out the prefe= rred
browser, but I can't think of another solution, since we're talking= about the
case where the user changed the app order (to move up rekonq) in the mimety= pe
settings (the componentchooser module is not used for this, it's for ch= oosing
a BrowserApplication (e.g. "all http links in firefox") setup).

My original reaction when I discovered t= he issue was to simply document the behavior invokeBrowser and force applic= ation developers to do the right thing, i.e call the appropriate KRun metho= d, e.g. runUrl, when they are not sure that the url is actually html page. = After all invokeBrowser does exactly what its namesake suggests! However, r= ealistically speaking, such expectations from developers are not really pla= usible in practise ; so why not simply use xdg-open and kde-open only and r= emove everything else ? Why is there a need to do a preferred service and/o= r the "BrowserApplication" setting look ups ? From my tests, call= ing 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 s= ystem settings.
=C2=A0
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
kfmclient.desktop instead". This would work. It just puts back a speci= al 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 nas= ty habit of coming back to bite us at some point down the road...

--0015175caaf6f9f120049a4bfe75--