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.
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.
If the user has permission to change a room's subject or name, they can
now edit the text views displaying them (toward the top of the window).
When enter is pressed, the changes will be sent to the protocol.
To do this, a BTextView subclass was added to libinterface
(splitting somewhat from SendTextView)― EnterTextView sends a message
containing the text to the given target when the user hits enter sans
modifiers.
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.
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
Sometimes a protocol's commands are dynamic, or change based on certain
events― and it's necessary in these cases that commands be reloaded.
The IM_PROTOCOL_RELOAD_COMMANDS message is now added to the API, which
will force Cardie to reload commands from the protocol.
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.
Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for
registering commands and user-list pop-up items.
The former replaces CayaProtocol::Commands(), which was a real bad idea
in the first place. Just awful. No idea why I did that instead of this,
which is nicer and significantly easier anyway.
With the new use of RoomFlags for signifying whether or not a room's
chat should be populated with local logs (ROOM_POPULATE_LOGS),
SaveLogs() is redundant.
A Commands() method was added to the CayaProtocol class returning a
CommandMap, which will be used by Caya when searching for commands.
KeyList::AddList() and List::AddList() were also added to libsupport,
for convenience.
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).
In the API, a firm distinction between initially fetching a room's
metadata and receiving further changes has been made:
IM_ROOM_METADATA will be sent to Caya on request (IM_GET_ROOM_METADATA)
with the room's name, subject, etc. The other metadata-related messages
should only be sent to Caya after the room is initialized, not as a
means of initially setting its metadata.
Basic room flags were added, though they aren't yet used― they should
allow the protocol/add-on/user to configure some room features. Logging,
auto-joining, etc.
Rooms are now cached in ~/config/settings/Caya/Cache/$account/Rooms/,
with each file representing a seperate room. The filename is used as the
identifier, and these files now also serve as log files. The log
attribute name has also changed from "logs" to "Caya:logs".
When a protocol has succesfuly connected, all cached rooms are
automatically joined.
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.
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.
Jaidyn Ann