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
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." :)
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.
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.
Jaidyn Ann
plfiorini