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).
Chat messages can now be formatted with colors in addition to varying
faces with "color_start," "color_length," and "color" slots in
IM_MESSAGE_RECEIVED.
If the user disables an account, this saves it so that on any
subsequent start-ups, the account won't be connected until the user
explicitly re-enables it.
ProtocolSettings were reworked to allow for publicly loading/saving
settings from BMessages, rather than solely from BViews.
In addition, all program-side disabling, enabling, and toggling of
accounts has been consolidated into ProtocolManager. This makes life
easier for other parts of the program that have to do these things
anyway.
Ensures that an item in the chat list is always selected (as long as
there are items to be selected), and that an account's "buffer" (fake
conversation) is added immediately after connection, and removed
immediately after disconnection.
Now addons can format messages with new slots accepted by
IM_MESSAGE_RECEIVED: "face_start," "face_length," and "face".
The first two deal with the position of the face-change by character
offset in the string, and the last being the face flag affected.
Now, per each account, there is a read-only chat view associated with
it, accessible through its item in the conversations list. This can be
used to place system messages, MOTDs, insignificant errors, etc.
Protocols can send text to this buffer by specifying no "chat_id" in
an IM_MESSAGE_RECEIVED message.
Some chat protocol messages' names have been changed to more fitting or
consistent names― e.g., "IM_AVATAR_SET" to "IM_USER_AVATAR_SET", or
"IM_CONTACT_LIST_*" to "IM_ROSTER_*" (to agree with Cardie's usage of
the word).
The API version has been bumped― for the forseeable future (at least
several months, I promise!) no compatibility-breaking changes will be
introduced. Until then, any new feautures or message slots will be
additive and optional.
Seperate UserItems are now created for each list, too, rather than a
single one being created per-user. This functionally works a lot nicer.
But onto more important things… now setting the user's own nick should
work quite well. Finally. =w=
This has given me a good bit of trouble over the past couple of days―
setting the user's nick *worked*, but it wouldn't propagate to its
corresponding UserItem nor its UserInfoDialog. It would, however, work
with the StatusView.
These are all registered Observers of the User itself, so if one works,
they *all* should, them all being registered to the same User.
Now, if a given User isn't found in the ProtocolLooper's user-list,
the Conversation class will take it upon itself to create a new
one and add it to both of their respective lists.
So the user's own contact would be set in the ProtocolLooper― but it
*wouldn't* be added to the user-list.
Hilarity ensues as two seperate objects for the user's own contact would
be created.
Since the StatusView is registered to the ProtocolLooper's "real" own contact
slot, it would receive all updates… but since Conversations' user-lists and
items would be registered to the Conversation-created "fake" user, they
would be borked.
Simple oversight, but wow it hecked with me. :P
Jaidyn Ann