GNOME Bugzilla – Bug 522483
use gtk_show_uri() instead of calling firefox directly
Last modified: 2009-08-08 13:33:31 UTC
Please describe the problem: I think that gimp should use the default browser chosen by user instead of firefox. For example, I use epiphany as default, and much more other apps use it without needing to change its configuration. For now I am using "xdg-open" from xdg-utils for this. Steps to reproduce: 1. Open About dialog 2. Click on "Visit de GIMP website" 3. Actual results: Expected results: Does this happen every time? Other information:
Using xdg-open indeed sounds like the right thing to do. We just need to check its availibility and maybe fallback to firefox.
I suggested that before. However the problem is how to check for the availability of xdg-open? It might be better to wait for gtk_show_uri() to land in GTK+, see bug #514396.
What the heck, let the distributors deal with this. xdg-utils should become a dependency for GIMP 2.6. If a distributor doesn't like this, they can easily patch GIMP. 2008-03-18 Sven Neumann <sven@gimp.org> * app/config/gimpguiconfig.c (DEFAULT_WEB_BROWSER): changed default web-browser to xdg-open. Fixes bug #522483.
Thanks a lot :-)
gimp [current svn] gives me a text-based browser, w3m. Under preferences one can set the desired browser for the help system. Now that xdg-open %s gave me this silly w3m, I tried the GIMP help browser. Unfortunately that is not very stable. One gets lots of annoying Unhandled property: 51 letter-spacing Unhandled property: 93 text-transform complaints (it is easy to shut these up by editing gtkhtml2:cssmatcher.c) [already reported in http://bugzilla.gnome.org/show_bug.cgi?id=158867] and under gimp-2.4.5 I saw /usr/lib/gimp/2.0/plug-ins/helpbrowser: fatal error: Segmentation fault so far not reproducible. Going back, I can of course replace xdg-open %s by firefox %s and all will be well. I checked what Ubuntu did, and they have (web-browser "sensible-browser %s") in gimprc. That also works fine. Finally I wondered why anybody would prefer xdg-open. The man page says optimistically that xdg-open will use the browser preferred by the user, but does not reveal what mechanisms the user is supposed to use in order to indicate a preference. Certainly w3m was not my preference. Perhaps xdg-open assumes GNOME or KDE? (I use neither.) At first sight the change from firefox to the obscure xdg-open seems a regression.
For most of our users it's an improvement. If it isn't for your desktop of choice, then please ask the developers of your desktop to improve the situation.
Gimp help needs a browser capable of showing images, but there is no mime type "text-with-images/html". Some users indicate their preference via the BROWSER environment variable, but xdg-open does not look at it. However, sensible-browser does. I see that xdg-open (as installed here on Linux Ubuntu HH) uses sensible-browser for non-local URLs, and asks run-mailcap for local URLs. And run-mailcap finds in /etc/mime.types that a .html file is probably of type text/html, and then in /etc/mailcap that w3m is a program that handles text/html. Solution for the user: create a file .mailcap with a line "text/html; firefox '%s'" or: add a line (web-browser "sensible-browser %s") to gimprc or: go to Edit->Preferences->Help System and choose the desired browser. So, for a user this is not very difficult to fix, but by default gimp comes with not very helpful help. That is bad, for a help system. It could be that sensible-browser is a better choice than xdg-open, but I have no idea about how well-distributed it is. (Since xdg-open here uses it, maybe it is at least as well-distributed.) As a side remark: if some random browser is chosen as the default, then there is always the possibility that the exec fails. In plug-ins/common/web-browser.c line 142 is a line "Please specify ...". That is good. It means that if no default at all was given the user is pointed to the preferences dialog. On the other hand, if the exec fails, there is just the message "could not exec" (line 174). Maybe the same line should be added here, to point the user to the preferences dialog.
(In reply to comment #5) This is an ubuntu problem, xdg-utils works as expected in other distributions like mandriva and gentoo. Maybe this is the cause of ubuntu being using "sensible-browser" instead of "xdg-open". xdg-open works as expected in other distributions. I think that you should send a bug against xdg-utils provided in ubuntu. Anyway ubuntu already patches its gimp for using sensible-browser instead. (I don't know why ubuntu uses "sensible-browser" instead of xdg-utils that are more commonly used, anyway seems that its xdg-utils package has a problem)
Maybe this could be related with: https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/220765
> This is an ubuntu problem, xdg-open works as expected in other distributions I think the Ubuntu xdg-open is unchanged from Debian. So, most likely Debian will see precisely the same problems.
I am afraid that we have to revert that change and close this report as WONTFIX. xdg-open just doesn't do the right thing for file: URIs. It will use the text editor to open local HTML files. Unless that is fixed, we will continue to use firefox as the default browser: 2008-06-10 Sven Neumann <sven@gimp.org> * app/config/gimpguiconfig.c (DEFAULT_WEB_BROWSER): reverted change for bug #522483. 'xdg-open' doesn't do the right thing for file: URIs.
Thanks for reporting the problem. I have reproduced it but seems a gnome-open problem instead of "xdg-utils" one (gnome-open file.html also fails and "kfmclient exec file.html" works as expected) I have opened a bug for it (I think that gnome-open is part of libgnome, if I am wrong please let me know) Can you please keep this bug opened depending on bug #537563 for re-reverting the changes when it is fixed (if it's fixed of course) ? Thanks a lot
Hi again! I think that the problem is because gnome handles text/html files in a different way of remote urls, this way, if you right click on local html file and change it for opening with a web browser , text/html files are opened with it (for example, I think that http://bugzilla.gnome.org/show_bug.cgi?id=518994 is also related with this issue) In what situation does gimp use web-browser for opening *local* html files ? Maybe a workaround could be make a tiny script that would run command: basename "`gconftool-2 --get "/desktop/gnome/url-handlers/http/command"`" "%s" This would output default browser if gnome desktop is detected with: if [ x"$GNOME_DESKTOP_SESSION_ID" != x"" ]; then ... And xdg-open if not. The problem is that I don't know how to make a script that reads for input and appends it to " basename "`gconftool-2 --get "/desktop/gnome/url-handlers/http/command"`" "%s"" output :-(
Opening local HTML files is the main use of the web-browser in GIMP. It is used for context help when the user prefers the web browser over the help browser plug-in. This is not so uncommon. I don't want to see hacks and workarounds for this in GIMP. Let's wait until bug #537563 is fixed.
Seems that gnome-open is deprecated per: http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp Are you ok with changing summary accordingly? Or gimp-2.6 won't use >=gtk+-2.13.1 ?
Of course we are not going to release GIMP 2.6 with a dependency on an unstable GTK+ release. And even if GTK+ 2.14 is released over the next days, we are not likely going to depend on that. It's a little too late for that now. Let's put this on the milestone for 2.8.
As a first step I have now applied the change of the default web-browser to 'xdg-open' again. But we should actually check if we can use gtk_show_uri() directly wherever the web-browser procedure is used now.
Created attachment 140184 [details] [review] 0001-Bug-522483-use-gtk_show_uri-instead-of-calling.patch Like this? At least on Fedora 11, gtk_show_uri() launches Firefox for both file:// and http:// URIs. Bug 522483 – use gtk_show_uri() instead of calling firefox directly Obsolete the web-browser gimprc setting and use gtk_show_uri() in the web-browser plug-in instead.
Your patch doesn't mark the web-browser property as COMPAT. Other than that, it is a step in the right direction. But I think we should go further and remove the web-browser plug-in entirely and use gtk_show_uri() directly. The core can provide the 'web-browser' prodecure for backward compatibility.
I've commited the below patch (split in two). Seems like quite a bit of work to go all the way and I'm not sure it would be worth it. We should keep this open and investigate if we can enable gtk_show_uri() in Windows though. commit 29d9a94fd0b8124dccc8980309de78ef1336f8b2 Author: Martin Nordholts <martinn@src.gnome.org> Date: Sat Aug 8 15:16:12 2009 +0200 Bug 522483 – use gtk_show_uri() instead of calling firefox directly Use gtk_show_uri() instead of g_spawn_async() on a browser. plug-ins/common/Makefile.am | 4 ++ plug-ins/common/web-browser.c | 104 ++++------------------------------------- 2 files changed, 13 insertions(+), 95 deletions(-)
Appearently gtk_show_uri() doesn't work on win32 yet, g_win32_app_info_launch_uris() contains g_set_error_literal (error, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED, _("URIs not supported")); So let's close this as FIXED. The problem originally reported should be solved now.