The IRC add-on previously used libircclient, which is becoming inactive,
and newer versions don't compile on Haiku easily. A fresh rewrite seems
to be a better option.
So far it only supports basic connection and receiving the MOTD. :p
Some chat protocol messages' names have been changed to more fitting or
consistent names― e.g., "IM_AVATAR_SET" to "IM_USER_AVATAR_SET", or
"IM_CONTACT_LIST_*" to "IM_ROSTER_*" (to agree with Cardie's usage of
the word).
The API version has been bumped― for the forseeable future (at least
several months, I promise!) no compatibility-breaking changes will be
introduced. Until then, any new feautures or message slots will be
additive and optional.
Since libpurple doesn't mark individual account settings as "required"
or not (Pidgin will accept account settings even with all-blank answers,
unlike Cardie), every setting was marked as required by Cardie, just to
err on the side of caution.
But that's not necessary now, and was bad to begin with (especially for
Jabber, etc, with superfluous options)― in the case of libpurple, we can
follow Pidgin's example. Cardie will accept account settings with
mostly-blank options, but the add-on will send an error (and disable the
account) when it doesn't work.
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
Connection errors are now sent to Cardie through an IM_ERROR message
(which appear in a BAlert), and an IM_PROTOCOL_DISABLED IM_MESSAGE is
sent to Cardie when the account is disabled/connection fails.
Pidgin's icon has been borrowed as the add-on's icon― and protocol icons
are taken from `$DATA_DIR/pixmaps/Pidgin/protocol/`, just as
Pidgin/libpurple installs them.
Any third-party plugins will also install their icons there, even
if just locally.
I've updated the libpurple package to include these icons, hopefully
that'll get merged.
Since moderation commands are implemented per-protocol in libpurple
(with no easy way to use with the catch-all IM_ROOM_BAN_PARTICIPANT
message and corresponding command), the PERM_BAN, PERM_KICK, and a
couple other moderative perms aren't afforded to the user, disabling
these non-functional options in the UI.
The commands can still be implemented by the libpurple plugin, though.
If they aren't, purple will complain with some error message.
The "room" template has been split into two seperate
templates― "join_room" and "create_room". Before, "room" was used in the
room creation window, but now that's delegated to "create_room".
"join_room" is used with the join window― so now, the add-on has total
control over the slots used to join/create rooms generally, if they
specify the templates. Even a "/join" command could be overriden by the
add-on.
Also, default templates are now in use. Rather than add-ons being
required to specify templates, there are sensible defaults included with
Cardie for each one.
Jaidyn Ann