---

title: FAQ

date: 2017-09-19T03:57:30.000Z

anchor: development-faq

replaces:

- developer.pidgin.im/wiki/Development%20FAQ

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:

* 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()`.

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.

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`.

Yes. Use `purple_conv_im_write()` or `purple_conv_chat_write()`.

`DATADIR`, `LOCALEDIR`, and `LIBDIR` are defined as functions in the Windows

build. Therefore, doing something like this will break the Windows build:

Instead, it should be:

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()`.

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.

Use `g_getenv()`.

No. Use the GLib wrapper functions instead. They are `g_snprintf()` and

`g_vsnprintf()`.

Use `purple_home_dir()`. You should *not* use `g_get_home_dir()` or

`getenv("HOME")`.

**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.

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.

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.

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.