A new class was added (ChatCommand) to represent commands, which are
all stored in the Server iself.
A command can be assigned any arbitrary BMessage, and can be given
arguments with some semantic meaning (so far just "string" or "room
participant," etc).
"invite" and moderation commands were added (ban/kick/mute etc).
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.
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
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.
Now the user can leave or be forced to leave a chat.
For this, two protocol API messages were added: IM_LEAVE_ROOM, and IM_ROOM_LEFT.
Aside from that, IM_ROOM_BAN_PARTICIPANT and IM_ROOM_KICK_PARTICIPANT
were added, though they aren't used yet.
Two new messages were added to the protocol API to do this:
M_ROOM_PARTICIPANTS, which can be used when someone joins a room, or
on joining a room to send a full list of users, and IM_ROOM_PARTICIPANT_LEFT,
for when a user has left the room/disconnected.
IM_SET_STATUS no longer assumes received data comes from contacts, but
any general user.
UserItem was made to reflect changes in the User's name.
Chat messages can now be reliably received in a given room. :)
Protocol messages was added to the API to allow joining abstract rooms
by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in
anticipation of future room-related calls, some messages' values have
been shifted.
A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in
the main window), to allow joining a room with this protocol message.
The user can select which account the room should be joined from through
a drop-down menu in the lower left-hand corner― a design I think could
be replicated in other parts of Caya well.
Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and
SetAddOnPath() respectively. GetName() and SetName() were also added,
where "name" is the account name (aka the leaf of the protocols settings
path).
To Server, a new KeyMap was added for convenience (AccountInstances), to
associate these account names with their instance IDs.
Now all active conversations will be listed in the main window, in a
ConversationListView. Clicking one of the items will open its
conversation window as you'd expect, etc.
This is a commit with it's foot in a lot of places, but:
The Conversation class was created as the abstraction of chats: All
ImMessages that are relevant to a conversation get routed through it,
meta-data on chats is stored in it (even if right now that's basically
limited to the user list and ID).
Server was given more methods to help accessing contacts―
ContactById(BString) and AddContact(Contact*). This better allows
Conversations to add and fetch Contacts as necessary. Right now, all
users in chats are treated as Contacts, so in the future creating an
independent userlist for Server (fUserMap?) would be useful.
Server also now stores all Conversations (fChatMap) and has some
convenience methods like for Contacts: Conversations(),
ConversationById(BString), and AddConversation(Conversation*).
CayaRenderView has been changed to not store user nicks, and will use
the appropriate nick of any arbitrarily-numbered user.
Users also have a map of all Conversations they are a part of
(fChatMap).
The Remove* methods of KeyMap now return the removed item.
Jaidyn Ann
barrett
plfiorini