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.
The base for roster management (RosterEditWindow) has been made, and
adding new contacts works. Up next is contact removal and editing.
This leverages a new template (as defined in a protocol's
CayaProtocol::SettingsTemplate()), "roster," which should contain all
slots pertinent to editing/adding a contact member.
Two new API messages were added for this― IM_CONTACT_LIST_CONTACT_ADDED
and IM_CONTACT_LIST_CONTACT_REMOVED. The former will functionally just
be IM_CONTACT_INFO, but with some semantical meaning.
A new CayaMessage (CAYA_EDIT_ROSTER) was also added.
TemplateWindow was also edited to this end: Now, like RosterWindow/View,
it can be given a specific accounts' instance id, and it will prevent
the selection of another account. A new constructor was also added, to
allow a ProtocolTemplate to be explicitly passed to it― probably from
the program itself.
A nice templating system is used for account settings dialogues― the
required slots are specified by the protocol, and are reflected in the
settings dialogue.
To generalize this templating system (and eventually use elsewhere),
ProtocolSettings was split into two classes― ProtocolSettings and
ProtocolTemplate.
The CayaProtocol::SettingsTemplate() call was also edited to require a
string parameter, naming the specific template that should be returned.
"account" is used for the account settings dialogue, and other values
are TBA.
Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for
registering commands and user-list pop-up items.
The former replaces CayaProtocol::Commands(), which was a real bad idea
in the first place. Just awful. No idea why I did that instead of this,
which is nicer and significantly easier anyway.
With the new use of RoomFlags for signifying whether or not a room's
chat should be populated with local logs (ROOM_POPULATE_LOGS),
SaveLogs() is redundant.
A Commands() method was added to the CayaProtocol class returning a
CommandMap, which will be used by Caya when searching for commands.
KeyList::AddList() and List::AddList() were also added to libsupport,
for convenience.
In the API, a firm distinction between initially fetching a room's
metadata and receiving further changes has been made:
IM_ROOM_METADATA will be sent to Caya on request (IM_GET_ROOM_METADATA)
with the room's name, subject, etc. The other metadata-related messages
should only be sent to Caya after the room is initialized, not as a
means of initially setting its metadata.
Basic room flags were added, though they aren't yet used― they should
allow the protocol/add-on/user to configure some room features. Logging,
auto-joining, etc.
When no accounts are active, all items in the Menubar->Chat menu are
disabled, and some other menu items related to starting/managing chats
are disabled in other views.
One new message was added to the API― IM_PROTOCOL_READY, which tells
Caya that a given protocol has logged in and is ready to receive
messages (rather than just sending).
This is currently done in XMPP after the roster is loaded, which be a
process that stalls the protocol for a few seconds. IM_PROTOCOL_READY
should only be sent after those initial, potentially time-heavy
operations.
Accounts can now be temporarily disabled (in a Pidgin-like style)
through Preferences->Accounts. Work is still required to allow
enabling/re-enabling of accounts on-the-fly, and for keeping an
account's disabled state persistent.
New API messages were added to distinguish between a user leaving of
their own volition and being kicked/banned.
Messages are now shown in the chat view when a user leaves or or
kicked/banned, etc.
Allow kicking/banning/muting/unmuting/deafening and undeafening through
the UserListView right-click menu (if permissions are sufficient).
Support for banning, kicking, and muting were added to the XMPP add-on―
deafening isn't supported, so is left out.
If chat logs are stored in an endless plain-text file, they're going to be a
pain to parse. If they're stored in a binary file, they're a pain for
the user to `grep` or go through manually, but they're easier to parse.
Why not both?
Logs are now stored with a BMessage (with BStringLists) in the 'logs'
attribute, and the plain-text logs in the file itself.
The attribute will only store 20 messages, but the file itself will be
appended to forever.
The logs directory also changed, from ~/config/settings/Caya/Cache/Logs
to ~/config/settings/Caya/Logs.
Useful functions for reading/writing messages to and from an attribute were
borrowed from BePodder's libfunky. :-)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.
A new class, Role, represents a user's role in a given room, with three
values:
* The role's title
* The role's permission-set
* The role's priority
The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.
These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.
For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.
This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
Jaidyn Ann