Since ConversationViews were manually removed/added previously, now
that a BCardLayout is used, the visibility-detection/some actions
change (e.g., using BView::Show instead of BView::AttachedToWindow).
… openable through menu-bar as Program→Help.
Following Humdinger's lead here, he did a bang-up job on Calendar's docs!
His code for opening documentation in Calendar is re-used here, too.
Now, instead of using Utils.cpp's AccountCachePath and AddOnCachePath,
and add-on should implement ChatProtocol::SetAccountCachePath and
ChatProtocol::SetAddOnCachePath.
In addition, most path-related functions in Utils now return BPaths― and
some of interest to chat add-ons can accept the path given by
ChatProtocol::SetAccountCachePath as the main argument.
Just the scaffolding of a Matrix protocol using mtxclient: Room-joins
and (unencrypted) messages can be received, but everything's read-only
as yet. More to come!
In Chat-O-Matic, text messages are enqueued by the ConversationView
and appended when the ConversationView becomes attached to the window
(editing a non-attached BTextView doesn't go well).
Previously, only the receive-time was added to the enqueued message― so
that if the view doesn't come into focus for a long while after message
receipt, the timestamp is still accurate. The user's nickname and color
weren't added as well, meaning that if the user left the room before the
message was appended, the ugly user-id and default user color would be
used instead.
This appends user_color and user_name.
The room directory window now has an accounts menu, to allow the user to
filter rooms by account― and a "category" column has been added, which can
optionally be filled by the protocol for more semantic sorting of rooms
(Through "category" slot of IM_ROOM_DIRECTORY).
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.
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!
Now a notification is sent as soon as a protocol has been readied
(before connection established), and all status notifications use the
same message ID to avoid spamming the poor user.
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.
Binary logs are no longer stored as a single message with a list of
strings and int64s ("body", "user_name", "user_id", "when"), but a
message with sub-messages (IM_MESSAGE_RECEIVED) verbatim saved.
This has the main benefit of preserving message formatting (coloring,
bold, italics, etc).
Jaidyn Ann
begasus