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

[Evan Schoenberg]

On Sep 11, 2008, at 10:29 AM, John Bailey <rekkanoryo at rekkanoryo.org>  
wrote:

> Evan Schoenberg wrote:
>> Adium is not Pidgin for Mac OS X.
>
> Of course it isn't.  I realize Adium also isn't strictly a libpurple  
> UI, but it
> *is* a libpurple UI nonetheless.  As a libpurple contributor at the  
> time, I
> expected that libpurple plugins (which by definition may not use any  
> specific
> UI) would work, and was surprised a couple years ago when I found  
> that they don't.

It's be nice if they did.

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.




>
>
>> Here's the problem: we could probably say, "a libpurple plugin which
>> requires no UI presentation except Account or Buddy actions and
>> requires no configuration can be loaded directly" if someone could  
>> wok
>> out how to perform such linkage dynamically (which I don't know how  
>> to
>> do but wouldn't be averse to). However, as far as I know, this
>> excludes the vast majority of plugins.
>
> It would exclude the majority of useful plugins, yes.  For example,  
> the
> ListHandler plugin I mentioned requires the Request API to be  
> implemented in the UI.

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).

The Preferences part is the only UI component I canthink of on further  
reflection which is not supported.. And which would be difficult to  
support.


> A protocol plugin, on the other hand, should be using very little if  
> any of the
> things Adium doesn't currently implement.  Protocol plugins have a  
> specific type
> flag set which can be used when probing to ignore other plugins if  
> desired.
> Granted, since libpurple provides the ability to have account  
> options specified
> by the prpl, this complicates matters.  I believe the HTTP method  
> checkbox
> that's been discussed recently is provided in such a manner

A whole bunch of dynamic class creation magic - magic over my head at  
present - would be needed to generate subclasses of the required Adium  
classes  (AIService, AIAccount, etc) to hook a libpurple prpl in  
without any Cocoa glue code. The glue, however, requires no more  
coding skill than duplicating and renaming files then running a  
find&replace.


>
>
>> If you or someone else can write code to build whatever preferences
>> and presentation UI hooks and generators a libpurple plugin expects
>> without tying us to Pidgin's interface, that'd be awesome. We also
>> need some way to version such plugins against libpurple
>> (which .AdiumLibpurplePlugin bundles also need, for that matter). As
>> it stands, though, we simply couldn't provide an acceptable user
>> experience. Patches, as they say, welcome.
>
> The Request and Notify APIs can be implemented in the UI however  
> anyone chooses,
> whether they be a thin wrapper that just assembles a simple dialog  
> or something
> much more complex.  There's no tying to Pidgin's or Finch's UI,  
> although the API
> does somewhat resemble our toolkits' capabilities.  These two APIs  
> represent the
> bulk of the existing libpurple plugins that Adium users might find  
> useful.

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


>
>
> I get the impression that you're saying it's impossible for an  
> application to
> generate a UI programmatically with OS X's toolkit.  Am I reading  
> too much into
> this?
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.

-Evan

>
>
> All this said, if someone cared to write the necessary Adium glue  
> for any of my
> plugins, I certainly wouldn't be stupid enough to turn them down.   
> It's just not
> an endeavor I wish to undertake myself.
>
> I also get that no one is currently interested in making libpurple  
> plugins work
> properly in Adium (this was made *quite* clear in #adium-devl when  
> the previous
> discussion took place).


>
>
> John
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com