jadedctrl/Chat-O-Matic
jadedctrl/ Chat-O-Matic
1
0
Disbranĉigi 0
Fontkodo Issues 20 Tirpetoj Actions Packages Projects Eldonoj 2 Wiki Activity
Chat-O-Matic/application/ProtocolLooper.cpp

228 lines
3.7 KiB
C++
Raw Normal View History

Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
/*
Update copyright year.
2011-12-03 16:38:03 -06:00
* Copyright 2009-2011, Andrea Anzani. All rights reserved.
* Copyright 2009-2011, Pier Luigi Fiorini. All rights reserved.
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
* Copyright 2021, Jaidyn Levesque. All rights reserved.
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
* Distributed under the terms of the MIT License.
*
* Authors:
* Andrea Anzani, andrea.anzani@gmail.com
* Pier Luigi Fiorini, pierluigi.fiorini@gmail.com
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
* Jaidyn Levesque, jadedctrl@teknik.io
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
*/
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
#include "ProtocolLooper.h"
Redesign add-on disconnection 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." :)
2021-07-18 17:52:36 -05:00
#include <Bitmap.h>
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
#include <String.h>
#include "Account.h"
Redesign add-on disconnection 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." :)
2021-07-18 17:52:36 -05:00
#include "AppMessages.h"
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
#include "Conversation.h"
Group rooms in roomlist by account 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.
2021-06-11 17:24:04 -05:00
#include "ConversationAccountItem.h"
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
Change class names
2021-06-20 12:44:20 -05:00
ProtocolLooper::ProtocolLooper(ChatProtocol* protocol, int64 instance)
Fix some style violations.
2010-05-19 17:28:26 -05:00
:
BLooper(),
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
fProtocol(protocol),
Group rooms in roomlist by account 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.
2021-06-11 17:24:04 -05:00
fInstance(instance),
Reformat ChatProtocol, default own contact to null
2021-07-07 10:59:56 -05:00
fListItem(NULL),
fMySelf(NULL)
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
{
Account* account = reinterpret_cast<Account*>(
protocol->MessengerInterface());
Reloading of protocol's commands on request 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.
2021-07-05 23:53:46 -05:00
LoadCommands();
Move command/menu-item registration to call 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.
2021-06-20 01:24:34 -05:00
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
BString name(protocol->FriendlySignature());
name << " - " << account->Name();
SetName(name.String());
Run();
}
Support temporary disabling of accounts 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.
2021-06-11 20:33:28 -05:00
ProtocolLooper::~ProtocolLooper()
{
Redesign add-on disconnection 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." :)
2021-07-18 17:52:36 -05:00
BMessage* msg = new BMessage(APP_ACCOUNT_DISABLED);
BBitmap* icon = fProtocol->Icon();
icon->Archive(msg);
msg->AddString("name", fProtocol->GetName());
fProtocol->MessengerInterface()->SendMessage(msg);
Support temporary disabling of accounts 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.
2021-06-11 20:33:28 -05:00
fProtocol->Shutdown();
delete fProtocol;
}
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
void
ProtocolLooper::MessageReceived(BMessage* msg)
{
if (Protocol()->Process(msg) != B_OK)
BLooper::MessageReceived(msg);
}
Change class names
2021-06-20 12:44:20 -05:00
ChatProtocol*
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
ProtocolLooper::Protocol()
{
return fProtocol;
}
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
ChatMap
ProtocolLooper::Conversations() const
{
return fChatMap;
}
Conversation*
ProtocolLooper::ConversationById(BString id)
{
bool found = false;
return fChatMap.ValueFor(id, &found);
}
void
ProtocolLooper::AddConversation(Conversation* chat)
{
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
if (chat != NULL)
fChatMap.AddItem(chat->GetId(), chat);
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
}
void
ProtocolLooper::RemoveConversation(Conversation* chat)
{
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
if (chat != NULL)
fChatMap.RemoveItemFor(chat->GetId());
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
}
RosterMap
ProtocolLooper::Contacts() const
{
return fRosterMap;
}
Contact*
ProtocolLooper::ContactById(BString id)
{
bool found = false;
return fRosterMap.ValueFor(id, &found);
}
void
ProtocolLooper::AddContact(Contact* contact)
{
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
if (contact != NULL)
fRosterMap.AddItem(contact->GetId(), contact);
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
}
Removal of roster members 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.
2021-06-19 22:37:20 -05:00
void
ProtocolLooper::RemoveContact(Contact* contact)
{
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
if (contact == NULL)
return;
Removal of roster members 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.
2021-06-19 22:37:20 -05:00
fRosterMap.RemoveItemFor(contact->GetId());
fUserMap.AddItem(contact->GetId(), (User*)contact);
}
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
UserMap
ProtocolLooper::Users() const
{
UserMap users = fUserMap;
for (int i = 0; i < fRosterMap.CountItems(); i++) {
User* user = (User*)fRosterMap.ValueAt(i);
users.AddItem(user->GetId(), user);
}
return users;
}
User*
ProtocolLooper::UserById(BString id)
{
bool found = false;
User* user = ContactById(id);
if (user == NULL)
user = fUserMap.ValueFor(id, &found);
return user;
}
void
ProtocolLooper::AddUser(User* user)
{
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
if (user != NULL)
fUserMap.AddItem(user->GetId(), user);
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
}
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
CommandMap
ProtocolLooper::Commands() const
{
return fCommands;
}
ChatCommand*
ProtocolLooper::CommandById(BString id)
{
return fCommands.ValueFor(id);
}
Remove own user from contacts; fix roster bitmaps 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
2021-07-06 14:46:28 -05:00
Contact*
ProtocolLooper::GetOwnContact()
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
{
return fMySelf;
}
void
Remove own user from contacts; fix roster bitmaps 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
2021-07-06 14:46:28 -05:00
ProtocolLooper::SetOwnContact(Contact* contact)
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
{
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
if (contact != NULL)
fMySelf = contact;
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
}
int64
ProtocolLooper::GetInstance()
{
return fInstance;
}
Group rooms in roomlist by account 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.
2021-06-11 17:24:04 -05:00
ConversationAccountItem*
ProtocolLooper::GetListItem()
{
if (fListItem == NULL)
fListItem = new ConversationAccountItem(fProtocol->GetName(),
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
fInstance);
Group rooms in roomlist by account 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.
2021-06-11 17:24:04 -05:00
return fListItem;
}
Move command/menu-item registration to call 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.
2021-06-20 01:24:34 -05:00
void
Reloading of protocol's commands on request 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.
2021-07-05 23:53:46 -05:00
ProtocolLooper::LoadCommands()
Move command/menu-item registration to call 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.
2021-06-20 01:24:34 -05:00
{
Reloading of protocol's commands on request 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.
2021-07-05 23:53:46 -05:00
fCommands = CommandMap();
Move command/menu-item registration to call 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.
2021-06-20 01:24:34 -05:00
BObjectList<BMessage> commands = fProtocol->Commands();
for (int i = 0; i < commands.CountItems(); i++) {
ChatCommand* cmd = new ChatCommand(commands.ItemAt(i));
fCommands.AddItem(cmd->GetName(), cmd);
}
}