Instead of passing around pointers to the Server, Server::Get() returns
the server's pointer (simplifying some things a good bit).
As a result, headers have been cleaned up, and some redundant KeyMaps
have been placed in Maps.h.
Room flags (e.g., whether or not to auto-join, whether notifications
should be sent on message receive) can now be toggled through a room's
right-click menu in the room-list.
Two new room flags were added for notifications as well― ROOM_NOTIFY_DM
and ROOM_NOTIFY_ALL. If ROOM_NOTIFY_DM is enabled, the user will receive
notifications if they are in a one-on-one chat. If ROOM_NOTIFY_ALL, they
will receive notifications on every message sent to the room.
The default menu items for the room's pop-up menu were moved from
Templates.rdef to be built into the app.
Everything else in Templates.rdef should follow suit― B_TRANSLATE
can't be used in rdef files!
If a message/event is sent to a room that's tied to a user that hasn't
been formally declared (through IM_ROOM_PARTICIPANTS or
IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept
anymore.
Now, after adding an implicit user, the participant list will be
requested again― upon receiving the list, all implicitly-defined users
will be removed. If they really existed to begin with, they should be
re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS.
Ghosts should be treated as ghosts, not users.
If a room doesn't have a set icon (and it isn't a one-on-one chat, for
which the icon'll come from the other user's avatar), the default icon
is now determined based on user count.
If there's X users, an icon with X people will be displayed, up to four.
After that, a "+" is overlayed on the icon.
Not really necessary… but I think it's cute. :-)
If the user has permission to change a room's subject or name, they can
now edit the text views displaying them (toward the top of the window).
When enter is pressed, the changes will be sent to the protocol.
To do this, a BTextView subclass was added to libinterface
(splitting somewhat from SendTextView)― EnterTextView sends a message
containing the text to the given target when the user hits enter sans
modifiers.
For one-on-one chats without a custom icon, the other user's avatar will
be used as the chat's icon.
A default chat icon was also added
(haiku/data/artwork/icons/WebsiteComments).
When a new message is posted (or the user is messaged), the room's item
in the roomlist is now highlighted, like Vision.
Chat also auto-scrolls when new messages are posted.
It doesn't make sense to lump the user themself with their contacts
list― their Contact object is now stored seperately.
BBitmap loading for RosterItems are fixed, as well.
Fixes#33
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).
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.
Rooms are now cached in ~/config/settings/Caya/Cache/$account/Rooms/,
with each file representing a seperate room. The filename is used as the
identifier, and these files now also serve as log files. The log
attribute name has also changed from "logs" to "Caya:logs".
When a protocol has succesfuly connected, all cached rooms are
automatically joined.
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.
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.
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. :)
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.
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.
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.
Jaidyn Ann