Red Hat Bugzilla – Bug 172759
gaim-remote plugin not on by default
Last modified: 2007-11-30 17:11:16 EST
When you click on an aim: link, the browser gives you a warning dialog about
launching an external application. After you say "OK, proceed anyway" then
gaim-remote just prints errors silently to the console because the remote plugin
isn't active. If you turn on the plugin then aim: links work fine, after you've
OK'd them via the browser's warning dialog.
Should be fixed by just enabling the plugin by default, since in a Fedora
context at least we can probably say it will always work.
Or at least the gaim-remote error should go in a dialog, though I think
a "please go turn on the plugin" dialog is substantially less helpful than
gaim-remote seems to be broken in gaim-2 currently. Need upstream assistance.
<warren> LSchiere2, so gaim2 doesn't provide a /usr/bin/gaim-remote in order to
maintain compatibility with older apps that knew of that command?
<LSchiere2> I currently don't have a working gaim-remote.py (ImportError: No
module named dbus when I try to run it), I think that's my fault
<LSchiere2> but anyway, there was some talk of changing the name from
gaim-remote.py to simply gaim-remote
<LSchiere2> I'm not sure all the syntax is 100% the same though anyway
<LSchiere2> the cause of the above error is that even when I point gaim to
python manually (because /usr/bin/python is 2.3), the gaim-remote.py still ends
up with #!/usr/bin/python
<LSchiere2> so yeah, the interface it provides isn't 100% the same as the older
<LSchiere2> off hand, it doesn't provide --help
<warren> Should apps try to interface with gaim directly via dbus?
At present gnome/firefox needs a command line executable for protocol handling
Epiphany and Firefox could of course be modified to special-case use the gaim
dbus interface, but it would take a long time to get out there.
A simple command line app that fired off the "handle aim:" dbus message would
be all that's required. In fact the Mugshot sources have an example (mugshot-
There isn't likely to be a dialog in the current version, because it has no X11
code whatsoever. The upside of this is that writing a client to do the aim:goim
type stuff is *very* easy now, and there is no reason that browser plugins or
DE-specific interfaces or what-have-you could not be written in just a few lines
of code. For example, gtk-gaim-remote using a Gtk+ interface to present d-bus
errors to the user would probably add only a few dozen lines of python (if that,
really) to the existing gaim-remote. This isn't on our list of things to do,
but it's not a horrible idea so I'll poke it around ... gaim-remote itself will
remain X11-UI-less, of course. We would also accept a "prettier" remote
interface as a patch. :-)
Turning the gaim-remote interface on should no longer be required in the Gaim
2.0.0 betas, as we now use a D-bus interface which should be always available
provided that Gaim is compiled with D-bus support. Is it possible that you do
not have D-bus support in your binaries?
(Note that I read the comments in the wrong order above, as I'm used to the sf
bugracker, so I now see that you all understand what's going on. My bad. :-)
This is no longer relevant, closing WONTFIX. Software will need to interface
pidgin via dbus from now on.