GNOME Bugzilla – Bug 534225
Url in conversations don't open
Last modified: 2008-07-29 21:14:23 UTC
Please describe the problem: When you clic on a url in a conversation or in the "about" box, an error box is opened with this message : unable to open uri opération non prise en charge Steps to reproduce: 1. clic on a web link (url) Actual results: a dialog box is open with this error message : unable to open uri opération non prise en charge Expected results: open the url in the default web browser (on my pc, the default one is iceweasel -> configured in gnome-default-applications-properties) Does this happen every time? yes it does Other information:
it works here. Empathy uses GIO to open links, it should just work. I suspect your system to be badly configured.
Nicolas, could you tell use which versions of Empathy, glib, gio and gtk+ you are using?
Since this bug, I reinstalled from scratch my OS (debian Lenny) for some other reasons. Since that, links are opened correctly in my default web browser. Maybe one of the application or lib you quoted was not up to date.
Created attachment 114312 [details] [review] Implemented gtk_show_uri in empathy_url_show. This also happens to me. Looking at the source of empathy_url_show, I see this comment: > /* FIXME: this does not work for multihead, we should use > * GdkAppLaunchContext or gtk_show_url, see bug #514396. > */ I am indeed using dual-head. I have created a patch that uses gtk_show_uri and it changes empathy_url_show to accept a GdkScreen argument, but haven't actually tested it yet as gtk_show_uri isn't in stable GTK+ yet. Empathy HEAD currently builds fine with stable GTK+, and I think it would be unwise to lose this. That sounds reasonable, doesn't it? Anyway, I have the patch in my show-uri branch of git://git.collabora.co.uk/git/user/jonny/empathy.git and have attached it to this comment. This comment is mainly for the record, and to give a status update.
I think that's the way to go. However we can't use that API until GTK 2.14 get released and included in most distro... I think we could just copy/paste the code of that func from GTK with a FIXME pointing to this bug report. Also, in chat_view_url_event_cb() you can give the view as user_date. Like that you can give the screen using gtk_widget_get_screen. Same for chat_view_open_address_cb(), you can get the url from the menu widget because there is a g_object_set_date with it. In link_button_hook() you can get the screen of the button. Otherwise it seems OK to me.
(In reply to comment #5) > I think that's the way to go. However we can't use that API until GTK 2.14 get > released and included in most distro... I think we could just copy/paste the > code of that func from GTK with a FIXME pointing to this bug report. The code for that function can't be pasted into Empathy as GdkAppLaunchContext is only in unstable GTK. This looks like we just have to wait, right? > Also, in chat_view_url_event_cb() you can give the view as user_date. Like that > you can give the screen using gtk_widget_get_screen. Done. > Same for chat_view_open_address_cb(), you can get the url from the menu widget > because there is a g_object_set_date with it. I moved the g_object_set_data from the menu shell to the specific menu item as the url wasn't being used anywhere else. > In link_button_hook() you can get the screen of the button. Done. Okay, I updated my branch. I still haven't tested this as I am not running unstable GTK+, for the above reasons, unless I am being silly and misunderstanding this? :-)
Thanks. It's good to have the patch ready, we can test and commit it when GTK get released.
In Debian, this bug can be fixed by installing the gvfs-backends package, which includes an implementation of the GDesktopAppInfoLookup interface.