[Adium-devl] MSNp15 (libpurple im.pidgin.pidgin) in Adium 1.3.x

[John Bailey]

On Thu, Sep 11, 2008 at 12:08:40PM -0400, Evan Schoenberg wrote:
> A big part of the problem comes from the fact that Adium can expect  
> virtually nothing (including libpurple itself) to be installed  
> systemwide; it therefore comes down to a build system problem. Adium  
> links the shipped prpls in statically, and static external loading is  
> much more problematic from a versioning and access standpoint than  
> dynamic. It would increase binary size to switch to dynamic plugins  
> but I'd be okay with that.

Static external loading isn't strictly necessary for a purely libpurple
plugin, although the alternatives are a bit more complicated for the
person building the plugin.  Since libpurple provides its own plugin
system, which last I checked *does* actually work on OS X, this could be
leveraged to your advantage.  The trick would then be getting things set
up so that libpurple would load the plugin.  This is probably in the
short term much more trouble than it's worth.  If I ever finish the 5 or
so Pidgin and libpurple projects I'm currently working on, I might take
a look at trying this.

> I'm an idiot today; sorry. We fully implement the request and notify  
> APIs, though there might be some aspects of the Request Field part  
> which need expansion (I'm not sure if the table part, for example, has  
> been written or tested offhand).

I'm not aware of any plugins that actually use the full extent of the
request API, but some request fields are fairly important to
plugins--the account selection one, for example.  The problem here is
that since Adium isn't *just* a libpurple UI, accounts for non-libpurple
protocols wouldn't appear here and wouldn't work correctly even if they
did.

> Then we're okay. This really comes down to build system problems,  
> then, so long as the preferences aspect isn't needed.

I'm sure there are a fair few plugins that would use the pluginpref
API, so this would probably be further complication.

> That's basically what I was implying. Any UI •could• be generated  
> programatically, but doing so for any but the very simplistic of  
> dialogues is difficult. The request fields api, for example, is  
> implemented but looks out of place, as it is presented via an HTML  
> form in a web widget.

Ouch.  It sounds like I should be greatful I don't mess with UI on OS X
then.

John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080911/a171ba9c/attachment.sig>