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.
The settings file-hierarchy has been changed a bit:
* Cardie/
* preferences
* Accounts/
* Cache/
* Accounts/
* Add-Ons/
`Cardie/Protocols` is now `Cardie/Accounts`, and the cache directory
has been split into two. `Cache/Accounts/` is for account-specific
cached data (e.g., cached roster icons, data, etc.), and
`Cache/Protocols` is for protocol-wide settings/data.
For purple, this will be used as the user's libpurple directory,
which has been moved from the default of `~/.purple` (yikes!)
Some plugin search-paths have been given to purple, too― lib
directories + "/purple2/", and Cardie/Cache/Add-Ons/purple/plugins/.
Now the purple add-on's starting to come together with a clear
structure:
* Add-on sends IM_MESSAGES etc to the server for processing
* Server sends all (reply/etc) messages to add-on, which sends
to app
It's worth noting that on the add-on's side, no looper or handler is
used for receiving messages, it's all through sending serialized
BMessages to the add-on's connect_thread buffer.
PurpleAccounts are now reliably associated with Cardie's account names
and the thread ID of their respective connect_thread.
The GLib main-loop is gone over regularly thanks to a message runner.
Now, the add-on can log into/create accounts, connect to them, and send
the IM_PROTOCOL_READY notification to Cardie as appropriate.
The libpurple add-on has been split into two parts― a background process
that will actually interface with libpurple, and an add-on that acts as
intermediary between Cardie and the process. This helps prevent
redundancy, and is giving me a lot less trouble that directly loading
libpurple.
The protocol amount and names are now returned by the add-on (through
protocol_count() and protocol_at() respectively)― you can see them in
Preferences' protocol list.
Registration of custom chat commands and menu-items for protocols was
done by the IM_REGISTER_* messages, and is now done through direct calls
to the CayaProtocol object.
The new model for call/message for protocols is this: Temporary
information (chat messages, roster members, etc.) should be accessed
through messages. Relatively static data (protocol name, commands)
should be accessed through direct calls to the protocol object.
Now roster members can be deleted through the RosterEditWindow.
IM_CONTACT_LIST_REMOVED_CONTACT was renamed to
IM_CONTACT_LIST_CONTACT_REMOVED to fit style of other API messages.
Fixes#1.
Roster members' can now be edited (through Roster->Edit Roster / CMD+R)
TemplateWindows can now be populated through sending any IM_MESSAGE to
it (it will assume the slots of the message correspond to the
template's).
IM_CONTACT_LIST_ADDED_CONTACT was removed (for redundancy), and
IM_CONTACT_LIST_EDIT_CONTACT was added.
Jaidyn Ann