October 10, 2013 03:09 PM by Tomasz Wasilczyk
August 26, 2013 10:47 AM by Tomasz Wasilczyk
June 08, 2013 05:54 PM by Tomasz Wasilczyk
May 28, 2013 12:52 AM by Mark Doliner
Pidgin was awarded four students for this year’s Google Summer of Code. It was a difficult process to select just four students from the 34 great applications we received. These are the projects we finally chose:
- Ankit Vani will be working on GObjectification. This entails a lot of behind-the-scenes changes to the Pidgin code to use GObjects to make developer’s lives easier.
- Ashish Gupta will be working on improving file transfer between libpurple and non-libpurple IM clients. He’ll initially be focusing on the Yahoo! and XMPP protocols before moving on to a protocol-agnostic file transfer plugin.
- Bhaskar Kandiyal will be creating a website for browsing available Pidgin plugins, as well as improving Pidgin’s plugin management and installation UI.
- Phil Hannent will create Quail – a Qt GUI for libpurple.
We’re looking forward to seeing what they create! The coding period begins June 17 and ends September 23.
As always, thanks to everyone who applied. And remember, this is an open source project and you’re welcome to contribute even if you’re not participating in Summer of Code.
May 16, 2013 03:12 PM by Tomasz Wasilczyk
April 25, 2013 05:31 AM by Mark Doliner
The application period for applying to Google Summer of Code opened on Monday and we’ve already received a number of applications. The application period closes next Friday, May 3rd. Just 8 days left—don’t wait, submit your application soon!
April 09, 2013 07:21 AM by Mark Doliner
Google has accepted Pidgin into Google Summer of Code 2013. Woo-hoo! We’re looking forward to mentoring a few lucky students again this year.
We always encourage our users to brainstorm and share your ideas on improvements you would like to see in Pidgin, Finch, and libpurple. Feel free to share thoughts and ask questions on our devel mailing list.
March 26, 2013 06:24 PM by Tomasz Wasilczyk
November 11, 2012 11:58 PM by John Bailey
So, Microsoft recently announced that they’ll terminate the Windows Live Messenger service in favor of Skype in early 2013. We’ve been getting a number of questions about what this means for Pidgin. Quite honestly, we don’t know. At this point, all we know is that China will still be able to use Windows Live Messenger. That leads us to believe that the servers providing MSNP service will remain active and maintained for some period of time after the announced shutdown, but it’s not clear whether or not that will be the case. It’s also not clear if the servers supporting China’s continued use of WLM will be accessible to non-Chinese IP space. Even further, it’s not clear if the recently-launched XMPP interface to the WLM network will remain functional. We don’t support that yet though, as it requires some authentication magic we don’t implement. Even if we implement support for the authentication this XMPP gateway requires, it could end up being a waste of time, as it could get shut down at any time, either before or after the rest of WLM.
And before anyone goes there, we can’t support Skype. There is no documentation of the protocol available to us, nor is there code we can borrow from a cleanly reverse-engineered alternative implementation. All that exists is SkypeKit, whose license agreement explicitly forbids its use in open-source software. The license also forbids use in “server applications” which precludes doing something like wrapping a simple closed-source XMPP daemon around SkypeKit. It is not currently possible to legally support Skype, so we won’t try.
The bottom line is we have no idea what the announcement means for Pidgin or any other alternative clients yet. We’ll all just have to wait and see.
November 01, 2012 09:52 PM by Sanket Agarwal
If you have had the pleasure of reading a great contribution to academics, be it any field – you could marvel at how systematically and sequentially authors write their work. Well, if you are after impressing the world – you better know how to trick-o-treat with words! I have been very fortunate to be part of a system and academic curriculum where meaningful and real-world impacting research took place. I have a very few academic publications to my name. I could easily count them on fingers, 3 if I remember correctly. But being a part of the academic community leaves an impression which cannot be replaced by any thing else. It’s the same thrill one feels when jumping off the cliff (for a bungee, ofcourse). I have wondered why, WHY do I keep getting these thrills to do some academic research again. I know, what I currently do is what I like but I keep getting attracted to the other side of the park – which theoretically (pun intended!) is GREEN.
The issue that I want to raise today, is how research happens in an environment where students doing their Bachelor’s or Master’s interact with their senior colleagues. To start off let’s look at how a Bachelor thinks of research. In his opinion, research is a way to glorify his path to success. A way to vent his thirst on something he finds meaty. The charm of doing what very few do. All this is good, simply because of the hundred’s of dead-end ways of spending his time — here he is destined to learn something useful. But he is no different from a “toad in a well”. His view of the BIG PICTURE is restricted. What matters to him is his short-sight towards quick-glory. Compare this to a Doctoral Student who would spend few years just learning about the domain he is about to rip apart — a bachelor student gets a few hours over the week assigned to him by his professor! Ofcourse, I am speaking this in context of IIT’s research fraternity.
The professor’s view of a bachelor’s student is very interesting. I am trying to anonymously quote one of the discussions I had regarding this with a very friendly department professor. He started off by expressing the obvious that Bachelor students at IIT are perhaps the best thing that might happen to this group of institutes. But the real research is not happening here. The reason being — lack of long term dedicated students. An good BTech might dedicate some 6 months to an year but then he’ll move on. What happens of the work he left behind, what about the continuity loss to the prof-in-charge? This is a motivating argument to considering the amount of effort put on part of our already-so-burdened professors. Well, I feel for them. They have had a lot to deal with — poor facilities, lack of good funding projects and the most essential – lack of competitive brilliance in their teams!
But how does a student feels when he gets a paper, some 12 pages of cribbing only a very few idiots in this world could understand, gets accepted! It’s enthralling. You feel as if you have been accepted as being one of the enlightened. I felt very delighted, on top of the world, cloud 9 or any-damn-cliche! I always wonder why that was, and one of the instantaneous reasons would be the audience. They consist of some really brilliant people known for their devotion towards excellence — and there you go, excellence is what makes it complete.
If you are one of those students, in your sophomore or around years of college, don’t think twice to accept such opportunities. Research is not about becoming the PhD nor does it involve kung-foo. It’s an adventure, sometimes tough(characterized by frustration) and sometimes enlightening(characterized by discovery). But it’s something that you would want to experience.
Best of luck!
August 08, 2012 06:36 AM by Sanket Agarwal
As part of a (un)timely dose of SoC updates, the Statscollector project is moving towards a mini milestone. With the UI part now consolidated and the client having all functionality of a mature plugin, we might have an official statscollector and display UI very soon . Currently the UI is hosted (with some test data) here. It may be down once in a while, and will change once we go live, but for the enthusiastic who wants to give inputs — you’re most welcome .
The plugin is now equipped with the following functionalities:
* Ask the user for the first time, “if he wants to submit stats”.
* Have the functionality to “Ask later” and also to change his preference using the prefs box
I have used the request API from pidgin, which means that the above functionality should span across Pidgin/Finch/(adium?) or whatever implements libpurple for their XMPP clients — great huh?
On the server side, the UI is pepped up to handle the following stats:
* Account/Plugin/UI information/Version info
It’s pretty much all about the highchartsjs API which makes the UI look apart .
June 04, 2012 08:48 AM by Sanket Agarwal
It’s a proud moment to actually see your baby fly . If you have been following the other posts on this category, you might have heard me saying a lot of stuff about how the server and client sides will be interacting to show the final stats. The hour of truth is here and I have finally completed a bare-bones version of statistics website. Before I blabber about it’s salient features go have a loot at it!
As I had discussed currently it has basic statistics (drawn from a rather small sample of a few dev’s sending there share of information). Currently you can see, the type of Operating System, the architecture type, bitness of the application/operating system and other purple specific statistics. I have used highcharts and it has proved to be *quite* an impeccable JS plotting library. It gives neat and smooth transitions. You should check out Operating System information where clicking on either “Windows” or “Mac” drills you down into another chart, without having to reload the page .
The tough part, ofcourse is testing the server. I will be bottom posting a few code links where you can find all the stuff I have done. I am currently trying to tract developers to use my plugin and help me in testing the server components, as well as spanning different variety of machines. I will split this section for windows, mac and linux/unix/POSIX users separately.
If you are using windows, I already have a compiled DLL for download. You can help yourself with the link here. To enable the plugin copy the plugin in your .purple/plugins/ directory and enable it using Tools->Plugins->Statscollector.
The version of this plugin is compiled with 2.10.4 which is the latest release currently on pidgin.im. If you are a energetic and tedious [;-)] tester or wish to compile on a different release (2.10.5devel) hold your horses till the “From Source” section.
This section (should) hold for all flavors of linux as long as the version is compatible. If it does not work, then most probably you need to compile from source . In linux you require a .so file to work with plugins. I have compiled quite a few .so files with linux and will be providing you with versions of 2.10.4, 2.10.5devel and 3.0.0 (current im.pidgin.pidgin). Though IMO you should check your pidgin version and as 2.10.4 is the current release, try to test the plugin with that. I am unsure _if_ these plugins should crash pidgin. If they do, please compile your code from source.
2.10.4 — http://dl.dropbox.com/u/11564582/statscollector-2.10.4.so
2.10.5devel – http://dl.dropbox.com/u/11564582/statscollector-2.x.y.so
3.0.0 – http://dl.dropbox.com/u/11564582/statscollector-2.10.4.sho
I currently don’t have access to a 64 bit Operating System running linux. So if you have indeed installed a 64 bit pidgin, might as well build from source
Mac is much more like a Linux Machine and building code should be equally easy if you are working on a development scratch-pad. That said, I don’t have binaries to ship out for Mac either !
Building from source is perhaps the most reliable (and easy for me to maintain) way to do things! The source for the plugin could be found in the mtn repositories here. Check out the head and look for the file, libpurple/plugins/statscollector.c. You can make the plugin by using tips here!
If you do decide to install my plugin and have a go at it, let a comment so that I can fix any bugs/ask for feedback.
May 28, 2012 04:41 PM by Sanket Agarwal
In the continuing series of posts, I will today highlight another aspect of GSoC project. This time we’ll take a look at the server components, and some rational as to why these are chosen. If you have been following the previous posts, you’d know that I have been actively working on collecting whatever the system can provide me with information regarding the activity on your pidgin and/or the information about OS/hardware features. Pidgin devs find it useful to know where to concentrate their focus while developing protocols et. al for pidgin.
The hardest part in stats collection apparently turned out to be CPU info, as it is heavily OS/Architecture dependent and hence a lot of #ifdef _some_os_ stuff etc. For now I have been able to stabilize it to _some_ extent. Well development on that end will continue as we speak .
This post considers some of the server related issues. So the technologies that I’ll be working with for the server components are DJango for serving the logic on top of MySQL (anyhow DJango very nicely abstracts DB connections using the classical MVC architecture). As the task involves a lot of graphing, Eion has suggested me to use this awesome JS native library called, “Highcharts” which apparently is very savvy. I am currently figuring out a way to meld Django with Highcharts’ JSON objects cleanly.
Let’s wait and watch for some magic to happen soon !
May 22, 2012 06:06 PM by Sanket Agarwal
It has been an exciting ride till now, and mostly discovering new stuff. I’ll discuss what has been the plan all this week and what all I have been able to achieve, including the most amazing learning experiences with pidgin .
The task is to collect useful statistics which could help libpurple/pidgin developers about what should be developed in which platform. We started with boiling down the statistics to the following categories and sub-categories.
* Protocol Plugins
* User plugins (gtk, core and others controlled by users)
* UI’s used (pidgin/gtk, finch/ncurses, adium, nullclient?)
You might be interested in how the final obtained output shall look for a Linux box running x86 architecture and Pidgin. Here’s a pastie view of it: http://pastebin.com/3sVFFd4a
As you could follow, I have used XML to story the contents (simply because XML is a inherent component when dealing with protocols and extensively used across various IM platforms). There is a lot of meat in the XML stats collection taking place — starting from CPUinfo right down to UI info and accounts, plugins etc.
I started off with writing components which were easier to do, and by easy I mean those which can be done on multiple platforms without trouble. It is my experience and lot other coders shall believe so, that cross-platform stuff can be REALLY nagging. It’s the same old store, IE vs the rest of world. Accounts, plugins and other libpurple specific information was hence easy to grab.
The tough part and the part in which I spent the better half of my time, was collecting CPUinfo. The various components of CPUinfo we are dealing with are:
* Architecture of the hardware
* Whether the application is 32/64 bit
* Whether the OS running the application is 32/64 bit
* OS/kernel description and version (in case of Mac and Windows)
The task is complicated by reasons obvious, we need a lot of native code and hence need to write separate sections for various OSes. We demarcated the OSes into the following categories
So we could use absolutely separate code for Windows but mix and match code for the other boxes. I was surprised with the power POSIX compliance gives to OSes. Specially when it comes to knowing what hardware is really being run! Just for a small demo, you could try “uname -a” to know exactly what kind of hardware and kernel (to the extent of Linux kernel version and Flavor) being run. It was really a life saver because there’s *no* other easy way to do this.
The biggest hurdle till now has been determining bitness of application vs OS. This is necessary because there’s a big current question, do we completely switch to 64 architectures or there are lots of people who could not afford such a switch. Infact currently pidgin ports *only* for 32 bit windows applications, even when windows support 64 bit applications. The trouble again here is that you cannot use simple checks. Consider for example I did, sizeof(int *) to detect what is the Bitness, it’ll fail in case a 32 bit application is running on top of 64 bit OS. We had to come up with rather hacky idea of using “uname -m” in case of POSIX compliant OS and something called, “IsWow64Processs” in case of Windows to determine if an application is running on a 64 bit OS. I would remind here that architecture could *still* be different. Eg, if a 32 bit application is running on a 32 bit OS but the hardware supports 64 bit (say x86_64).
All in all, I learnt a lot about computer architectures and bitness and how they really fit into current scenarios. I also learnt a lot about writing #os-specific code . I am amazed at the amount of work I have been able to complete within few days of code-period and it looks like it’ll be a great summer of code ahead
May 01, 2012 06:41 PM by Sanket Agarwal
Looks like this summer is going to be one dusty ride. I have been selected for the Google Summer of Code program, 2012 with Pidgin. Firstly my proposal is public. You are welcome to have a shot at it. I will be working on “Pidgin stats collection” and Eion will be helping me out with the project.
For those who are not aware of what Google Summer of Code entails. It’s a summer long coding program where students (and students only) are allowed to write proposals for any projects they might wish to pursue to various organizations. The organizations then choose students on requirement and quality of proposal basis. GSoC has been successfully running for over “5″ years now. The pay is nice (~ $5000) for a summer spanning 3 months.
I have been trying for GSoC for 4 years now, and this is my second success. So basically it’s pretty stiff to compete here! Coming to my project, I will be working on providing Pidgin with a usage-stats collecting framework. Pidgin being a multi-protocol client – has a lot of diversity and it’s generally useful to know what is being used a lot and what is used only scanty. Well, it’s a famous software engineering law that 10% of the software features are used 95% of times. Then better know them . I will be working on the lines similar to Sparkle, which is a stats collation interface for Adium.
It sounds a very interesting summer, and the project has a very largescale impact across Pidgin! The most interesting part being, as soon my plugin goes live – it starts collecting information. It’s always very exciting to see you baby fly . I have decided to write a regular blog in this space regarding my SoC progress.
April 24, 2012 08:19 AM by Mark Doliner
We’re pleased to announce that we’ve accepted four students for this year’s Summer of Code!
- Gadu-Gadu PRPL improvements by Tomasz Wasilczyk, mentored by Ethan Blanton
- Plugin website by Nikhil Bafna, mentored by Kevin Stange
- Usage stats collection by Sanket Agarwal, mentored by Eion Robb
- libpurple on Android by Michael Zangl, mentored by Mark Doliner
It’s always difficult to narrow down so many great applications into just a handful, and we want to thank everyone who applied. The coding period runs from May 21 through August 24. If you want to follow the progress of the four students, they’ll be providing periodic status updates to our devel mailing list throughout the summer.
March 27, 2012 12:28 PM by Jorge Villaseñor
I urge every student reading this to apply for any of the projects accepted and if you like, apply to Libpurple.
We have a set of proposed ideas but you are encouraged to bring your own ideas since they will be fresher and will not compete with other people over the same project.
You can find libpurple's application page at Pidgin, Finch and libpurple.
March 18, 2012 02:11 AM by Mark Doliner
Good news, everyone! Google has accepted the Pidgin project‘s application to be a mentoring organization in this year’s Google Summer of Code. If you love programming and are looking for a chance to help an open source project, look no further.
How much can you accomplish in a single summer? Quite a lot. To give you an idea, here’s a list of some of our heftier projects of past years:
- SSL certificate verification and management
- Voice and video chat for XMPP
- The Bonjour protocol plugin
- The MySpace protocol plugin
- The SIMPLE protocol plugin
- Finch (command-line based IM client based on libpurple)
- Get inspired by our ideas list. But don’t limit yourself to those ideas—we love when students propose their own projects.
- The application period starts March 26 and ends April 6th (full timeline)
- Once the application period opens, apply here
- We’re guessing we’ll request slots for 3 students this year.
- If IM isn’t your thing but you still want to participate, check out the list of other great organizations
August 28, 2011 03:44 PM by John Bailey
VersioningFirst of all, there seems to be some confusion about how Pidgin and libpurple version numbers work. I'd like to try to clear some of that up.
Pidgin, Finch, and libpurple use what's called “Semantic Versioning.” That is, each part of the version number has a particular meaning for users and developers. We chose this scheme to assist plugin developers in knowing when significant changes would require effort on their part to maintain compatibility with current Pidgin and/or libpurple versions. It also helps our users by letting them know when their existing plugins will stop working. So, how does this semantic versioning work? Let's look at the format of our version numbers and find out.
Pidgin, Finch, and libpurple version numbers have three components, separated by dots. At the time of this writing, 2.10.0 is the current version number. These components are called major (currently 2), minor (currently 10), and micro or patch (currently 0). Let's look at what each means.
- Major: the major version doesn't change often. The last time we changed it was in 2007 with the release of Pidgin 2.0.0, and before that was in 2004 with 1.0.0 when we started using semantic versioning under our previous name. Whenever this number changes, we've made changes to Pidgin, Finch, or libpurple that break compatibility with every UI and plugin that currently exists. Usually this means that we've removed something from the API exposed to plugins and UI's, or that we've changed something about a function (its name, arguments, return type, or the header file it's in). Sometimes plugins or UI's can just be recompiled when this happens; other times they need maintenance to become compatible with the new release. Additionally, the major version never decreases. It will always increase when it changes.
- Minor: the minor version changes more frequently than the major version, but generally less often than the micro or patch version. Whenever the minor number increases, we've added things to our API that do not break compatibility with existing plugins or UI's. A prime example of this is adding the voice and video support we added in 2.6.0. We added a bunch of stuff to the existing API, but didn't change anything that would cause a break in backward compatibility with existing plugins and UI's. When the minor version decreases (gets set back to 0), it means that the major version has changed, and the whole cycle starts over.
- Micro or patch: The patch version changes with almost every release. When this version increases, it means that we haven't touched API at all; instead we've done nothing but fix bugs or add small features that don't affect compatibility with plugins or UI's. When this version decreases (gets set back to 0), it means that the minor version has changed.
Related to all this, and important only for plugin and UI developers (so skip this paragraph if you're not a developer!), is the behavior of the
PURPLE_VERSION_CHECKmacro. Many developers expect
PURPLE_VERSION_CHECK(2, 5, 0)or similar to expand to a statement that evaluates to
TRUEin the case of building against libpurple 3.0.0. This, however, is not the case. Because our major versions are incompatible with each other, we have intentionally written
PURPLE_VERSION_CHECKto fail if the major version is not an exact match. We understand this can be confusing and inconvenient, and we sincerely apologize for that, but we're not going to change it.
What all this means is that if the first number (major version) changes, you're going to need to update your plugins when you upgrade Pidgin, Finch, and libpurple. If the second (minor version) or third (micro version) numbers change, it means you need to upgrade Pidgin, Finch, and libpurple, but your existing plugins will still work. No matter what the Pidgin, Finch, and libpurple version numbers are, you should always be using the newest version.
Structure (“struct”) HidingThis paragraph is for those who aren't programmers. Feel free to skip it if you don't care about it. Pidgin is written in the C language. C has a type system, which means that if you declare a variable (imagine this as a box somewhere in your computer's memory) you can store only one type of data in it. A structure, or struct in C parlance, is a type made up of other types arranged sequentially. This is pretty easy to picture if you think of Lego blocks--stack a red block, a blue block, a green block, a yellow block, and a white block on top of each other and connect them together and you now have a structure made out of Lego blocks. It's pretty similar in C, except that you're telling the compiler to assemble something out of sequential boxes of memory instead of little plastic blocks.
Pidgin uses structs everywhere. We use them to represent things like your buddies, conversations, accounts, etc. Currently in Pidgin 2.10.0, most of the structs are in the public API—that is, anyone can directly access the members of the structs and do whatever they like. This is all fine and well, but it means that if our code changes such that a particular struct needs to grow significantly by the addition of new members, we can't always do that without breaking backward compatibility. (Yes, we included padding in a number of our structs, but we've burned through the padding in several of them, and although there are ways to work around it, I and a few other developers don't like them.) It also means that if we discover, for example, that switching the order of members in a struct allows the compiler to improve its optimizations or if we think a different order makes more logical sense for those of us reading and maintaining the code, we absolutely can't do this without breaking compatibility. We also can't rename members of structs for the same reason—it breaks compatibility with existing plugins, UI's, etc.
Because having these structs in the public API limits us so much, we're striving to hide as many of them as possible. By hiding, we mean that we're removing the struct definitions from the header files and moving them to the .c files, thus making them private. Plugin and UI authors will still be able to reference the “objects” with pointers, passing them to functions and operating on them with the appropriate sections of our public API, but no longer will the members of the structs be directly accessible outside of the .c files that define the functions that interact with them. For example, we have a PurpleRoomlist struct in libpurple/roomlist.c and libpurple/roomlist.h. For 3.0.0, the struct definition is in roomlist.c; thus the individual members are not directly accessible outside roomlist.c, even in other parts of libpurple. This “hiding” of the strcuts allows us significant internal flexibility in each file to modify the struct as we see fit.
Clean-Slate API DocumentationBecause we generally change so much each time we increase our major version number, the API documentation can get a bit confusing if we keep doing
@sincetags and whatnot in our doxygen documentation. Our general overall feeling is that we prefer just starting with a clean slate at each new major version. This means that each time we do a new major version, all existing
@sincetags will disappear, any functions marked as
@deprecatedwill be removed, renamed, or replaced as described in the
@deprecatedstatement, and so on. We realize this decision may make some things more difficult for some plugin and UI authors, and we apologize for that, but our aim is to have overall cleaner documentation for everyone.
Merging of Old ProjectsOver the years that we've participated in Google's Summer of Code program, we've accumulated a number of branches that have been sitting for quite some time. Most of these need some form of TLC and integration work. We want to try to incorporate at least some of them into 3.0.0 so we can finally benefit from the fruits of the students' labor. Most notably, we've been talking about merging the webkit integration branch into what will become 3.0.0. Eventually, this would allow the support of Adium's message styles, although it may not happen right away.
Another project of notable interest is some of the logging changes that went on in a previous Summer of Code project. One of our new Crazy Patch Writers took some of that work and made some progress on it; we don't know if this will make it for 3.0.0 or not yet, but it would be nice to have some of the features, such as non-blocking log writing.
Other Changes As WantedWe may decide to make other changes since a major version change gives us the opportunity to break so much. There have been a number of ideas floated, ranging from supporting that XDG directory spec that I can't stand to doing away with the xml files in .purple and replacing them with something else (with what, in particular, has not seriously been discussed). There is a whole range of possibilities of things we could do for 3.0.0; it's just a matter of one of us wanting it and sitting down to write it.
So everyone should stay tuned, as we'll be making more and more changes over the course of the 3.0.0 development cycle. We don't yet know when we'll be releasing 3.0.0—this is another one of our famous “when it's ready, and not a minute before” time frames. We do know, however, that it will change a lot!
August 04, 2011 07:49 AM by Mark Doliner
I wrote a crummy tool that displays the current DNS SRV records for a given XMPP domain. After writing it I discovered that Olark has already created something similar.
My tool attempts to do some really basic sanity checks and warns if it sees problems. If you think of something that it should check for but currently does not, please let me know! And please let me know if you notice any problems or have other suggestions.
Last updated: April 23, 2014 11:00 PM (All times are UTC.)