[Pidgin] #3288: Make purple_blist_load() static

Pidgin trac at pidgin.im
Fri Mar 7 15:45:20 EST 2008


#3288: Make purple_blist_load() static
--------------------------+-------------------------------------------------
  Reporter:  MarkDoliner  |       Owner:  MarkDoliner
      Type:  task         |      Status:  new        
  Priority:  blocker      |   Milestone:  3.0.0      
 Component:  libpurple    |     Version:  2.2.0      
Resolution:               |    Keywords:             
   Pending:  0            |  
--------------------------+-------------------------------------------------
Comment (by raschermg):

 == This patch makes the following changes: ==

 1. Removes calls to the following functions from UIs: purple_set_blist(),
 purple_blist_new(), purple_blist_load()

 2. Placed above calls into purple_blist_init()

 3. Renamed purple_blist_load() to load_blist() and made it static.

 4. Basically "stubbed" purple_blist_init() in order to make the binary
 compatible with microversions, etc.

 5. Changes when purple_blist_init() is called. This change calls it after
 calling ui_init()

 == Potential Issues ==

 The only problem (which I don't think is a problem, I will explain) is
 with #5 above - the order in which the buddylist is loaded.

 Prior to this patch, the process of loading the buddy list looked
 something like this (roughly!)

 {{{
 init_core() ->
 init_blist() /* which loads a bunch of signals */ ->
 ui_init() ->
 set_blist, blist_load
 }}}

 That is, the init_blist() only set up signals. Then, after the UI was
 inited, blist_load would populate the buddy list from the xml file.

 Now, however, the order looks like this:

 {{{
 init_core() ->
 ui_init() ->
 init_blist() /* which loads a bunch of signals, in addition to set_blist
 and blist_load */
 }}}

 '''The only issue is this''': Mark mentioned that it is preferable to have
 the signals initialized before initing the gui. Quote, "It's important
 that the signals are registered before the ui tries to do stuff"

 '''However, I do not think this is a problem.''' After ui_init is called,
 pidgin goes through a lot of other stuff before even putting the blist
 onto the screen. Which means that the ui isn't really "trying" to do
 anything, because the ui doesn't really exist until much later in the
 process. (to be honest: I don't understand gtk/related code enough to make
 but a semantic argument, but when stepping through this in gdb, while the
 signals were being registered, it was not until much later that there was
 actually a UI to make use of them.)

-- 
Ticket URL: <http://developer.pidgin.im/ticket/3288#comment:3>
Pidgin <http://pidgin.im>
Pidgin


More information about the Tracker mailing list