Add the GSoC pages and tags other files so they show up
--- a/content/design-guidelines.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,42 +0,0 @@
-These guidelines are informal descriptions of the sort of thinking that goes into the design of Pidgin, libpurple, and family. These are not hard-and-fast rules, but they are conscious decisions made by the Pidgin developers which will be violated only after careful consideration. (Or by mistake, and corrected shortly thereafter!)-While Pidgin is a multiprotocol IM client, the goal is to hide protocols from the user as much as possible. Obviously users have to know about individual protocols when they create or modify accounts, but in day-to-day communication and usage, the intent is that users don't have to think about protocols at all.-The workflow in Pidgin is intended to be "I would like to chat with Sean about wibbles", not "I would like to create an XMPP conversation with seanegan@pidgin.im".-The focus is on the goal, not the process. In reaching toward this focus, we have chosen to paper over the differences between the various protocols and features as much as possible (without crippling or needlessly complicating things). This has lead to decisions such as the removal of protocol icons from the buddy list and the implementation of contact-aware chats and logs.-> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.-> --Antoine de Saint-Exupery-In general we try to keep the code and the user interface simple. Especially when it comes to preferences in the UI. Pidgin should be as streamlined as possible. It is an IM client, so messaging someone should be easy. See [this essay](http://www106.pair.com/rhp/free-software-ui.html) by Havoc Pennington for an explanation of some ideas that we try to follow.-It's important for the code to be simple because this is an open source project and developers come and go. You never know who's going to be looking at your code next. If you write a function that's hard to follow then the next person that comes along will end up rewriting it, and that's counterproductive.-In plain language, this means that the protocol-specific code goes in the protocol plugin (*prpl*), and that libpurple exists, and is cleanly separated from the user interface. There are practical implications to this. While all of our code depends on glib, only the Pidgin specific parts depend on GTK+.-To implement, for example, file transfer; there are 3 steps. First, the protocol(s) have to support it. By themselves, however, the protocols can do nothing. So the "core," libpurple, has to support it also (the second step).-We do not want massive amounts of very similar code in libpurple, so the implementation of file transfer at the libpurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols.-Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch, or Adium) must support it. These interfaces know nothing about the protocol, and have only limited contact with the core. This helps to enforce the desire for uniformity explained above. It also makes it easier for the only sort of duplication we encourage: many interfaces. The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch).-Patches that voilate this layering will be rejected. In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video. On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI.-Our source code is very much a 'live' document. It should reflect what is currently needed, not what used to be needed or what might be needed in the future. Old code should be removed if it isn't being used (of course, you can only remove public functions and structures when the major version number increases)--it'll always be in the source code repository if anyone needs it. The code should contain documentation about what it does and why.-Pidgin and libpurple are single threaded. That means that the network code runs in the same process as the user interface. Network code must be non-blocking, otherwise the UI will be unresponsive. Code should be event-driven. Long running tasks should be asynchronous. File descriptors that need to be watched for changes should be added to the event loop.\ No newline at end of file
--- a/content/development-faq.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,99 +0,0 @@
-The following is a list of Frequently Asked Questions (FAQs), with answers, and notes related to development using LibPurple.-### I created an account, but it's not being saved!-You need to use `purple_accounts_add()` to add the account to the list of available accounts. This list of accounts is saved. Note that many of the functions require an account to be on that list. So you should always call `purple_accounts_add()` after creating an account.-### How do I get online with an account?-There are two ways you can do this:- * If you have other accounts online, and you want the new account to have the same status as those, then call `purple_savedstatus_get_current()` to get the current status, and use `purple_savedstatus_activate_for_account()` for the account.- * Otherwise, you can simply do `purple_account_set_status()` to set the status of the account.-An account needs to be enabled before it can be connected. So after doing either of the above, you need to enable the account by calling `purple_account_set_enabled()`.-### How can I create a conversation with someone?-Use `purple_conversation_new()`. Use `PURPLE_CONV_TYPE_IM` if the conversation is an IM (one-to-one person conversation), and use `PURPLE_CONV_TYPE_CHAT` if it's a multi-user conversation. One important thing to note here is that the name property of the `PurpleConversation` struct is the name of the buddy you are creating a conversation with (the documentation states that this is the name of the conversation itself, but it is in fact also the name of the receiving buddy). So a call to `purple_conversation_new()` takes the name of the buddy as its third argument.-### How can I send a message in a conversation?-Use either `purple_conv_im_send()` or `purple_conv_chat_send()`. Note that the first parameter to either of these functions are ***not*** the conversation itself. Rather, it's the IM data or chat data of the conversation which you can get from `PURPLE_CONV_IM`/`PURPLE_CONV_CHAT`.-### Is there a way that I can print something in the conversation window, but not send the message?-Yes. Use `purple_conv_im_write()` or `purple_conv_chat_write()`.-### What do I do with `DATADIR`, `LOCALEDIR`, and `LIBDIR`?-`DATADIR`, `LOCALEDIR`, and `LIBDIR` are defined as functions in the Windows build. Therefore, doing something like this will break the Windows build:- printf("File in DATADIR is: %s\n", DATADIR G_DIR_SEPARATOR_S "pic.png")- printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png");-### Why are files opened with mode `b`?-Without this, on Windows systems the opened files will use Windows default translation (<CR><LF> for newline, for example). This will cause errors due to newline format and the "bytes read" counts, which will be wrong when comparing the return value of `read()` to `stat()`.-### Why are `G_DIR_SEPARATOR_S` and `G_DIR_SEPARATOR` used everywhere?-This is a matter of maintaining cross-platform compatibility. Windows uses a backslash ("\") for directory separators in paths, while UNIX-like systems use the forward slash ("/"). Other OSes may choose to use other separators--for example, prior to Mac OS X, it was common for the directory separator on Macs to be a colon (":").-It is impractical to use preprocessor directives throughout the code to determine the path style to use, especially if a new OS were to appear and use a different directory separator. GLib, which we already use, provides the convenient separator macro, so we use this to reduce our code complexity and maintain cross-platform portability.-### What should I do to get the contents of an environment variable?-### Should I use `snprintf()` or `vsnprintf()`?-No. Use the GLib wrapper functions instead. They are `g_snprintf()` and `g_vsnprintf()`.-### How do I get the settings directory?-Use `purple_home_dir()`. You should *not* use `g_get_home_dir()` or `getenv("HOME")`.-### What is the versioning scheme?-**This is already defined elsewhere, we should probably just have a page for it... --grim**-There are three fields in the version: `major.minor.micro`.- * If the `major` is changing, you can break plugins. That means both forward- and backward- compatibility. API can be added or removed or whatever you like.- * If only the `minor` is changing, you can break forward compatibility only. You may add API, but you can't remove it. You can mark API as deprecated instead.- * If only the `micro` is changing, you can't break the API at all.-### Why is win32dep.h causing problems for me?-You need to make sure it is the last header you include if you need to include it. Not doing so is asking for problems.-## Plugins and Protocols-### How should I handle global variables?-Use `G_MODULE_IMPORT` for any global variable located outside your dynamic library. Not doing this will cause "Memory Access Violation" errors on Windows systems.-### What should I do for "exported" functions?-If your plugin has functions that are to be accessed from outside the scope of its file (.dll or .so), `G_MODULE_EXPORT` those functions.--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/development/_index.md Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,6 @@
+date: 2019-01-11T04:05:09+00:00 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/development/design-guidelines.md Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,47 @@
+title: "Design Guidelines" +date: 2019-01-10T22:32:00-06:00 +anchor: "design-guidelines" +These guidelines are informal descriptions of the sort of thinking that goes into the design of Pidgin, libpurple, and family. These are not hard-and-fast rules, but they are conscious decisions made by the Pidgin developers which will be violated only after careful consideration. (Or by mistake, and corrected shortly thereafter!) +While Pidgin is a multiprotocol IM client, the goal is to hide protocols from the user as much as possible. Obviously users have to know about individual protocols when they create or modify accounts, but in day-to-day communication and usage, the intent is that users don't have to think about protocols at all. +The workflow in Pidgin is intended to be "I would like to chat with Sean about wibbles", not "I would like to create an XMPP conversation with seanegan@pidgin.im". +The focus is on the goal, not the process. In reaching toward this focus, we have chosen to paper over the differences between the various protocols and features as much as possible (without crippling or needlessly complicating things). This has lead to decisions such as the removal of protocol icons from the buddy list and the implementation of contact-aware chats and logs. +> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. +> --Antoine de Saint-Exupery +In general we try to keep the code and the user interface simple. Especially when it comes to preferences in the UI. Pidgin should be as streamlined as possible. It is an IM client, so messaging someone should be easy. See [this essay](http://www106.pair.com/rhp/free-software-ui.html) by Havoc Pennington for an explanation of some ideas that we try to follow. +It's important for the code to be simple because this is an open source project and developers come and go. You never know who's going to be looking at your code next. If you write a function that's hard to follow then the next person that comes along will end up rewriting it, and that's counterproductive. +In plain language, this means that the protocol-specific code goes in the protocol plugin (*prpl*), and that libpurple exists, and is cleanly separated from the user interface. There are practical implications to this. While all of our code depends on glib, only the Pidgin specific parts depend on GTK+. +To implement, for example, file transfer; there are 3 steps. First, the protocol(s) have to support it. By themselves, however, the protocols can do nothing. So the "core," libpurple, has to support it also (the second step). +We do not want massive amounts of very similar code in libpurple, so the implementation of file transfer at the libpurple level has to abstract away from how individual protocols handle it, so as to be able to use the same calls from all file transfer supporting protocols. +Last, but not least, before the user can actually send or receive a file, the UI (Pidgin, Finch, or Adium) must support it. These interfaces know nothing about the protocol, and have only limited contact with the core. This helps to enforce the desire for uniformity explained above. It also makes it easier for the only sort of duplication we encourage: many interfaces. The core implementation cannot assume too much about what the UI will do, because the GTK+ UI (Pidgin) might need to handle a file transfer somewhat differently than the ncurses based UI (Finch). +Patches that voilate this layering will be rejected. In practice, this means that there is more work involved to introduce a new class of functionality, say file transfer, white-boarding, voice, or video. On the other hand, it means less work to implement any given class of functionality for a new protocol or for a new UI. +Our source code is very much a 'live' document. It should reflect what is currently needed, not what used to be needed or what might be needed in the future. Old code should be removed if it isn't being used (of course, you can only remove public functions and structures when the major version number increases)--it'll always be in the source code repository if anyone needs it. The code should contain documentation about what it does and why. +Pidgin and libpurple are single threaded. That means that the network code runs in the same process as the user interface. Network code must be non-blocking, otherwise the UI will be unresponsive. Code should be event-driven. Long running tasks should be asynchronous. File descriptors that need to be watched for changes should be added to the event loop. \ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/development/faq.md Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,104 @@
+date: 2019-01-10T22:32:00-06:00 +anchor: "development-faq" +The following is a list of Frequently Asked Questions (FAQs), with answers, and notes related to development using LibPurple. +### I created an account, but it's not being saved! +You need to use `purple_accounts_add()` to add the account to the list of available accounts. This list of accounts is saved. Note that many of the functions require an account to be on that list. So you should always call `purple_accounts_add()` after creating an account. +### How do I get online with an account? +There are two ways you can do this: + * If you have other accounts online, and you want the new account to have the same status as those, then call `purple_savedstatus_get_current()` to get the current status, and use `purple_savedstatus_activate_for_account()` for the account. + * Otherwise, you can simply do `purple_account_set_status()` to set the status of the account. +An account needs to be enabled before it can be connected. So after doing either of the above, you need to enable the account by calling `purple_account_set_enabled()`. +### How can I create a conversation with someone? +Use `purple_conversation_new()`. Use `PURPLE_CONV_TYPE_IM` if the conversation is an IM (one-to-one person conversation), and use `PURPLE_CONV_TYPE_CHAT` if it's a multi-user conversation. One important thing to note here is that the name property of the `PurpleConversation` struct is the name of the buddy you are creating a conversation with (the documentation states that this is the name of the conversation itself, but it is in fact also the name of the receiving buddy). So a call to `purple_conversation_new()` takes the name of the buddy as its third argument. +### How can I send a message in a conversation? +Use either `purple_conv_im_send()` or `purple_conv_chat_send()`. Note that the first parameter to either of these functions are ***not*** the conversation itself. Rather, it's the IM data or chat data of the conversation which you can get from `PURPLE_CONV_IM`/`PURPLE_CONV_CHAT`. +### Is there a way that I can print something in the conversation window, but not send the message? +Yes. Use `purple_conv_im_write()` or `purple_conv_chat_write()`. +### What do I do with `DATADIR`, `LOCALEDIR`, and `LIBDIR`? +`DATADIR`, `LOCALEDIR`, and `LIBDIR` are defined as functions in the Windows build. Therefore, doing something like this will break the Windows build: + printf("File in DATADIR is: %s\n", DATADIR G_DIR_SEPARATOR_S "pic.png") + printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png"); +### Why are files opened with mode `b`? +Without this, on Windows systems the opened files will use Windows default translation (<CR><LF> for newline, for example). This will cause errors due to newline format and the "bytes read" counts, which will be wrong when comparing the return value of `read()` to `stat()`. +### Why are `G_DIR_SEPARATOR_S` and `G_DIR_SEPARATOR` used everywhere? +This is a matter of maintaining cross-platform compatibility. Windows uses a backslash ("\") for directory separators in paths, while UNIX-like systems use the forward slash ("/"). Other OSes may choose to use other separators--for example, prior to Mac OS X, it was common for the directory separator on Macs to be a colon (":"). +It is impractical to use preprocessor directives throughout the code to determine the path style to use, especially if a new OS were to appear and use a different directory separator. GLib, which we already use, provides the convenient separator macro, so we use this to reduce our code complexity and maintain cross-platform portability. +### What should I do to get the contents of an environment variable? +### Should I use `snprintf()` or `vsnprintf()`? +No. Use the GLib wrapper functions instead. They are `g_snprintf()` and `g_vsnprintf()`. +### How do I get the settings directory? +Use `purple_home_dir()`. You should *not* use `g_get_home_dir()` or `getenv("HOME")`. +### What is the versioning scheme? +**This is already defined elsewhere, we should probably just have a page for it... --grim** +There are three fields in the version: `major.minor.micro`. + * If the `major` is changing, you can break plugins. That means both forward- and backward- compatibility. API can be added or removed or whatever you like. + * If only the `minor` is changing, you can break forward compatibility only. You may add API, but you can't remove it. You can mark API as deprecated instead. + * If only the `micro` is changing, you can't break the API at all. +### Why is win32dep.h causing problems for me? +You need to make sure it is the last header you include if you need to include it. Not doing so is asking for problems. +## Plugins and Protocols +### How should I handle global variables? +Use `G_MODULE_IMPORT` for any global variable located outside your dynamic library. Not doing this will cause "Memory Access Violation" errors on Windows systems. +### What should I do for "exported" functions? +If your plugin has functions that are to be accessed from outside the scope of its file (.dll or .so), `G_MODULE_EXPORT` those functions. --- a/content/gsoc-ideas.md Mon Jan 14 00:04:40 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,25 +0,0 @@
-## Add Voice and Video to the SIP Plugin--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/gsoc/_index.md Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,22 @@
+title: "Google Summer of Code" +date: 2019-01-10T22:32:00-06:00 +Pidgin has been involved in the +[Google Summer of Code](https://summerofcode.withgoogle.com/) for many years +since it was started. This section contains a running list of project ideas as +well as some documentation on our participation for the years we participated. +{{< gsoc year="2015" >}} +{{< gsoc year="2013" >}} +{{< gsoc year="2012" >}} +{{< gsoc year="2010" >}} +{{< gsoc year="2009" >}} +{{< gsoc year="2008" >}} +{{< gsoc year="2007" >}} --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/content/gsoc/ideas.md Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,32 @@
+date: 2019-01-10T22:32:00-06:00 +## Add Voice and Video to the SIP Plugin --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2007.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,43 @@
+ "project": "MonoLoader", + "student": "Eoin Coffey", + "mentor": "Gary Kramlich", + "project": "MySpaceIM Protocol Plugin?", + "student": "Jeffrey Connelly", + "project": "Remote Logging", + "student": "Michael Shkutkov", + "mentor": "Richard Laager", + "status": "Waiting 3.0.0; Needs Work" + "project": "Certificate Manager", + "student": "William Ehlhardt", + "mentor": "Ethan Blanton", + "project": "Finch Improvements", + "student": "Eric Polino", + "mentor": "Sadrul Habib Chowdhury", + "project": "Virtual Classroom over Pidgin", + "student": "Prekshu Ajmera", + "mentor": "Richard Laager", + "project": "Stabilize and improve MSN support", + "student": "Carlos Silva", + "mentor": "Mark Doliner", + "project": "Telepathy", + "student": "Will Thompson", + "mentor": "Robert McQueen", + "status": "Telepathy Haze" --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2008.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,33 @@
+ "project": "Finch spell checking and window manager", + "student": "Mark Schneider", + "mentor": "Sadrul Habib Chowdhury", + "project": "LibPurple theme manager and Pidgin interface improvements", + "student": "Justin Rodriguez", + "mentor": "Gary Kramlich", + "project": "Master password support", + "student": "Vivien Bernet-Rollande", + "mentor": "Richard Laager", + "project": "Improving Yahoo! Implementation of libpurple", + "student": "Sulabh Mahajan", + "mentor": "Mark Doliner", + "project": "Voice and video support", + "student": "Mike Ruprecht", + "project": "Improving XMPP support", + "student": "Tobias Markmann", + "mentor": "Etan Reisner", --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2009.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,38 @@
+ "project": "Telepathy prpl", + "student": "Felix Kerekes", + "mentor": "Will Thompson", + "project": "Windows GUI (High-level Toolkit)", + "student": "Wade Fagen", + "mentor": "Sadrul Chowdhury", + "project": "Privacy Rewrite", + "student": "Sulabh Mahajan", + "mentor": "Ethan Blanton", + "status": "Waiting 3.0.0; Needs Work" + "project": "Struct Hiding and GObjectification", + "student": "Eric Polino", + "mentor": "Gary Kramlich", + "project": "Vulture (lower-level Windows GUI)", + "student": "Gregor Dick", + "mentor": "John Bailey", + "project": "XMPP Transport", + "student": "Jan Kaluza", + "mentor": "Etan Reisner", + "status": "Development continues out-of-tree at http://spectrum.im" + "project": "Webkit Support", + "student": "Arnold Noronha", --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2010.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,23 @@
+ "project": "Improving the ICQ implementation in Pidgin", + "student": "Ivan Komarov", + "mentor": "Mark Doliner", + "project": "Better chat log viewer", + "student": "Adam Fowler", + "mentor": "Daniel Atallah", + "status": "Project wasn't completed." + "project": "Detachable libpurple sessions", + "student": "Gilles Bedel", + "mentor": "Ethan Blanton", + "status": "Waiting for 3.0.0; needs work" + "project": "MSN-prpl refactor and SLP rewrite", + "student": "Jorge Villaseñor Salinas", + "mentor": "Elliott Sales de Andrade", --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2012.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,23 @@
+ "project": "libpurple on Android", + "student": "Michael Zangl", + "mentor": "Mark Doliner", + "status": "Cleaning up" + "project": "Pidgin Plugin Website", + "student": "Nikhil Bafna", + "mentor": "Kevin Stange", + "status": "Never Started" + "project": "Usage Statistic Collection", + "student": "Sanket Agarwal", + "status": "http://stats.pidgin.im/, finished but not merged" + "project": "Gadu-Gadu protocol plugin improvements", + "student": "Tomasz Wasilczyk", + "mentor": "Ethan Blanton", --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2013.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,23 @@
+ "project": "File Transfer Improvements", + "student": "Ashish Gupta", + "mentor": "Mark Doliner", + "status": "GTalk FT Pending Review" + "project": "Easy Plugins Website", + "student": "Bhaskar Kandiyal", + "status": "Community bonding" + "project": "Quail - A QT client for libpurple", + "student": "Phil Hannent", + "mentor": "Elliott Sales de Andrade", + "status": "View status blog" + "project": "GObjectification", + "student": "Ankit Vani", + "mentor": "Ethan Blanton", --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data/gsoc/2015.json Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,33 @@
+ "project": "Port libpurple changes from Instantbird", + "student": "Abel Serrano Juste (akronix)", + "mentor": "Florian Quèze", + "project": "Rewrite chat log backend and frontend", + "student": "Igor Gajowiak (igor.g)", + "mentor": "Tomek Wasilczyk", + "project": "Facebook Messenger Protocol for libpurple", + "student": "James Geboski", + "project": "XMPP prpl improvements", + "student": "Koosha Khajehmoogahi", + "project": "Maintenance hero", + "student": "Michael McConville (mmcc)", + "mentor": "Ethan Blanton", + "project": "Google Hangouts Plugin: Protocol Implementation", + "student": "Nakul Gulati", + "mentor": "Etan Reisner", --- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/layouts/shortcodes/gsoc.html Mon Jan 14 21:38:25 2019 -0600
@@ -0,0 +1,22 @@
+{{ $year := "unknown" }} +{{ with .Get "year"}}{{ $year = . }}<h3 id="gsoc-{{$year}}">{{$year}}</h3>{{end}} + {{- with (index .Site.Data.gsoc $year) }} + <td>{{ .project }}</td> + <td>{{ .student }}</td>
