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.
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.
The conversation view now displays the protocol icon and room subject.
Messages for receiving room names (IM_ROOM_NAME) and subjects
(IM_ROOM_SUBJECT) were added, and support for the latter was given to
the XMPP add-on.
New message APIs were added, and several (room-related) im_what values were
moved into the 150s/160s.
UserItem::_TintColor() was moved to CayaUtils, because it can be used in
several different contexts.
The new Notifier→Observer relation chain:
* Conversation → ConversationItem, ConversationView
* User → UserListItem, UserInfoWindow, UserPopUp
* Contact → RosterItem
These line up pretty intuitively― if something changes in the conversation, you
want the list item and view to change too.
But there's one more here that's less intuitive:
* User → Conversation
If Conversation observes something from a user (i.e., status change), it
immediately knows to do one thing only: invalidate the user list, because
something's changed.
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. :)
Adds basic support for joining MUCs― so basic that Caya won't even tell
the user they've joined, and messages can't be received.
The scaffolding for further MUC development was added, and some
much-needed error-handling for stanzas has been created.
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.
UserListView and UserItem were added as the backbone of the user-list,
and the (currently unused) Caya message CAYA_SEND_INVITE was established
for inviting users to rooms.
Some menus were reworked (e.g., pop-ups of the RosterListView) or
generally tweaked to be more sensical or consistent.
ALT-↑ and ALT-↓ change the active conversation, based on its position
in the main window's ConversationListView. If a conversation is
registered by the main window, and no other conversation is selected, it
is automatically selected.
Now all instances of sending messages (bar status changes) to a
conversation's CayaRenderView only happen when attached to the window.
Messages sent by user appear after the protocol confirms it's been sent
(IM_MESSAGE_SENT), rather than appearing right after the user sends it
to the protocol (IM_SEND_MESSAGE).
Logs are now re-enabled (since they can safely be appended under any
circumstance).
Removes explicit setting of sizes in ConversationView and StatusView,
allowing them to be resized appropriately. Also rearranges StatusView
somewhat, so that it's more friendly to smaller sizes. (The avatar is
moved from being beside the status menu field to being beside the
nickname textbox.)
All chats now stay in a single window, which removes and switches its
current ConversationView with the appropriate one using
Conversation::GetView().
This is a stepping-stone to merging the ChatWindow into the MainWindow.
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.
The roster list is now split from MainWindow into RosterWindow, which
can be used arbitrarily for selecting something from contacts. The
im_what, title, and target can be specified.
Right now it's in use under the Chat menu, "New chat…". Chats can only
have two members (DM/PM), so "New chat…" directly leads to the roster
list.
In the future, roster list might be extended to allow specification of
non-contact users based on their identifiers, or filtering based on
protocol/account― this could help it with "invites" to future rooms,
etc.
IM_CREATE_CHAT and IM_CHAT_CREATED were also added to the protocol API,
allowing a new chat to be explicitly created from Caya or the protocol.
Also adds a function to protocols to toggle this― if CayaProtocol::SaveLogs()
returns true, then local logs will be used to popualte conversation
windows. Otherwise, it's up to the protocol itself.
A new protocol IM_MESSAGE was also created, IM_LOGS_RECEIVED, which can
be used to populate conversations with old logs.
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.
This dichotomy is useful and necessary in multi-user chats, so I split
Contact into a parent class, User. User should be used for generic
members of rooms, Contact used mainly with the roster.
Jaidyn Ann