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