This window (Chat→Room directory) is to be used for either a list of
publicly available rooms (in most protocols), or for a list of
joined-but-hidden rooms (as it'll used with libpurple, to list its
ChatBuddies).
Each room is sent individually from protocols using IM_ROOM_DIRECTORY
messages sent in response to a IM_GET_ROOM_DIRECTORY message.
Now the StatusView (bottom-left corner, right below the room list) can
be used to set the nickname and status not only for all accounts at
once, but for managing the status/nick of individual accounts.
AccountManager now can set details of a single account, too.
MainWindow is no longer an Observer (as it just passed the information
along to StatusView― now StatusView manages that itself).
NicknameTextControl was removed, not being in use.
StatusView now allows the selecting of accounts through a MenuButton
with BitmapMenuItems― the button for selecting an account is nice and
discrete, just showing the bitmap of a protocol (in leiu of a label).
No functional changes, other than this menu.
I tried making all AccountsMenus use BitmapMenuItems, but that gets
unweildy pretty quickly― for now they remain in this menu. Maybe
optional ownership of bitmaps in BitmapMenuItems and caching of protocol
items would help.
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. :-)
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).
CreateAccountMenu() is used to populate a BMenu with items corresponding
to the map of accounts provided to it― but when an account is disabled
or enabled, it can't update automatically.
A dedicated class, fAccountsMenu, now replaces it― it'll automatically
repopulate the list whenever the active accounts update.
The BTextBox used for sending messages has been moved from the main
window to individual ConversationViews, allowing seperate histories,
texts, etc., to exist in different conversations.
EditingFilter (a filter that hooked into MainWindow) was previously used
to field special key combos with this textbox, including "ENTER" for
sending, but this has been replaced with a new textview subclass
(SendTextView).
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.
Most of RosterWindow's special functions have been split into a special
BGroupView (including both the roster search-box and roster list),
RosterView.
This will give some more flexibility in other uses of the roster list.
In addition, RosterViews can be tied to a specific account by its
looper's instance ID, allowing it to either show all contacts (globally;
if the ID is set to -1) or only those of the specified account.
This can be useful, for example, when inviting contacts to a room―
you can only invite contacts that use the same protocol, and are
associated with your account, so showing all contacts doesn't make
sense.
The SearchBarTextControl class was removed, as it isn't particularly
necessary.
Explicit room-creation using protocol's own "room" template is now
supported.
Two new protocol API messages were added― IM_CREATE_ROOM and
IM_ROOM_CREATED, which are parallels to IM_CREATE_CHAT and
IM_CHAT_CREATED. Rather than the latter two, though, these are wholy
based on the "room" template― their slots are completely determined by
the protocol.
A generic "TemplateWindow" was created, which allows catch-all creation
of windows that leverage protocols' templates. It's used for the
room-creation window (Chat->New Room / Alt+N), for example.
At some point, it ideally should replace even the JoinRoom window, and
maybe others.
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.
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).
The ConversationListView is now an BOutlineListView, and rooms are
added as subitems to the item of their associated account. Right now,
account items aren't selectable or useful.
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.
A BAlert is used to inform the user of room invitations― InviteDialogue―
and to send their response directly to the protocol's looper.
Some new protocol messages were added (and older ones were moved around
to compenstate)― IM_ROOM_SEND_INVITE, IM_ROOM_INVITE_REFUSED,
IM_ROOM_INVITE_RECEIVED, IM_ROOM_INVITE_ACCEPT, and
IM_ROOM_INVITE_REFUSE.
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.
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.
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