Clickable links API

[Kevin Stange]

On 03/28/2011 04:15 AM, Andrew Victor wrote:
> hi,
> 
>> Couldn't you just use the 'uri-handler' core signal instead?
> 
> I had a look at the uri-handler method on Linux.
> 
> 1. You need to register a gnome URL-handler.
>     At startup, Pidgin calls gtk_imhtml_class_register_protocol() for
> all of these.
> 2. When clicking on a link, it causes pidgin/gtknotify.c to spawn a
> Python process (libpurple/purple-url-handler).
> 3. That process sends a DBus message back to Pidgin.
> 
> This mechanism's overhead seems very high, and we'd like a
> cross-platform cross-client solution without all the external
> dependencies.
> I think the URI Handlers are also an optional component on a Windows
> installation of Pidgin.

I think what we're missing is a way for a plugin to register a URI
handler that is processed internally and is UI agnostic.

It seems like uri-handler signals are emitted only by API calls which
can be done by a plugin in its own UI or via an external application
which is the function of the dbus or Windows uri handlers.

Your patch lets prpls handle links clicked in a conversation that is
specific to a particular prpl, but I think perhaps what might be better
is API to register protocols in libpurple so that any plugin can present
a link in the conversation window and make UI or API calls based on the
click.  For example, you can register aim: globally in OSCAR and then an
aim: link in a mxit message would work without having to call an
external application since Pidgin supports the URI internally.

gtkimhtml has its own GTK-only API for registering link handlers which
means this can work only in Pidgin and should not be done from a prpl or
core plugin.

An approach might involve refactoring so that we take
gtk_imhtml_class_register_protocol and/or the uri-handler signals and
convert the functionality into core API and update gtkimhtml to simply
make use of this API (gtk_imhtml_class_register_protocol could simply
use the core API for compatibility, or be removed if held for 3.0.0) and
allow UI, core and protocol plugins to handle their own registrations.

Optimally, conflicting registrations need to be addressed.  We might
want to consider supporting overriding (priorities?) to, for example,
allow a plugin to replace the http:// handler... or maybe we don't want
that.

We could also try to build the functionality around the existing
uri-handler signal and allow it to be emitted via UI links as well as
via purple_got_protocol_handler_uri and just let plugins fight for it.

Kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20110329/9190bc58/attachment.sig>