Sent from the wrong email address originally, so it bounced. Begin forwarded message:
> Date: January 15, 2010 4:43:20 PM CST > To: Felipe Contreras <[email protected]> > Cc: pidgin-devel <[email protected]>, adium-devel <[email protected]>, Will > Thompson <[email protected]>, Devid Antonio Filoni > <[email protected]>, Craig Harding <[email protected]>, Mark Doliner > <[email protected]> > Subject: Re: Workaround for libpurple's lack of set_alias() > > > On Jan 14, 2010, at 6:24 PM, Felipe Contreras wrote: > >> Then the prpl would have to export a set_alias() function (just like >> msn_set_friendly_name()). In case you are wondering if multiple >> plugins's definition of set_alias() would conflict: no; symbols are >> loaded in the local name-space. For example, all plugins export >> 'purple_init_plugin' safely. > > I believe this would break static compilation. When compiling statically, > plugins don't export purple_init_plugin(); they export > purple_init_##x##_plugin() where ##x## is the prpl name. > >> You might wonder: wouldn't it be better to just fix libpurple? And to >> that my answer is: ha! I wouldn't hold my breath. > > This is counterproductive. > >> I'm attaching the >> patch just in case somebody else succeeds in getting it accepted, > > This is highly productive. > >> perhaps by issuing a secret offering to the right god, or maybe by >> nailing the time when developers are not feeling moody. > > This, too, is counterproductive. > > What you're doing in this email remains good for us all - driving development > forward, offering fixes in one hand and potential workarounds in the other. I > love that; thanks. I'd love not to have to read through the ire towards > libpurple developers to get to it. > > Cheers, > Evan
