The following is a list of Frequently Asked Questions (FAQs), with answers, and notes related to development using LibPurple.
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.
There are two ways you can do this:
purple_savedstatus_get_current()to get the current status, and use
purple_savedstatus_activate_for_account()for the account.
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_CONV_TYPE_IM if the conversation
is an IM (one-to-one person conversation), and use
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.
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
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")
Instead, it should be:
printf("File in DATADIR is: %s%s%s\n", DATADIR, G_DIR_SEPARATOR_S, "pic.png");
Without this, on Windows systems the opened files will use Windows default
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
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.
No. Use the GLib wrapper functions instead. They are
purple_home_dir(). You should not use
This is already defined elsewhere, we should probably just have a page for it… –grim
There are three fields in the version:
majoris changing, you can break plugins. That means both forward- and backward- compatibility. API can be added or removed or whatever you like.
minoris changing, you can break forward compatibility only. You may add API, but you can’t remove it. You can mark API as deprecated instead.
microis changing, you can’t break the API at all.
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.
G_MODULE_IMPORT for any global variable located outside your dynamic
library. Not doing this will cause “Memory Access Violation” errors on Windows
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.