remove the files that were already put into place
--- a/content/drafts/design-guidelines.md Mon Jan 14 21:47:05 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,45 +0,0 @@
----
-title: "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
--- a/content/drafts/development-faq.md Mon Jan 14 21:47:05 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,102 +0,0 @@
----
-title: "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/drafts/gsoc-ideas.md Mon Jan 14 21:47:05 2019 -0600
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,28 +0,0 @@
----
-title: "Libpurple"
----
-## Add Voice and Video to the SIP Plugin
