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.
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.
If the user's in a one-on-one chat, notify on every message― otherwise,
only notify when the user's name/ID is mentioned by another user.
Notifications should be managed by roomflags, but that's for another
time.
Base-level replacement of the Vision-derived text RunView― a couple
important features supported by the replacee haven't been implemented yet,
including:
* Right-click menu
* URL-highlighting/selection
* Emote support
The StatusView (below the roomlist) now shows a default icon if no
accounts have associated avatars, and will use an account's cached avatar
if available.
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).
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
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.
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 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).
This makes it so RunView's built-in timestamps are used― but requires
that a time_t be sent with each newly-appended line. This allows for lines to
be backdated or forward-dated.
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.
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.
Allows custom colors to be dictated to RunView directly from
CayaRenderView. Some colors that were reliant on hard-coded theme
have been replaced with system colors.
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. :-)
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. :)
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.
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.
There's only one little problem that will probably be solved after Alpha1: if you have multiple accounts, all of them will set the avatar icon and the user will see just the last icon set.
* Added BitmapView::Bitmap() method.
* BitmapView::SetBitmap() now doesn't resize the view anymore.
* BitmapView has now a minimum size of 32x32.
* Draw bitmap on BitmapView using B_FILTER_BITMAP_BILINEAR.
* StatusView sets now explicit max and preferred size to 50x50 for the avatar icon view and doesn't resize the bitmap explicitely.
* Small style violation fixes.
Jaidyn Ann
Jérôme Duval
barrett
plfiorini
urnenfeld