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
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.
Now all account menus will have the pretty protocol icons to go with
them. :)
The icons are scaled to text-size so that they might be displayed in a
corresponding MenuButton, or maybe BMenuField at some point, and put
into the ImageCache.
The menu items do not have ownership of the bitmaps.
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.
/me waves arms in the air like a maniac
/me knocks over a nearby cup of coffee
/me gasps when the coffee spills onto the adjacent laptop
/me cries out “Fore! Wait, four! Wait, fire!” when the laptop bursts
into flames
/me burns to a crisp
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. :-)
Jaidyn Ann