… 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.
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.
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, 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.
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.
Windows using RosterView (like for the invitiation/new chat dialogues)
have a search-box for filtering between contacts. This allows the user
to type a user ID into this search-box that isn't a contact's ID, which
can then be selected as the user.
This makes common operations (inviting a user/adding a new contact)
a little easier.
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.
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
Like the notification sent when accounts are ready (IM_PROTOCOL_READY),
one's been added for when accounds have disconnected/are disabled:
IM_PROTOCOL_DISABLED.
Also, error BAlerts (created with IM_ERROR messages) are now more
detailed, showing the associated accounts' name in the header.
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).
The "room" template has been split into two seperate
templates― "join_room" and "create_room". Before, "room" was used in the
room creation window, but now that's delegated to "create_room".
"join_room" is used with the join window― so now, the add-on has total
control over the slots used to join/create rooms generally, if they
specify the templates. Even a "/join" command could be overriden by the
add-on.
Also, default templates are now in use. Rather than add-ons being
required to specify templates, there are sensible defaults included with
Cardie for each one.
Jaidyn Ann