Make purple_blist_load() static (#3288) - necessary?

Evan Schoenberg evan.s at dreskin.net
Sun Mar 9 14:13:16 EDT 2008


On Mar 9, 2008, at 12:29 AM, Jay Goel wrote:

> This patch changes the way purple_blist_load() works, and the
> ticket+patch outline that pretty clearly. But this raises the  
> question:
> are these good/necessary changes to make?
>
> (let me know if i should describe the patch more thoroughly here)
>
> Pros:
>
> Clients implementing libpurple have fewer oddball things to do before
> using the client. That is, both pidgin and finch (or the nullclient)
> have to make the following calls after calling purple_core_init():
>
> purple_set_blist(purple_blist_new());
> purple_blist_load();
>
> This is, well, an extra step, and there is no need to require UIs to
> perform this task. Particularly because those functions are modifying
> global/static variables; I mean, it doesn't exactly make sense for
> someone to call purple_blist_load(), as it depends on the side  
> effect of
> the previous set_blist functions.

I would be okay with this being done automatically, but I do not think  
that it should happen within blist_init().  The UI has had no chance  
to perform its own initialization or to associate any of its data with  
libpurple structures.  This means that the flood of information from  
loading the blist (buddies added to groups, aliases set, etc. as  
blist.xml is loaded) may have nowhere to go.

I think that a second call into the blist module should be made after  
ops->ui_init() is called, along the lines of blist_finish_initing().   
Seem reasonable?

Thanks for bringing this up on-list.

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080309/21eb832c/attachment.html>


More information about the Devel mailing list