Mercurial > pidgin.yaz
changeset 16178:d73ee2690376
merge of '3ae1c2f29b72682bad3542b9c0175438dd3309c0'
and '60672db63b751e0cdc4ab40d5251c9479d3c0c79'
| author | Richard Laager <rlaager@wiktel.com> |
|---|---|
| date | Mon, 16 Apr 2007 00:46:39 +0000 |
| parents | cc5917d70dde (current diff) d88f0f320c9b (diff) |
| children | 04acdacb4f96 |
| files | HACKING README.SVN README.dbus |
| diffstat | 11 files changed, 54 insertions(+), 662 deletions(-) [+] |
line wrap: on
line diff
--- a/COPYRIGHT Sun Apr 15 23:54:55 2007 +0000 +++ b/COPYRIGHT Mon Apr 16 00:46:39 2007 +0000 @@ -14,6 +14,7 @@ Patrick Aussems Anibal Avelar Ali Albazaz +Christopher Ayoup Alex Badea John Bailey Chris Banal
--- a/HACKING Sun Apr 15 23:54:55 2007 +0000 +++ b/HACKING Mon Apr 16 00:46:39 2007 +0000 @@ -1,448 +1,2 @@ -Lots of this is pretty grossly out of date... -Some of it might still be useful. For coding style, your -best bet is to browse through some of the files in src and -emulate what you see there. ---Mark - - -The majority of the below was written by Eric Warmenhoven way back in -antiquity. I have taken the liberty of attempting to PARTIALLY update -it. I still think its helpful, but use it at your own risk. ---Luke - - -A lot of people have tried to hack gaim, but haven't been able to because -the code is just so horrid. Well, the code isn't getting better anytime -soon (I hate GNU indent), so to help all you would-be hackers help out -gaim, here's a brief tutorial on how gaim works. I'll quickly describe -the logical flow of things, then what you'll find in each of the source -files. As an added bonus, I'll try and describe as best I can how multiple -connections and multiple protocols work. Depending on how much I want to -avoid my final tomorrow I may even describe other parts of gaim that I -particularly want to brag about. Hopefully that's enough to get most of -you going. - -If you don't know how event-driven programs work, stop right now. Gaim -uses GTK+'s main loop (actually GLib's but I won't talk about how GTK -works) and uses GLib functions for timeouts and socket notification. If -you don't know GTK+ you should go learn that first. - -If you're going to hack gaim, PLEASE, PLEASE PLEASE PLEASE send patches -against the absolute latest SVN. I get really annoyed when I get patches -against the last released version, especially since I don't usually have -a copy of it on my computer, and gaim tends to change a lot between -versions. (I sometimes get annoyed when they're against SVN from 3 days -ago, but can't complain because it's usually my fault that I haven't -looked at the patch yet.) To get gaim from SVN (if you haven't already), -run the following commands: - -$ svn co https://svn.sourceforge.net/svnroot/gaim/trunk gaim -$ cd gaim -$ ./autogen.sh - -You'll now have your normal gaim tree with ./configure and all (which -./autogen.sh takes the liberty of running for you). (If you want to make -your life really simple, learn how SVN works. SVN is your friend.) To make -a patch, just edit the files right there in that tree (don't bother with -two trees, or even two copies of the same file). Then when you're ready to -make your patch, simply run 'svn diff > my.patch' and post it on -sf.net/projects/gaim in the patches section. - -Some Documentation is available on the Gaim api if you run the command -$make docs -after running ./configure (or ./autogen.sh). You will need doxygen and -graphiz dot to generate these docs. - -CODING STYLE -============ - -Coding styles are like assholes, everyone has one and no one likes anyone -elses. This is mine and if you want me to accept a patch from you without -getting annoyed you'll follow this coding style. :) - -It would probably just be easier for me to include CodingStyle from the -linux kernel source. - -Tab indents. I *HATE* 2-space indents, and I strongly dislike 8-space -indents. Use a tab character. I'm likely to refuse a patch if it has -2-space indents. - -K&R style for braces. Braces always go on the same line as the if, etc. -that they're associated with; the only exception is functions. Braces -for else statements should have both braces on the same line as the else -(i.e. "} else {"). - -No functionOrVariableNamesLikeThis. Save it for Java. Underscores are your -friend. "tmp" is an excellent variable name. Hungarian style will not be -tolerated. Go back to Microsoft. - -I have a 105-char wide Eterm. Deal with it. - -NO goto. I'm very likely to refuse a patch if it makes use of goto. If you -feel the need to use goto, you need to rethink your design and flow. - - -PROGRAM FLOW (just about every function name from here on down is wrong. -============ but many of the ideas still apply under different names.) - -Before gaim does anything you can see, it initializes itself, which is -mostly just reading ~/.gaim/*.xml (handled by the functions in prefs.[ch]) -and parsing command-line options. It then draws the login window by -calling show_login, and waits for input. - -At the login window, when "Accounts" is clicked, account_editor() is -called. This then displays all of the users and various information -about them. (Don't ask about what happens when "Sign On" is called. It's -quite hackish. The only reason the login window is there anymore is to -make it more palatable to people so used to WinAIM that they can't accept -anything else.) - -When the "Sign on/off" button is clicked, serv_login is passed the -username and the password for the account. If the password length is -zero (the password field is a character array rather than pointer so it -will not be NULL) then the Signon callback will prompt for the password -before calling serv_login. serv_login then signs in the user using the -appropriate protocol. - -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, -even between connections, and only one buddy_show per group_show per -buddy name, even between connections. (If that's not confusing enough, -wait until I really start describing how the buddy list works.) - -New connections happen the exact same way as described above. Each -gaim_account can have one gaim_connection associated with it. gaim_account -and gaim_connection both have a protocol field. This is kind of confusing: -gaim, except for the account editor screen and when the user signs on, -ignores the user's protocl field, and only uses the connection's protocol -field. You can change the connection's protocol field once it's created -and been assigned a PRPL to use to change certain behavior (Oscar does -this because it handles both AIM and ICQ). I'll talk about the -gaim_connection struct more later. - -When the user opens a new conversation window, new_conversation is called. -That's easy enough. If there isn't a conversation with the person already -open (checked by calling find_conversation), show_conv is called to -create the new window. All sorts of neat things happen there, but it's -mostly drawing the window. show_conv is the best place to edit the UI. - -That's pretty much it for the quick tutorial. I know it wasn't much but -it's enough to get you started. Make sure you know GTK+ before you get too -involved. Most of the back-end stuff is pretty basic; most of gaim is GTK+. - - -SOURCE FILES (this should probly be utterly removed) -============ - -about.c: - Not much to say here, just a few basic functions. - -account.[ch]: - This controls the GaimAccount struct, which stores information - on each account a user registers with gaim. Usernames, pass- - words, user info, alias, user specific options, and everything - else controlled from within the account editor (and then some) - are handled via this code. - -accountopt.[ch]: - Api and implemenation for account options. I'm not precisely - sure how this meshes with account.[ch] - -away.c: - This takes care of most of the away stuff: setting the away message - (do_away_message); coming back (do_im_back); drawing the away window; - etc. Away messages work really oddly due to multiple connections and - multiple protocols; I think there are really only two or three people - who know how it works and I don't think any of us know why it works - that way. - -blist.[ch]: - This takes care of the buddy list backend, the blist.xml file, - importing old buddy list files, and related things like - finding buddies and groups. buddies, contacts, and groups - are controlled from these files. - -buddy_chat.c: - This takes care of the buddy chat stuff. This used to be a lot bigger - until the chat and IM windows got merged in the code. Now it mostly - just takes care of chat-specific stuff, like ignoring people and - keeping track of who's in the room. This is also where the chat window - is created. - -conversation.c: - This is where most of the functions dealing with the IM and chat windows - are hidden. It tries to abstract things as much as possible, but doesn't - do a very good job. This is also where things like "Enter sends" and - "Ctrl-{B/I/U/S}" options get carried out (look for send_callback). The - chat and IM toolbar (with the B/I/U/S buttons) are both built from - the same function, build_conv_toolbar. - -core.c: - This is the start of what will become the main() for gaim-core. - -gtkdialogs.c: - A massive file with a lot of little utility functions. This is where all - of those little dialog windows are created. Things like the warn dialog - and the add buddy dialog are here. Not all of the dialogs in gaim are in - this file, though. But most of them are. This is also where do_import - is housed, to import buddy lists. (The actual buddy list parsing code - is in util.c for winaim lists and buddy.c for gaim's own lists.) - -gtkimhtml.c: - This is gaim's HTML widget. It replaced the old widget, GtkHtml (which - was different than GNOME's GtkHTML). It's self-contained (it doesn't - use any of gaim's code) and is actually a separate project from gaim - (but is maintained by Eric). - -idle.c: - This file used to be entirely #if 0'd out of existance. However, thanks - to some very generous people who submitted patches, this takes care of - reporting idle time (imagine that). It's a pretty straight-forward file. - This also takes care of the auto-away stuff. - -gtkmain.c: - This is where the main() function is. It takes care of a lot of the - initialization stuff, and showing the buddy list or account editor. - -md5.c: - Oscar, Yahoo, and MSN all require md5 hashing, so better to put it in - the core than have the same thing in three different places. - -module.c: - This contains all of the plugin code, except for the UI. This is what - actually loads the plugins, makes sure they're valid, has the code for - setting up plugin event handlers, and contains the plugin_event method - that gaim calls on events. - -prefs.c: - Read the documentation on this file. This handles the backend - side of prefs. - -proxy.c: - Adam (of libfaim glory) got bored one day and rewrote this file, so - now everything actually works. The main function is proxy_connect, - which figures out which proxy you want to use (if you want to use one - at all) and passes off the data to the appropriate function. This file - should be pretty straight-forward. - Except I STRONGLY suspect that time has broken this file. - -prpl.c: - This file is what lets gaim dynamically load protocols, sort of. All - of the actual dlopen(), dlsym() stuff is in module.c. But this contains - all of the functions that the protocol plugin needs to call, and manages - 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 - this file will take care of determining if a sound should be played - and which file should be played. - -util.c: - There's not really a lot of cohesion to this file; it's just a lot of - stuff that happened to be thrown into it for no apparent reason. None - of it is particularly tasty; it's all just utility functions. Just - like the name says. - -plugins/ticker/gtkticker.c: - Syd, our resident GTK+ God, wrote a GtkWidget, GtkTicker. This is that - widget. It's cool, and it's tiny. This is actually a really good example - widget for those of you looking to write your own. - -plugins/ticker/ticker.c: - Syd is just so cool. I really can't get over it. He let me come - visit him at Netscape one day, and I got to see all of their toys - (don't worry, I'm under an NDA). Anyway, this file is for the buddy - ticker. This is also a damn cool file because it's got all of the - functions that you'd want right up at the top. Someday I want to be - as cool as Syd. - -For the PRPLs, the only protocol whose "main" gaim file isn't the same as -the name of the protocol is ICQ; for that it's gaim_icq.c. But ICQ is -deprecated and you should be using Oscar for ICQ anyway. - -PLUGINS (read the plugins howto, this is really out of date) -======= - -OK, so you want to load a plugin. You go through whatever UI (you -can read all about the UI in plugins.c or whereever). You finally get -to load_plugin, the meat of the plugins stuff (plugins can actually -call load_plugin themselves to load other plugins). load_plugin -is passed the full path to the plugin you want to load -(e.g. /usr/local/lib/gaim/irc.so). - -load_plugin does a few things with that filename. The first is to see -if you've already loaded that plugin. If you have, load_plugin unloads -the one that is currently loaded. You might wonder why; it's because -the same plugin can't be loaded twice. If you call g_module_open on a -filename twice, both times it will return the same pointer, and both times -increment the reference count on the GModule * that it returns. This -means you really do have the same plugin twice, which fucks up the -callback system to no end. So it's better that you can only have it -loaded once at any given time. - -Now that we're assured that we don't have this particular plugin loaded -yet, we better load it. g_module_open, baby. Much more portable than -dlopen(). In fact, for Linux it actually is the equivalent of dlopen() -(you can read the gmodule source and see for yourself). There's only one -quirk. It always logically ORs the options you pass with RTLD_GLOBAL, -which means that plugins share symbols. I haven't figured out yet if -this means just functions or variables too; but in either case make every -function and variable in your plugin static except for gaim_plugin_*(), -name(), and description(). It's good coding practice anyway. - -So, assuming we didn't get NULL back from g_module_open, we then make sure -it's a valid gaim plugin by looking for and calling gaim_plugin_init, -courtesy g_module_symbol (g_module_symbol is actually what's portable -about gmodule as opposed to dl*; some BSD's require '_' prepended to -symbol names and g_module_symbol guarantees we do The Right Thing). - -Assuming we've found gaim_plugin_init and it hasn't returned non-NULL -to us, we then add it to our list of plugins and go merrily about our way. - -So when do the callbacks happen?! plugin_event, baby, plugin_event. Any -time you want to trigger a plugin event simply call plugin_even with the -parameters to be passed to any event handlers and you're set. plugin_event -then makes sure that any plugins waiting for the event get passed the -arguments properly and passes it on to perl. - -Speaking of perl. If you really want to know how this works, you're -better off reading X-Chat's documentation of it, because it's better -than what I could provide. - - -MULTIPLE CONNECTIONS AND PRPLS -============================== - -OK, let's start with the basics. There are users. Each user is contained -in an gaim_account struct, and kept track of in the gaim_accounts GSList. -Each gaim_account has certain features: a username, a password, and -user_info. It also has certain options, and the protocol it uses to sign -on (kept as an int which is #define'd in prpl.h). - -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. - -Here's how struct gaim_connection fits into all of this. At some point -the User (capitalized to indicate a person and not a name) will try to -sign on one of Their users. serv_login is then called for that user. It -searches for the prpl that is assigned to that user, and calls that prpl's -login function, passing it the gaim_account struct that is attempting to -sign on. The prpl is then responsible for seeing that the gaim_connection -is created (by calling new_gaim_connection), and registering it as -being online (by calling account_online and passing it the gaim_account and -gaim_connection structs). At that point, the gaim_account and gaim_connection -structs have pointers to each other, and the gaim_connection struct has -a pointer to the prpl struct that it is using. The gaim_connections are -stored in the connections GSList. The way connection management works is, -there will always only be one gaim_connection per user, and the prpl that -the gaim_connection uses will be constant for the gaim_connection's life. - -So at certain points the User is going to want to do certain things, -like send a message. They must send the message on a connection. So the UI -figures out which gaim_connection the User want to send a message on (for -our example), and calls serv_send_im, telling it which gaim_connection to -use, and the necessary information (who to send it to, etc). The serv_ -function then calls the handler of the prpl of the connection for that -event (that was way too many prepositions). OK, each prpl has a send_im -function. Each connection has a prpl. so you call gc->prpl->send_im and -pass it the connection and all the necessary info. And that's how things -get done. - -I hope some of that made sense. Looking back at it it makes absolutely no -sense to me. Thank god I wrote the code; otherwise I'm sure I'd be lost. - - -WRITING PRPLS -============= - -Start off with a protocol that you want to implement; make sure it has a -number defined in prpl.h. If it doesn't, talk to Rob or Eric about adding -it. *NEVER* use an unassigned number, not even for testing or personal -use. It's possible that number will be used later by something else and -that would cause quite a few head-scratchers. - -Start off with the following boiler plate: - -static struct prpl *my_protocol = NULL; - -void newproto_init(struct prpl *ret) { - ret->protocol = PROTO_NEWPROTO; - - my_protocol = ret; -} - -#ifndef STATIC - -char *gaim_plugin_init(GModule *handle) -{ - load_protocol(newproto_init, sizeof(struct prpl)); - return NULL; -} - -void gaim_plugin_remove() -{ - struct prpl *p = find_prpl(PROTO_NEWPROTO); - if (p == my_protocol) - unload_protocol(p); -} - -char *name() -{ - return "New Protocol"; -} - -char *description() -{ - return PRPL_DESC("New Protocol"); -} - -#endif - -Replace all NEWPROTO things with your protocol name (e.g. PROTO_OSCAR -instead of PROTO_NEWPROTO, oscar_init instead of newproto_init). Then -populate your struct prpl; the most important function is actually name(), -because without it, Gaim will most likely segfault. The second most -important function is login(). Not all functions need to be implemented. - -There should be absolutely *ZERO* GTK+ in the PRPLs. PRPLs should *NEVER* -say what the UI *looks* like, only what information needs to be there. -There's currently an effort to get the GTK+ that is contained in the PRPLs -directory out of there. If you submit a patch that adds GTK+ to those -directories it's very likely to be refused, unless if I'm in a good mood -and decide to relocate things for you. That's not likely. - -You're probably wondering how you can do certain things without GTK+. Well, -you're just going to have to make do. Rely on the UI, that's why it's -there. A PRPL should have absolutely ZERO interaction with the user, it -should all be handled by the UI. - -Don't use the _options variables at all. The core should take care of all -of that. There are several proto_opt fields that you can use on a per-user -basis. Check out existing protocols for more details. +For information on hacking on Pidgin, Finch, or libpurple, see: + http://developer.pidgin.im
--- a/Makefile.am Sun Apr 15 23:54:55 2007 +0000 +++ b/Makefile.am Mon Apr 16 00:46:39 2007 +0000 @@ -7,8 +7,7 @@ Makefile.mingw \ PLUGIN_HOWTO \ PROGRAMMING_NOTES \ - README.SVN \ - README.dbus \ + README.MTN \ README.mingw \ config.h.mingw \ gaim.pc.in \
--- a/PLUGIN_HOWTO Sun Apr 15 23:54:55 2007 +0000 +++ b/PLUGIN_HOWTO Mon Apr 16 00:46:39 2007 +0000 @@ -1,6 +1,6 @@ For information on writing a plugin for Purple, Pidgin or Finch, go -http://pidgin.im/api/ and see the HOWTOs in the "Related Pages" -section. +http://developer.pidgin.im and click on API. From there, see the HOWTOs in the +"Related Pages" section. You can also generate this documentation locally by installing doxygen and graphviz dot, then running "make docs" in the
--- a/PROGRAMMING_NOTES Sun Apr 15 23:54:55 2007 +0000 +++ b/PROGRAMMING_NOTES Mon Apr 16 00:46:39 2007 +0000 @@ -16,7 +16,7 @@ e.g: fopen("somefile", "wb"); - Not doing so will open files in windows using defaut translation mode. + Not doing so will open files in windows using default translation mode. i.e. newline -> <CR><LF> Paths
--- a/README Sun Apr 15 23:54:55 2007 +0000 +++ b/README Mon Apr 16 00:46:39 2007 +0000 @@ -41,12 +41,9 @@ get installed into locations they want to be in. Once you've done that, you only need to run 'pidgin' or 'finch'. -Protocol plugins (PRPLs) are now automatically loaded. Simply go to the -account editor, add a new account, and all supported protocols will be -there. Be sure to use OSCAR (AIM/ICQ) and not the old TOC or ICQ plugins. +To get started, simply add a new account. -Read below for protocol-specific information. - +If you come across a bug, please report it at: http://pidgin.im PLUGINS ======= @@ -57,121 +54,12 @@ 'make install' puts the plugins in $PREFIX/lib/purple (PREFIX being what you specified when you ./configure'd - it defaults to /usr/local). Purple -looks for the plugins in that directory by default, but they do not have -to be there to use them. Also, plugins have a .so extension by default, -though they do not have to. +looks for the plugins in that directory by default. Plugins can be installed +per-user in ~/.purple/plugins as well. Pidgin and Finch also look in +$PREFIX/lib/pidgin and $PREFIX/lib/finch for UI-specific, respectively. To build a plugin from a .c file, put it in the plugins/ directory in the source and run 'make filename.so', e.g. if you have the .c file 'kickass.c', put it in the plugins/ directory, and from that directory, run 'make kickass.so'. - -NOTES -===== - -If you manually set a command for your browser or sound player options, -make sure to put double-quotes around the "%s", otherwise bad things may -happen. - -If you come across a bug, please report it to http://pidgin.im/. - - -PROTOCOL INFORMATION -==================== - -Each protocol is hacked by both Rob and Eric, though there is one person -that kind of "owns" a protocol (mostly indicating that they were the -person that originally wrote it). Their name will be next to the protocol; -they're the people to complain to when something doesn't work ;). - - -TOC (Mark) -=== - -You shouldn't use TOC, you should use Oscar instead. TOC can sync your -buddy list with the server (if it's not too long), and can respond to file -transfer requests (both sending and receiving). Other than that, there's -nothing it can do that Oscar can't, yet. The TOC protocol doesn't allow -retrieval of away messages; isn't capable of sending or receiving buddy -icons; it also can't make file transfer requests. - - -Oscar (Mark) -===== - -Oscar is the default protocol. It is recommended that you use Oscar for -both AIM and ICQ, as TOC isn't very featureful and the old ICQ protocol no -longer works. - -For AIM, Oscar can get people's away messages. It can request and accept -Direct Connections, and has limited support for file transfer. IM Image -does not currently work. It can send and receive buddy icons if you have -GdkPixbuf. - -For ICQ, it supports nearly everything that the old ICQ plugin supported, -which isn't much. To use Oscar for ICQ, enter your ICQ UIN as the -screenname. The default host/port will work. You'll need to use a different -client to register a new ICQ account if you don't have one yet. - - -Yahoo (Sean) -===== - -Yahoo is currently using the new YMSG protocol that newer official Yahoo -clients are using. This protocol is much better than the old one, and -tends to be somewhat more reliable. However, the Yahoo service is still -flaky at best. - - -IRC (Ethan) -=== - -There are three ways to join an IRC chat room. The first is the File->Join -A Chat menu option in the Buddy List window. The second is the "Chat" -button at the bottom of the buddy list. The third is to type "/join #name" -in an IM window where the "Send Message As" menu is set to your IRC -account. There are other / commands that work in IM and Chat windows for -IRC, /help will give you a list of them. - - -MSN -=== - -With MSN you can join a conversation with several people, but you can't -invite people from the IM window yet. - - -Jabber (Nathan) -====== - -Transports aren't currently supported at all, though if you have a -transport already subscribed Purple will use it (you can't add or remove -transports though). In order to use a server other than jabber.org, set -your username to include the server, e.g. warmenhoven@mycompany.com. This -is the actual format of the Jabber ID anyway; Jabber is email with online -notification. You can register a new Jabber account by checking the -appropriate box in the account editor for your Jabber account. - - -Zephyr (Sean) -====== - -Let me start off by saying how much I really despise Zephyr. They do a -lot of things that make me realize why this never caught on. For those -of you who are unfortunate enough to feel compelling need to use this, -Purple now has a Zephyr plugin. It can currently sign on/off, handles -presence/buddy lists (it even imports your .anyone file!), and can -send/receive personal messages. A lot of stuff is missing, this is just -a real rough first stab at it. - - -Gadu-Gadu (Sean) -========= - -I really shouldn't be taking credit for Gadu-Gadu, I'm just the person who -commits the patches that Arkadiusz Miskiewicz gives me. Gadu-Gadu is an IM -system most similar to ICQ that is quite popular in Poland. It can manage -your server-side buddy list through the Protocol Actions menu. You'll need -to use a different client to register a new account if you don't have one -yet.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/README.MTN Mon Apr 16 00:46:39 2007 +0000 @@ -0,0 +1,33 @@ +If you plan to use Pidgin, Finch and libpurple from our Monotone repository, +PLEASE read this message in its entirety! + +Pidgin, Finch, and libpurple are a fast-moving project with a somewhat regular +release schedule. Due to the rate of development, the code in our Monotone +repository undergoes frequent bursts of massive changes, often leaving behind +brokenness and partial functionality while the responsible developers rewrite +some portion of code or seek to add new features. + +What this all boils down to is that the code in our Monotone repository _WILL_ +sometimes be broken. Because of this, we ask that users who are not interested +in personally tracking down bugs and fixing them (without a lot of +assistance from the developers!) use only released versions. Since releases +will be made often, this should not prevent anyone from using the newest, +shiniest features -- but it will prevent users from having to deal with ugly +development bugs that we already know about but haven't gotten around to fixing. + +If you are interested in hacking on Pidgin, Finch, and/or libpurple, please +check out the information available at: http://developer.pidgin.im + +By far the best documentation, however, is the documented code. If you have +doxygen, you can run "make docs" in the toplevel directory to generate pretty +documentation. Otherwise (or even if you do!), the header files for each +subsystem contain documentation for the functions they contain. For instance, +conversation.h contains documentation for the entire purple_conversation_* +API, and account.h contains documentation for the purple_account_* API. + +If you have questions, please feel free to contact the Pidgin, Finch, and +libpurple developers by e-mail at devel@pidgin.im or on IRC at irc.freenode.net +in #pidgin. Please do as much homework as you can before contacting us; the +more you know about your question, the faster and more effectively we can help! + +Patches should be posted as Trac tickets at: http://developer.pidgin.im
--- a/README.SVN Sun Apr 15 23:54:55 2007 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,39 +0,0 @@ -If you plan to use Pidgin, Finch & libpurple mtn, PLEASE read this message in its entirety! - -Pidgin, Finch & libpurple is a fast-moving project with a somewhat regular -release schedule. Due to the rate of Pidgin, Finch & libpurple development, -mtn undergoes frequent bursts of massive changes, often leaving behind -brokenness and partial functionality while the responsible developers rewrite -some portion of code or seek to add new features. - -What this all boils down to is that mtn _WILL_ sometimes be broken. -Because of this, we ask that users who are not interested in -personally tracking down bugs and fixing them (without a lot of -assistance from the developers!) avoid mtn and use releases. Since -releases will be made often, this should not prevent anyone from using -the newest, shiniest features -- but it will prevent users from having -to deal with ugly development bugs that we already know about but -haven't gotten around to fixing. - -If you are interested in hacking on Pidgin, Finch & libpurple, please read -README and HACKING, and take note of the issues in PROGRAMMING_NOTES. (Note -that they may be somewhat out of date at times.) Win32 developers, please -read README.mingw. - -By far the best documentation, however, is the documented code. Not -all parts of Pidgin, Finch & libpurple have yet been documented, but the major -subsystems are falling fast. If you have doxygen, you can use the Doxyfile in -the toplevel directory to generate pretty documentation. Otherwise -(or even if you do!), the header files for each subsystem contain -documentation for the functions they contain. For instance, -conversation.h contains documentation for the entire purple_conversation_* -API, and account.h contains documentation for the purple_account_* API. - -If you have questions, please feel free to contact the Pidgin, Finch & -libpurple developers by email at devel@pidgin.im or on IRC at irc.freenode.net -in #pidgin. Please do as much homework as you can before contacting us; the -more you know about your question, the faster and more effectively we can help -you! - -Send patches to Pidgin, Finch & libpurple mailing list, devel@pidgin.im, or -post them in the tracker at http://developer.pidgin.im.
--- a/README.dbus Sun Apr 15 23:54:55 2007 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,48 +0,0 @@ -This file describes how to compile and run gaim with dbus support. -Hopefully, most of the steps from point 3 will soon be automated. - - -1. Make sure you have the latest version (0.34) of the dbus library - installed, including glib bindings. - - http://www.freedesktop.org/Software/dbus - - -2. Compile gaim - - ./configure --enable-dbus - make - make install - - -3. Configure your dbus instalation for gaim - - A. Find your dbus session configuration file, usually - - /etc/dbus-1/session.conf - - B. In that file, find the <servicedir> section. This section - contains the directory that stores files describing services, - usually - - /usr/share/dbus-1/services - - C. Copy src/dbus-gaim.service to that directory - - D. Edit the dbus-gaim.service file you've just copied, and replace - the path in the "Exec=" line with the path to your gaim - executable. - - -4. Start Session DBUS if you haven't done it already - - eval `dbus-launch --session` - export DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_PID - - These commands will set the two above shell variables. These - variables must be set before running any dbus-aware programs. - -Start gaim as usual. To communicate with it, use "gaim-send". When -you execute gaim-send, the dbus system will automatically start a gaim -process if one is not running already. -
--- a/libpurple/protocols/simple/simple.c Sun Apr 15 23:54:55 2007 +0000 +++ b/libpurple/protocols/simple/simple.c Mon Apr 16 00:46:39 2007 +0000 @@ -593,12 +593,16 @@ GSList *transactions = sip->transactions; gchar *cseq = sipmsg_find_header(msg, "CSeq"); - while(transactions) { - trans = transactions->data; - if(!strcmp(trans->cseq, cseq)) { - return trans; + if (cseq) { + while(transactions) { + trans = transactions->data; + if(!strcmp(trans->cseq, cseq)) { + return trans; + } + transactions = transactions->next; } - transactions = transactions->next; + } else { + purple_debug(PURPLE_DEBUG_MISC, "simple", "Received message contains no CSeq header.\n"); } return NULL;