comparison HACKING @ 10011:32467b63f55a

[gaim-migrate @ 10928] More deprecation of serv_got_update or whatever it's called. Is all the sound and logging stuff done in the new code? I didn't actually check. committer: Tailor Script <[e-mail]>

10010:56e34a659db2

After you're signed in, Gaim draws the buddy list by calling
show_buddy_list. Assuming the user has a buddy list (all buddy list
functions are controlled by list.c; when you sign on do_import is called
and that loads the locally saved list), the protocol calls
serv_got_update, which sets the information in the appropriate struct
buddy and then passes it off to set_buddy.

set_buddy is responsible for a lot of stuff, but most of it is done
implicitly. It's responsible for the sounds (which is just a call to
play_sound), but the biggest thing it does is call new_group_show and
new_buddy_show if necessary. There's only one group_show per group name,

  all of the protocols. It's a pretty simple file actually.

server.c:
  This is where all of the differentiation between the different protocols
  is done.  Nearly everything that's network related goes through here
  at one point or another. This has good things like serv_send_im and
  serv_got_update. Most of it should be pretty self-explanatory.

sound.c:
  The main function in this file is play_sound, which plays one of 8
  (maybe 9?) sounds based on preferences. All that the rest of the code
  should have to do is call play_sound(BUDDY_ARRIVE), for example, and

Now then, there are protocols that gaim knows about. Each protocol is
in a prpl struct and kept track of in the protocols GSList. The way the
management of the protocols is, there will only ever be one prpl per
numeric protocol. Each prpl defines a basic set of functions: login,
logout, send_im, etc. The prpl is responsible not only for handling
these functions, but also for calling the appropriate serv_got functions
(e.g. serv_got_update when a buddy comes online/goes offline/goes
idle/etc). It handles each of these on a per-connection basis.

So why's it called a PRPL? It stands for PRotocol PLugin. That means
that it's possible to dynamically add new protocols to gaim. However,
all protocols must be implemented the same way: by using a prpl struct
and being loaded, regardless of whether they are static or dynamic.

10011:32467b63f55a

After you're signed in, Gaim draws the buddy list by calling
show_buddy_list. Assuming the user has a buddy list (all buddy list
functions are controlled by list.c; when you sign on do_import is called
and that loads the locally saved list), the protocol calls
gaim_prpl_got functions, which set the information in the appropriate 
struct buddy and then passes it off to set_buddy.

set_buddy is responsible for a lot of stuff, but most of it is done
implicitly. It's responsible for the sounds (which is just a call to
play_sound), but the biggest thing it does is call new_group_show and
new_buddy_show if necessary. There's only one group_show per group name,

  all of the protocols. It's a pretty simple file actually.

server.c:
  This is where all of the differentiation between the different protocols
  is done.  Nearly everything that's network related goes through here
  at one point or another. This has good things like serv_send_im. Most of 
  it should be pretty self-explanatory.

sound.c:
  The main function in this file is play_sound, which plays one of 8
  (maybe 9?) sounds based on preferences. All that the rest of the code
  should have to do is call play_sound(BUDDY_ARRIVE), for example, and

Now then, there are protocols that gaim knows about. Each protocol is
in a prpl struct and kept track of in the protocols GSList. The way the
management of the protocols is, there will only ever be one prpl per
numeric protocol. Each prpl defines a basic set of functions: login,
logout, send_im, etc. The prpl is responsible not only for handling
these functions, but also for calling the appropriate prpl_got functions
It handles each of these on a per-account basis.

So why's it called a PRPL? It stands for PRotocol PLugin. That means
that it's possible to dynamically add new protocols to gaim. However,
all protocols must be implemented the same way: by using a prpl struct
and being loaded, regardless of whether they are static or dynamic.