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.
Roster members' can now be edited (through Roster->Edit Roster / CMD+R)
TemplateWindows can now be populated through sending any IM_MESSAGE to
it (it will assume the slots of the message correspond to the
template's).
IM_CONTACT_LIST_ADDED_CONTACT was removed (for redundancy), and
IM_CONTACT_LIST_EDIT_CONTACT was added.
The base for roster management (RosterEditWindow) has been made, and
adding new contacts works. Up next is contact removal and editing.
This leverages a new template (as defined in a protocol's
CayaProtocol::SettingsTemplate()), "roster," which should contain all
slots pertinent to editing/adding a contact member.
Two new API messages were added for this― IM_CONTACT_LIST_CONTACT_ADDED
and IM_CONTACT_LIST_CONTACT_REMOVED. The former will functionally just
be IM_CONTACT_INFO, but with some semantical meaning.
A new CayaMessage (CAYA_EDIT_ROSTER) was also added.
TemplateWindow was also edited to this end: Now, like RosterWindow/View,
it can be given a specific accounts' instance id, and it will prevent
the selection of another account. A new constructor was also added, to
allow a ProtocolTemplate to be explicitly passed to it― probably from
the program itself.
Most of RosterWindow's special functions have been split into a special
BGroupView (including both the roster search-box and roster list),
RosterView.
This will give some more flexibility in other uses of the roster list.
In addition, RosterViews can be tied to a specific account by its
looper's instance ID, allowing it to either show all contacts (globally;
if the ID is set to -1) or only those of the specified account.
This can be useful, for example, when inviting contacts to a room―
you can only invite contacts that use the same protocol, and are
associated with your account, so showing all contacts doesn't make
sense.
The SearchBarTextControl class was removed, as it isn't particularly
necessary.
Explicit room-creation using protocol's own "room" template is now
supported.
Two new protocol API messages were added― IM_CREATE_ROOM and
IM_ROOM_CREATED, which are parallels to IM_CREATE_CHAT and
IM_CHAT_CREATED. Rather than the latter two, though, these are wholy
based on the "room" template― their slots are completely determined by
the protocol.
A generic "TemplateWindow" was created, which allows catch-all creation
of windows that leverage protocols' templates. It's used for the
room-creation window (Chat->New Room / Alt+N), for example.
At some point, it ideally should replace even the JoinRoom window, and
maybe others.
A nice templating system is used for account settings dialogues― the
required slots are specified by the protocol, and are reflected in the
settings dialogue.
To generalize this templating system (and eventually use elsewhere),
ProtocolSettings was split into two classes― ProtocolSettings and
ProtocolTemplate.
The CayaProtocol::SettingsTemplate() call was also edited to require a
string parameter, naming the specific template that should be returned.
"account" is used for the account settings dialogue, and other values
are TBA.
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).
This makes it so RunView's built-in timestamps are used― but requires
that a time_t be sent with each newly-appended line. This allows for lines to
be backdated or forward-dated.
Add a program-wide avatar cache― whenever a contact or user's avatar has
changed, it gets cached in ~/config/settings/Caya/Cache/$account/People
(for contacts) or $account/Users (for everyone else).
ImageCache is now used, only for caching the kPersonIcon resource image―
it might be useful later for other commonly used images (status
indicators, etc).
Fixes#4
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.
The ConversationListView is now an BOutlineListView, and rooms are
added as subitems to the item of their associated account. Right now,
account items aren't selectable or useful.
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.
A BAlert is used to inform the user of room invitations― InviteDialogue―
and to send their response directly to the protocol's looper.
Some new protocol messages were added (and older ones were moved around
to compenstate)― IM_ROOM_SEND_INVITE, IM_ROOM_INVITE_REFUSED,
IM_ROOM_INVITE_RECEIVED, IM_ROOM_INVITE_ACCEPT, and
IM_ROOM_INVITE_REFUSE.
Allows custom colors to be dictated to RunView directly from
CayaRenderView. Some colors that were reliant on hard-coded theme
have been replaced with system colors.
New API messages were added to distinguish between a user leaving of
their own volition and being kicked/banned.
Messages are now shown in the chat view when a user leaves or or
kicked/banned, etc.
Allow kicking/banning/muting/unmuting/deafening and undeafening through
the UserListView right-click menu (if permissions are sufficient).
Support for banning, kicking, and muting were added to the XMPP add-on―
deafening isn't supported, so is left out.
Jaidyn Ann