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.
Protocol messages was added to the API to allow joining abstract rooms
by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in
anticipation of future room-related calls, some messages' values have
been shifted.
A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in
the main window), to allow joining a room with this protocol message.
The user can select which account the room should be joined from through
a drop-down menu in the lower left-hand corner― a design I think could
be replicated in other parts of Caya well.
Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and
SetAddOnPath() respectively. GetName() and SetName() were also added,
where "name" is the account name (aka the leaf of the protocols settings
path).
To Server, a new KeyMap was added for convenience (AccountInstances), to
associate these account names with their instance IDs.
Also adds a function to protocols to toggle this― if CayaProtocol::SaveLogs()
returns true, then local logs will be used to popualte conversation
windows. Otherwise, it's up to the protocol itself.
A new protocol IM_MESSAGE was also created, IM_LOGS_RECEIVED, which can
be used to populate conversations with old logs.
Now an add-on can contain multiple protocols, and the protocol API has
changed. An add-on must now export protocol_count() and protocol_at(),
with the latter replacing protocol(). protocol_count() returning the
amount of protocols in a given add-on, and protocol_at(i) giving a
new CayaProtocol* "at" the given index.
CayaProtocol has also been changed, adding Signature(),
FriendlySignature(), Icon(), Path(), and SetPath(). The reasoning is
that different protocols (even within a single add-on) will have
different signatures and icons, so this data should be accessible from
the protocol itself.
CayaProtocolAddOn now has CountProtocols() and ProtocolAt(i), allowing
the accessing of multiple protocols. A CayaProtocolAddOn can be given a
default protocol index in the constructor, whose protocol will be
returned with Protocol(). Version() was also moved from CayaProtocol to
CayaProtocolAddOn.
Jaidyn Ann
plfiorini