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

277 lines
4.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"
Add "system buffer" per protocol 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.
2021-08-12 15:43:52 -05:00
#include "ChatProtocolMessages.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"
Add "system buffer" per protocol 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.
2021-08-12 15:43:52 -05:00
#include "ConversationView.h"
#include "MainWindow.h"
#include "NotifyMessage.h"
#include "TheApp.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());
Add "system buffer" per protocol 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.
2021-08-12 15:43:52 -05:00
_InitChatView();
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
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();
Don't archive non-existant protocol icons
2021-08-09 22:10:01 -05:00
if (icon != NULL)
icon->Archive(msg);
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
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);
}
Add "system buffer" per protocol 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.
2021-08-12 15:43:52 -05:00
ConversationView*
ProtocolLooper::GetView()
{
return fSystemChatView;
}
void
ProtocolLooper::ShowView()
{
MainWindow* win = ((TheApp*)be_app)->GetMainWindow();
win->SetConversation(NULL);
win->SetConversationView(fSystemChatView);
}
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
{
Support generally setting own nick, own UserItems 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
2021-08-05 14:10:21 -05:00
if (contact != NULL) {
Misc. tweaks, no functional change
2021-08-01 06:37:25 -05:00
fMySelf = contact;
Support generally setting own nick, own UserItems 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
2021-08-05 14:10:21 -05:00
AddUser(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(),
Add "system buffer" per protocol 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.
2021-08-12 15:43:52 -05:00
fInstance, this);
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);
}
}
Add "system buffer" per protocol 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.
2021-08-12 15:43:52 -05:00
void
ProtocolLooper::_InitChatView()
{
fSystemChatView = new ConversationView();
BMessage clear(kClearText);
fSystemChatView->MessageReceived(&clear);
BMessage init(IM_MESSAGE);
init.AddInt32("im_what", IM_MESSAGE_RECEIVED);
init.AddString("user_name", "Cardie");
init.AddString("body", B_TRANSLATE("I'm rearing to go!"));
fSystemChatView->MessageReceived(&init);
fSystemChatView->ObserveString(STR_ROOM_NAME, fProtocol->GetName());
fSystemChatView->ObserveString(STR_ROOM_SUBJECT, "System buffer");
BBitmap* icon = fProtocol->Icon();
if (icon != NULL)
fSystemChatView->ObservePointer(PTR_ROOM_BITMAP, (void*)icon);
}