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

Mark Doliner mark at kingant.net
Wed Mar 12 03:17:12 EDT 2008


I agree with Evan on this.  I think it's better to continue calling
purple_blist_init() in before ui_init(), and then add a second function
specifically for loading the blist and call it after ui_init().

(I just left a confusing comment on the ticket saying the same thing)

-Mark

On Sun, 09 Mar 2008 21:41:50 -0400, Jay Goel wrote
> That makes sense; in fact, if ui_init() is not called first, then 
> pidgin will segfault.
> 
> However, the patch actually changes when the blist is initialized. 
> libpurple/core.c now looks like:
> 
> purple_core_init(const char *ui)
> {
>    /* lots of code */
> 
>    /*
>     * We need to initialize the UI before trying to create the buddy 
> list.    */   if (ops != NULL && ops->ui_init != NULL)     ops-
> >ui_init();
> 
>    purple_blist_init();
> 
> }
> 
> (a bit of an eyesore, but that problem is taken care of - unless I 
> have missed the mark?)
> 
> Jay
> 
> Evan Schoenberg wrote, On 03/09/2008 02:13 PM:
> >
> > 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?




More information about the Devel mailing list