> @section getting_started Getting Started
> To develop a plugin you need to have the gaim source code. It is generally a
> good idea to compile against the same version of gaim that you are running.
> You may also want to develop against CVS. While we do NOT recomend this for
> normal users, but there is an exception for developers. A lot tends to
> change between versions and it's much easier to fix your plugin as things
> change rather than waiting until the release. But please do not abuse CVS.
> Gaim puts a lot of strain on Source Forge's servers, and we do not need to
> add anymore to it.
This paragraph should probably mention something about gaim's versioning
scheme, since it talks about CVS and gaim versions. It is important that
plugin developers understand how the versioning scheme effects them.
> If you choose not to head my warnings and develop against a version of gaim
> that is different from what you're running, then you're gaim source must at
> the very least be configured. Note that just running configure will
> generally set the prefix to /usr/local. This shouldn't be a problem, except
> that most packages compile and install gaim with /usr as the prefix.
Something about -dev packages should be mentioned here, and again the
It probably makes good sense to develop against the 1.0.0 headers, and
test with both 1.0.0 and
latest 1.y.z, for example.
> All plugins must have @c GAIM_PLUGINS defined. You can choose to include
> @c internal.h to do this, but if you choose to do it this way it must be
> included before any other gaim files. Likewise, if you choose to manually
> define @c GAIM_PLUGINS, the definition must be before including any gaim
> files. Failure to do so will produce the 'plugin foo could not be loaded for
> an unknown reason'. This is one of the hardest unknown reasons to track
> down, so let's try to avoid it at all costs ;)
I think we should instead say DON'T INCLUDE INTERNAL.H FROM ANY 3RD
PARTY PLUGIN. Otherwise they get things like the binreloc macros and the
gettext macros, which can only cause problems. If plugins need
internal.h so bad, we can write a special header just for them that does
what they need from internal.h without the stuff that is poisen to them.
> Okay, so what does all this mean? We start off by defining @c GAIM_PLUGINS
> like described before. Next we include glib.h, mainly for gboolean and the
> glib wrappers of the standard c types. We could just use stdio and use
> an int for the gboolean but since gaim uses glib internally, we might as
> well do the same.
Gaim exposes glib in its api, so chances are good glib will be needed to
> NULL, /* This field is the ui requirement. This
> value should be a string. If you're
> writing a core plugin, this should be NULL
> and the plugin should not contain any ui
> specific code. If you're writing a gtk
You might want to explain how you disable the hello message while still
not depending on any UI.
> plugin, you can use the
> GAIM_GTK_PLUGIN_TYPE macro. All other ui
> plugins are dependent on their ui
> implementation, and is outside the scope of
> this howto.
> GAIM_PRIORITY_DEFAULT, /* This is the priority gaim with give your
> plugin. There are three possible values
> for this field, GAIM_PRIORITY_DEFAULT,
> GAIM_PRIORITY_HIGHEST, and
What does this priority thing do?