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 Just Working
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 gaim-remote <LSchiere2> off hand, it doesn't provide --help <warren> Should apps try to interface with gaim directly via dbus? <LSchiere2> yes
At present gnome/firefox needs a command line executable for protocol handling (like aim:) 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- url-handler)
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.