Shouldn't purple-url-handler start pidgin if it is not running?

[Richard Laager]

On Sun, 2009-01-25 at 23:08 +0100, Hib Eris wrote:
>  1. The g_info_app_launch_default_for_uri cannot detect errors in a
> helper application after the helper launched successfully. Therefore
> any errors should be dealt with 
>       in an appropriate manner by the helper application.

I'd rather that it check the exit code on the helper app and
(asynchronously) return that status (to a callback). That said, fixing
that now would surely be a compatibility nightmare.

> If it decides to call the handler it wants pidgin to be started.

First, I don't think applications should be making any decisions about
such things. If the user clicks the URL, they should call the
appropriate function to deal with it. Second, if you step back from the
problem at hand and go back to your description of what happens, you'll
see that Gnumeric doesn't even know that this will open Pidgin. It
doesn't even necessarily care about the type of the URL at all. In
Pidgin (under GNOME), for example, we linkify all URLs with schemes
listed in GConf and fire gnome-open on them when clicked. We don't know
anything about what is going to actually happen to handle them.


There are two problems with autostarting a libpurple client. The one
previously stated is that starting up Pidgin can result in, for example,
ten accounts being signed on to open one chat room. A possible solution
to this would be to make the Exec line in the .service file pass -n to
avoid signing on any accounts. Then, purple-url-handler would check to
see that the appropriate account was signed on, connecting it if need
be, before calling (in this case) serv_join_chat().

The second problem is... which libpurple client do you sign on? Do you
start up Pidgin, or Finch? If Finch, you're going to have to start it
under some sort of X terminal for it to work. I would suggest the
following solution:
     1. Create a proper .desktop file for Finch.
     2. Have Pidgin and Finch save their .desktop file in a pref at each
        startup.
     3. Create some small script that parses the prefs file, finds the
        last run client, and launches its .desktop file using the
        appropriate command-line utility (if one exists). If there is no
        such utility, we'd have to parse the .desktop file and perform
        the proper action.
     4. Put that script in the DBus .service file as the Exec line.

If you want to combine these two fixes to address both problems, you'd
probably have to create another .desktop file for Pidgin (& Finch) that
starts it offline.

All that said, I believe that Daniel was talking about wanting to
replace purple-url-handler with something that just called our internal
URL handling code (which I think we have somewhere for parsing URLs on
Windows?). If that were done, you could avoid the account-sign-on
modification to purple-url-handler (making it in internal code, if
necessary) and also do something to handle the case of not having an IRC
account for that server. Ideally, I'd like to see some prompt asking if
one should be added.

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20090125/fc637f6d/attachment.sig>