2010-05-07 04:47:10 -05:00
|
|
|
/*
|
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.
|
2021-06-15 21:05:21 -05:00
|
|
|
* Copyright 2021, Jaidyn Levesque. All rights reserved.
|
2010-05-07 04:47:10 -05:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
|
*
|
|
|
|
|
* Authors:
|
|
|
|
|
* Andrea Anzani, andrea.anzani@gmail.com
|
|
|
|
|
* Pier Luigi Fiorini, pierluigi.fiorini@gmail.com
|
2021-06-15 21:05:21 -05:00
|
|
|
* Jaidyn Levesque, jadedctrl@teknik.io
|
2011-12-14 17:36:27 -06:00
|
|
|
*
|
|
|
|
|
* Contributors:
|
|
|
|
|
* Dario Casalinuovo
|
2010-05-07 04:47:10 -05:00
|
|
|
*/
|
|
|
|
|
|
2021-06-15 21:05:21 -05:00
|
|
|
#include "Server.h"
|
|
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Application.h>
|
2021-07-19 09:54:27 -05:00
|
|
|
#include <Catalog.h>
|
2010-05-16 16:02:50 -05:00
|
|
|
#include <Debug.h>
|
2021-07-28 19:10:09 -05:00
|
|
|
#include <Directory.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Entry.h>
|
2010-05-30 07:17:32 -05:00
|
|
|
#include <Notification.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Path.h>
|
2021-06-02 16:53:03 -05:00
|
|
|
#include <StringList.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <TranslationUtils.h>
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
#include "Account.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "AppMessages.h"
|
2021-08-04 12:44:20 -05:00
|
|
|
#include "AppPreferences.h"
|
2021-06-22 01:06:00 -05:00
|
|
|
#include "Cardie.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "ChatProtocol.h"
|
2021-08-04 12:44:20 -05:00
|
|
|
#include "ConversationInfoWindow.h"
|
2021-08-12 15:43:52 -05:00
|
|
|
#include "ConversationView.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "ChatProtocolMessages.h"
|
2021-06-30 14:27:58 -05:00
|
|
|
#include "Flags.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "ImageCache.h"
|
2021-06-08 15:32:04 -05:00
|
|
|
#include "InviteDialogue.h"
|
2021-07-21 12:12:02 -05:00
|
|
|
#include "NotifyMessage.h"
|
2021-06-08 15:32:04 -05:00
|
|
|
#include "ProtocolLooper.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "ProtocolManager.h"
|
|
|
|
|
#include "RosterItem.h"
|
2021-08-16 10:40:18 -05:00
|
|
|
#include "StatusManager.h"
|
2021-06-15 21:05:21 -05:00
|
|
|
#include "UserInfoWindow.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "Utils.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
#undef B_TRANSLATION_CONTEXT
|
|
|
|
|
#define B_TRANSLATION_CONTEXT "Server"
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
Server::Server()
|
2010-05-19 17:28:26 -05:00
|
|
|
:
|
2021-06-30 14:27:58 -05:00
|
|
|
BMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-06-30 14:27:58 -05:00
|
|
|
if (fChatItems.IsEmpty() == false || fUserItems.IsEmpty() == false
|
|
|
|
|
|| fCommands.CountItems() > 0)
|
|
|
|
|
return;
|
|
|
|
|
|
2021-08-01 06:37:25 -05:00
|
|
|
BResources res = ChatResources();
|
|
|
|
|
if (res.InitCheck() != B_OK)
|
|
|
|
|
return;
|
2021-06-30 14:27:58 -05:00
|
|
|
|
|
|
|
|
// Loading user pop-up items
|
|
|
|
|
for (int i = 0; i < 6; i++) {
|
|
|
|
|
size_t size;
|
|
|
|
|
BMessage temp;
|
2021-08-01 06:37:25 -05:00
|
|
|
const void* buff = res.LoadResource(B_MESSAGE_TYPE, 1100 + i, &size);
|
2021-06-30 14:27:58 -05:00
|
|
|
temp.Unflatten((const char*)buff);
|
|
|
|
|
fUserItems.AddItem(new BMessage(temp));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Loading room pop-up items
|
2021-08-04 12:44:20 -05:00
|
|
|
for (int i = 0; i < 2; i++) {
|
|
|
|
|
size_t size;
|
|
|
|
|
BMessage temp;
|
|
|
|
|
const void* buff = res.LoadResource(B_MESSAGE_TYPE, 1120 + i, &size);
|
|
|
|
|
temp.Unflatten((const char*)buff);
|
|
|
|
|
fChatItems.AddItem(new BMessage(temp));
|
|
|
|
|
}
|
2021-06-30 14:27:58 -05:00
|
|
|
|
|
|
|
|
// Loading default chat commands
|
|
|
|
|
for (int i = 0; i < 9; i++) {
|
|
|
|
|
size_t size;
|
|
|
|
|
BMessage temp;
|
2021-08-01 06:37:25 -05:00
|
|
|
const void* buff = res.LoadResource(B_MESSAGE_TYPE, 1140 + i, &size);
|
2021-06-30 14:27:58 -05:00
|
|
|
temp.Unflatten((const char*)buff);
|
|
|
|
|
ChatCommand* cmd = new ChatCommand(&temp);
|
2021-06-20 01:24:34 -05:00
|
|
|
fCommands.AddItem(cmd->GetName(), cmd);
|
|
|
|
|
}
|
2021-08-05 19:28:05 -05:00
|
|
|
|
|
|
|
|
fStarted = false;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-19 17:28:26 -05:00
|
|
|
void
|
2010-05-07 04:47:10 -05:00
|
|
|
Server::Quit()
|
|
|
|
|
{
|
2021-06-12 21:42:10 -05:00
|
|
|
for (int i = 0; i < fLoopers.CountItems(); i++)
|
|
|
|
|
RemoveProtocolLooper(fLoopers.KeyAt(i));
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
void
|
|
|
|
|
Server::LoginAll()
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-08-05 19:28:05 -05:00
|
|
|
for (uint32 i = 0; i < fLoopers.CountItems(); i++)
|
|
|
|
|
Login(fLoopers.ValueAt(i));
|
|
|
|
|
fStarted = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
Server::Login(ProtocolLooper* looper)
|
|
|
|
|
{
|
|
|
|
|
BMessage* msg = new BMessage(IM_MESSAGE);
|
|
|
|
|
msg->AddInt32("im_what", IM_SET_OWN_STATUS);
|
|
|
|
|
msg->AddInt32("status", STATUS_ONLINE);
|
2010-05-16 16:02:50 -05:00
|
|
|
|
2021-08-05 19:28:05 -05:00
|
|
|
if (looper != NULL)
|
2010-05-16 16:02:50 -05:00
|
|
|
looper->PostMessage(msg);
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
filter_result
|
|
|
|
|
Server::Filter(BMessage* message, BHandler **target)
|
|
|
|
|
{
|
|
|
|
|
filter_result result = B_DISPATCH_MESSAGE;
|
|
|
|
|
|
2010-05-19 17:28:26 -05:00
|
|
|
switch (message->what) {
|
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
|
|
|
case IM_MESSAGE:
|
|
|
|
|
result = ImMessage(message);
|
|
|
|
|
break;
|
|
|
|
|
case IM_ERROR:
|
|
|
|
|
ImError(message);
|
|
|
|
|
break;
|
|
|
|
|
case APP_ACCOUNT_DISABLED:
|
|
|
|
|
{
|
|
|
|
|
BString name;
|
2021-07-28 19:10:09 -05:00
|
|
|
if (AppPreferences::Get()->NotifyProtocolStatus == true
|
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
|
|
|
&& message->FindString("name", &name) == B_OK) {
|
|
|
|
|
BBitmap* icon = new BBitmap(message);
|
2021-07-19 09:54:27 -05:00
|
|
|
BString content(B_TRANSLATE("%user% has been disabled!"));
|
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
|
|
|
content.ReplaceAll("%user%", name);
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
_SendNotification(B_TRANSLATE("Disabled"), content, icon);
|
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
|
|
|
}
|
2021-07-18 15:39:30 -05:00
|
|
|
break;
|
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
|
|
|
}
|
2021-08-05 20:43:08 -05:00
|
|
|
case APP_ACCOUNT_FAILED:
|
|
|
|
|
{
|
|
|
|
|
BString name;
|
|
|
|
|
if (AppPreferences::Get()->NotifyProtocolStatus == true
|
|
|
|
|
&& message->FindString("name", &name) == B_OK) {
|
|
|
|
|
BBitmap* icon = new BBitmap(message);
|
|
|
|
|
BString content(B_TRANSLATE("%user% has been temporarily disabled."));
|
|
|
|
|
content.ReplaceAll("%user%", name);
|
|
|
|
|
|
|
|
|
|
_SendNotification(B_TRANSLATE("Connection failed"), content, icon);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_REPLICANT_MESSENGER:
|
2011-12-14 17:36:27 -06:00
|
|
|
{
|
2012-02-27 18:46:15 -06:00
|
|
|
BMessenger* messenger = new BMessenger();
|
2011-12-14 17:36:27 -06:00
|
|
|
|
|
|
|
|
status_t ret = message->FindMessenger(
|
2012-02-27 18:46:15 -06:00
|
|
|
"messenger", messenger);
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2012-02-27 18:46:15 -06:00
|
|
|
if (ret != B_OK || !messenger->IsValid()) {
|
2011-12-14 17:36:27 -06:00
|
|
|
printf("err %s\n", strerror(ret));
|
2012-02-27 18:46:15 -06:00
|
|
|
break;
|
2011-12-14 17:36:27 -06:00
|
|
|
}
|
2021-08-16 10:40:18 -05:00
|
|
|
StatusManager* statusMan = StatusManager::Get();
|
|
|
|
|
statusMan->SetReplicantMessenger(messenger);
|
|
|
|
|
statusMan->ReplicantStatusNotify(statusMan->Status());
|
2011-12-14 17:36:27 -06:00
|
|
|
break;
|
|
|
|
|
}
|
2021-08-04 12:44:20 -05:00
|
|
|
case APP_ROOM_INFO:
|
|
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(message);
|
|
|
|
|
if (chat != NULL) {
|
|
|
|
|
ConversationInfoWindow* win = new ConversationInfoWindow(chat);
|
|
|
|
|
win->Show();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_USER_INFO:
|
2021-06-15 21:05:21 -05:00
|
|
|
{
|
|
|
|
|
User* user = _EnsureUser(message);
|
|
|
|
|
if (user != NULL) {
|
|
|
|
|
UserInfoWindow* win = new UserInfoWindow(user);
|
|
|
|
|
win->Show();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_REQUEST_HELP:
|
2021-06-15 00:45:51 -05:00
|
|
|
{
|
|
|
|
|
BString body;
|
|
|
|
|
BString cmd_name = message->FindString("misc_str");
|
2021-06-15 00:59:00 -05:00
|
|
|
int64 instance = message->FindInt64("instance");
|
2021-06-15 00:45:51 -05:00
|
|
|
Conversation* chat = _EnsureConversation(message);
|
|
|
|
|
|
|
|
|
|
if (chat == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (cmd_name.IsEmpty() == false) {
|
2021-06-15 00:59:00 -05:00
|
|
|
ChatCommand* cmd = CommandById(cmd_name, instance);
|
2021-06-15 00:45:51 -05:00
|
|
|
if (cmd == NULL)
|
2021-07-19 09:54:27 -05:00
|
|
|
body = B_TRANSLATE("-- That command doesn't exist. Try "
|
|
|
|
|
"'/help' for a list.\n");
|
2021-06-15 00:45:51 -05:00
|
|
|
else {
|
|
|
|
|
body = "** ";
|
|
|
|
|
body << cmd->GetName() << " ― " << cmd->GetDesc() << "\n";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2021-06-15 14:40:28 -05:00
|
|
|
CommandMap combinedCmds;
|
|
|
|
|
combinedCmds.AddList(fCommands);
|
|
|
|
|
combinedCmds.AddList(chat->GetProtocolLooper()->Commands());
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
body << B_TRANSLATE("** Commands: ");
|
2021-06-15 14:40:28 -05:00
|
|
|
for (int i = 0; i < combinedCmds.CountItems(); i++) {
|
|
|
|
|
ChatCommand* cmd = combinedCmds.ValueAt(i);
|
2021-06-15 00:45:51 -05:00
|
|
|
if (i > 0) body << ", ";
|
|
|
|
|
body << cmd->GetName();
|
|
|
|
|
}
|
|
|
|
|
body << "\n";
|
|
|
|
|
}
|
|
|
|
|
BMessage* help = new BMessage(IM_MESSAGE);
|
|
|
|
|
help->AddInt32("im_what", IM_MESSAGE_RECEIVED);
|
|
|
|
|
help->AddString("body", body);
|
|
|
|
|
help->AddInt64("when", 0);
|
|
|
|
|
chat->ImMessage(help);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-16 16:02:50 -05:00
|
|
|
default:
|
|
|
|
|
// Dispatch not handled messages to main window
|
|
|
|
|
break;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
2010-05-28 17:38:16 -05:00
|
|
|
return result;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
filter_result
|
|
|
|
|
Server::ImMessage(BMessage* msg)
|
2010-05-28 17:38:16 -05:00
|
|
|
{
|
2010-05-07 04:47:10 -05:00
|
|
|
filter_result result = B_DISPATCH_MESSAGE;
|
|
|
|
|
int32 im_what = msg->FindInt32("im_what");
|
|
|
|
|
|
|
|
|
|
switch (im_what) {
|
2021-08-08 21:01:42 -05:00
|
|
|
case IM_ROSTER:
|
2010-05-19 15:37:26 -05:00
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
BString id;
|
2021-05-31 13:04:58 -05:00
|
|
|
while (msg->FindString("user_id", i++, &id) == B_OK)
|
|
|
|
|
_EnsureContact(msg);
|
2010-05-19 15:37:26 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-08-08 21:01:42 -05:00
|
|
|
case IM_ROSTER_CONTACT_REMOVED:
|
2021-06-19 22:37:20 -05:00
|
|
|
{
|
|
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
if (looper == NULL || contact == NULL) {
|
|
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
looper->RemoveContact(contact);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_OWN_STATUS_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
|
int32 status;
|
2021-08-03 13:19:25 -05:00
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (msg->FindInt32("status", &status) != B_OK || looper == NULL)
|
2010-05-07 04:47:10 -05:00
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
|
2021-08-14 11:57:42 -05:00
|
|
|
// If online/offline, send a message to the protocol's buffer.
|
|
|
|
|
if (status == STATUS_OFFLINE || status == STATUS_ONLINE) {
|
|
|
|
|
BMessage info(IM_MESSAGE);
|
|
|
|
|
info.AddInt32("im_what", IM_MESSAGE_RECEIVED);
|
|
|
|
|
info.AddString("user_name", "Cardie");
|
|
|
|
|
if (status == STATUS_OFFLINE)
|
|
|
|
|
info.AddString("body", B_TRANSLATE("Account now offline and disconnected."));
|
|
|
|
|
else
|
|
|
|
|
info.AddString("body", B_TRANSLATE("Account now online!"));
|
|
|
|
|
looper->GetView()->MessageReceived(&info);
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-03 13:19:25 -05:00
|
|
|
Contact* contact = looper->GetOwnContact();
|
|
|
|
|
if (contact != NULL) {
|
2021-08-14 11:57:42 -05:00
|
|
|
// Send notification, if appropriate
|
|
|
|
|
UserStatus oldStatus = contact->GetNotifyStatus();
|
|
|
|
|
if ((oldStatus == STATUS_ONLINE && status == STATUS_OFFLINE)
|
|
|
|
|
|| (oldStatus == STATUS_OFFLINE && status == STATUS_ONLINE))
|
|
|
|
|
{
|
|
|
|
|
if (status == STATUS_ONLINE)
|
|
|
|
|
_ProtocolNotification(looper,
|
|
|
|
|
BString(B_TRANSLATE("Connected")),
|
|
|
|
|
BString(B_TRANSLATE("%user% has connected!")));
|
|
|
|
|
else
|
|
|
|
|
_ProtocolNotification(looper,
|
|
|
|
|
BString(B_TRANSLATE("Disconnected")),
|
|
|
|
|
BString(B_TRANSLATE("%user% is now offline!")));
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-03 13:19:25 -05:00
|
|
|
contact->SetNotifyStatus((UserStatus)status);
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2021-08-03 13:19:25 -05:00
|
|
|
BString statusMsg;
|
|
|
|
|
if (msg->FindString("message", &statusMsg) == B_OK)
|
|
|
|
|
contact->SetNotifyPersonalStatus(statusMsg);
|
|
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
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
|
|
|
case IM_OWN_NICKNAME_SET:
|
|
|
|
|
{
|
2021-08-10 18:03:32 -05:00
|
|
|
BString nick;
|
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
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
2021-08-10 18:03:32 -05:00
|
|
|
if (looper == NULL || msg->FindString("user_name", &nick) != B_OK)
|
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
|
|
|
break;
|
|
|
|
|
Contact* contact = looper->GetOwnContact();
|
|
|
|
|
if (contact != NULL)
|
|
|
|
|
contact->SetNotifyName(nick.String());
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-08-10 18:03:32 -05:00
|
|
|
case IM_USER_NICKNAME_SET:
|
|
|
|
|
{
|
|
|
|
|
BString nick;
|
|
|
|
|
if (msg->FindString("user_name", &nick) != B_OK)
|
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
|
|
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
if (user == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
ChatMap conv = user->Conversations();
|
|
|
|
|
for (int i = 0; i < conv.CountItems(); i++)
|
|
|
|
|
conv.ValueAt(i)->ImMessage(msg);
|
|
|
|
|
|
|
|
|
|
user->SetNotifyName(nick);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-08-08 21:01:42 -05:00
|
|
|
case IM_USER_STATUS_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
|
int32 status;
|
|
|
|
|
|
|
|
|
|
if (msg->FindInt32("status", &status) != B_OK)
|
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
|
2021-06-02 16:53:03 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
if (!user)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
user->SetNotifyStatus((UserStatus)status);
|
2012-03-07 18:47:00 -06:00
|
|
|
BString statusMsg;
|
|
|
|
|
if (msg->FindString("message", &statusMsg) == B_OK) {
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetNotifyPersonalStatus(statusMsg);
|
2012-03-07 18:47:00 -06:00
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-05-31 13:04:58 -05:00
|
|
|
case IM_OWN_CONTACT_INFO:
|
|
|
|
|
{
|
2021-07-06 14:46:28 -05:00
|
|
|
BString id = msg->FindString("user_id");
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (looper == NULL || id.IsEmpty() == true) break;
|
|
|
|
|
|
|
|
|
|
Contact* contact = looper->GetOwnContact();
|
|
|
|
|
if (contact == NULL) {
|
|
|
|
|
contact = new Contact(id, Looper());
|
|
|
|
|
contact->SetProtocolLooper(looper);
|
|
|
|
|
looper->SetOwnContact(contact);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
2021-07-06 14:46:28 -05:00
|
|
|
|
2021-06-21 02:32:49 -05:00
|
|
|
BString name;
|
|
|
|
|
if (msg->FindString("user_name", &name) == B_OK)
|
|
|
|
|
contact->SetNotifyName(name);
|
2021-05-31 13:04:58 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_CONTACT_INFO:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
|
if (!contact)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-16 16:02:50 -05:00
|
|
|
|
2010-05-19 12:11:22 -05:00
|
|
|
const char* name = NULL;
|
|
|
|
|
|
2021-06-07 11:45:30 -05:00
|
|
|
if ((msg->FindString("user_name", &name) == B_OK)
|
2010-05-28 16:31:53 -05:00
|
|
|
&& (strcmp(name, "") != 0))
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyName(name);
|
2012-03-07 13:22:09 -06:00
|
|
|
|
|
|
|
|
BString status;
|
2021-06-07 00:03:15 -05:00
|
|
|
if (msg->FindString("message", &status) == B_OK)
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyPersonalStatus(status);
|
2010-05-28 16:31:53 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IM_EXTENDED_CONTACT_INFO:
|
|
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
|
if (!contact)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-28 16:31:53 -05:00
|
|
|
|
2021-05-24 01:47:21 -05:00
|
|
|
if (contact->GetName().Length() > 0)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-28 16:31:53 -05:00
|
|
|
|
|
|
|
|
const char* name = NULL;
|
|
|
|
|
|
2021-06-07 11:45:30 -05:00
|
|
|
if ((msg->FindString("full_name", &name) == B_OK)
|
2010-05-28 16:31:53 -05:00
|
|
|
&& (strcmp(name, "") != 0))
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyName(name);
|
2021-06-07 11:45:30 -05:00
|
|
|
else if ((msg->FindString("user_name", &name) == B_OK)
|
|
|
|
|
&& (strcmp(name, "") != 0))
|
|
|
|
|
contact->SetNotifyName(name);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-13 14:43:48 -05:00
|
|
|
case IM_OWN_AVATAR_SET:
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
Contact* contact = looper->GetOwnContact();
|
|
|
|
|
entry_ref ref;
|
|
|
|
|
|
|
|
|
|
if (msg->FindRef("ref", &ref) == B_OK) {
|
|
|
|
|
BBitmap* bitmap = BTranslationUtils::GetBitmap(&ref);
|
|
|
|
|
if (bitmap != NULL)
|
|
|
|
|
contact->SetNotifyAvatarBitmap(bitmap);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-08-08 21:01:42 -05:00
|
|
|
case IM_USER_AVATAR_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-31 11:56:45 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
if (!user)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
|
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
entry_ref ref;
|
2010-05-29 23:28:04 -05:00
|
|
|
|
|
|
|
|
if (msg->FindRef("ref", &ref) == B_OK) {
|
|
|
|
|
BBitmap* bitmap = BTranslationUtils::GetBitmap(&ref);
|
2021-05-31 11:56:45 -05:00
|
|
|
user->SetNotifyAvatarBitmap(bitmap);
|
2010-05-29 23:28:04 -05:00
|
|
|
} else
|
2021-05-31 11:56:45 -05:00
|
|
|
user->SetNotifyAvatarBitmap(NULL);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-05-26 07:48:25 -05:00
|
|
|
case IM_CREATE_CHAT:
|
|
|
|
|
{
|
2021-08-15 20:34:30 -05:00
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->PostMessage(msg);
|
2021-05-26 07:48:25 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IM_CHAT_CREATED:
|
|
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
2021-05-31 11:56:45 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
2021-05-26 07:48:25 -05:00
|
|
|
|
|
|
|
|
if (chat != NULL && user != NULL) {
|
|
|
|
|
chat->AddUser(user);
|
2021-05-28 22:26:32 -05:00
|
|
|
chat->ShowView(false, true);
|
2021-05-26 07:48:25 -05:00
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-01 21:43:19 -05:00
|
|
|
case IM_JOIN_ROOM:
|
|
|
|
|
{
|
|
|
|
|
SendProtocolMessage(msg);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-07-29 22:00:01 -05:00
|
|
|
case IM_MESSAGE_RECEIVED:
|
2021-08-12 15:43:52 -05:00
|
|
|
if (msg->HasString("chat_id") == false) {
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->GetView()->MessageReceived(msg);
|
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
}
|
|
|
|
|
case IM_MESSAGE_SENT:
|
2021-07-29 22:00:01 -05:00
|
|
|
case IM_ROOM_JOINED:
|
|
|
|
|
case IM_ROOM_CREATED:
|
|
|
|
|
case IM_ROOM_METADATA:
|
|
|
|
|
case IM_ROOM_ROLECHANGED:
|
2021-08-18 14:18:24 -05:00
|
|
|
case IM_ROOM_PARTICIPANTS:
|
2021-06-07 00:03:15 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_JOINED:
|
2021-06-02 16:53:03 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_LEFT:
|
2021-06-07 00:03:15 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_BANNED:
|
|
|
|
|
case IM_ROOM_PARTICIPANT_KICKED:
|
2021-06-13 01:16:30 -05:00
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (chat != NULL)
|
|
|
|
|
chat->ImMessage(msg);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_NAME_SET:
|
2021-06-06 18:06:46 -05:00
|
|
|
{
|
|
|
|
|
BString name;
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (msg->FindString("chat_name", &name) != B_OK || chat == NULL)
|
|
|
|
|
break;
|
|
|
|
|
chat->SetNotifyName(name.String());
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_SUBJECT_SET:
|
2021-06-04 13:57:04 -05:00
|
|
|
{
|
|
|
|
|
BString subject;
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (msg->FindString("subject", &subject) != B_OK || chat == NULL)
|
|
|
|
|
break;
|
|
|
|
|
chat->SetNotifySubject(subject.String());
|
|
|
|
|
break;
|
2021-06-02 16:53:03 -05:00
|
|
|
}
|
2012-03-11 10:11:29 -05:00
|
|
|
case IM_SEND_MESSAGE:
|
|
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
// Route this message through the appropriate ProtocolLooper
|
2021-05-24 01:47:21 -05:00
|
|
|
Conversation* conversation = _EnsureConversation(msg);
|
|
|
|
|
if (conversation->GetProtocolLooper())
|
|
|
|
|
conversation->GetProtocolLooper()->PostMessage(msg);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
2010-05-16 16:02:50 -05:00
|
|
|
}
|
2021-06-08 15:32:04 -05:00
|
|
|
case IM_ROOM_INVITE_RECEIVED:
|
|
|
|
|
{
|
|
|
|
|
BString chat_id;
|
|
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
BString user_id = msg->FindString("user_id");
|
|
|
|
|
BString user_name = user_id;
|
|
|
|
|
BString chat_name = msg->FindString("chat_name");
|
|
|
|
|
BString body = msg->FindString("body");
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
if (msg->FindString("chat_id", &chat_id) != B_OK || looper == NULL)
|
2021-06-08 19:59:22 -05:00
|
|
|
{
|
2021-06-08 15:32:04 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (chat_name.IsEmpty() == true)
|
|
|
|
|
chat_name = chat_id;
|
|
|
|
|
|
|
|
|
|
if (user != NULL)
|
|
|
|
|
user_name = user->GetName();
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
BString alertBody(B_TRANSLATE("You've been invited to %room%."));
|
2021-06-08 15:32:04 -05:00
|
|
|
if (user_id.IsEmpty() == false)
|
2021-07-19 09:54:27 -05:00
|
|
|
alertBody = B_TRANSLATE("%user% has invited you to %room%.");
|
2021-06-08 15:32:04 -05:00
|
|
|
if (body.IsEmpty() == false)
|
|
|
|
|
alertBody << "\n\n\"%body%\"";
|
|
|
|
|
|
|
|
|
|
alertBody.ReplaceAll("%user%", user_name);
|
|
|
|
|
alertBody.ReplaceAll("%room%", chat_name);
|
|
|
|
|
alertBody.ReplaceAll("%body%", body);
|
|
|
|
|
|
2021-06-08 19:59:22 -05:00
|
|
|
BMessage* accept = new BMessage(IM_MESSAGE);
|
|
|
|
|
accept->AddInt32("im_what", IM_ROOM_INVITE_ACCEPT);
|
2021-06-08 15:32:04 -05:00
|
|
|
accept->AddString("chat_id", chat_id);
|
2021-06-08 19:59:22 -05:00
|
|
|
BMessage* reject = new BMessage(IM_MESSAGE);
|
|
|
|
|
accept->AddInt32("im_what", IM_ROOM_INVITE_REFUSE);
|
2021-06-08 15:32:04 -05:00
|
|
|
reject->AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
|
|
InviteDialogue* invite = new InviteDialogue(BMessenger(looper),
|
2021-07-19 09:54:27 -05:00
|
|
|
B_TRANSLATE("Invitation received"),
|
2021-06-08 15:32:04 -05:00
|
|
|
alertBody.String(), accept, reject);
|
|
|
|
|
invite->Go();
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-08-08 21:01:42 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_STARTED_TYPING:
|
|
|
|
|
case IM_ROOM_PARTICIPANT_STOPPED_TYPING:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-06-08 15:32:04 -05:00
|
|
|
// User* user = _EnsureUser();
|
|
|
|
|
// Conversation* chat = _EnsureConversation();
|
2010-05-07 04:47:10 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-30 07:17:32 -05:00
|
|
|
case IM_PROGRESS:
|
|
|
|
|
{
|
2021-07-18 15:39:30 -05:00
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
2010-05-30 07:17:32 -05:00
|
|
|
const char* protocol = NULL;
|
|
|
|
|
const char* title = NULL;
|
|
|
|
|
const char* message = NULL;
|
|
|
|
|
float progress = 0.0f;
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
if (looper == NULL)
|
2010-05-30 07:17:32 -05:00
|
|
|
return result;
|
|
|
|
|
if (msg->FindString("title", &title) != B_OK)
|
|
|
|
|
return result;
|
|
|
|
|
if (msg->FindString("message", &message) != B_OK)
|
|
|
|
|
return result;
|
|
|
|
|
if (msg->FindFloat("progress", &progress) != B_OK)
|
|
|
|
|
return result;
|
2012-03-08 16:55:13 -06:00
|
|
|
|
2021-07-28 19:10:09 -05:00
|
|
|
if (!AppPreferences::Get()->NotifyProtocolStatus)
|
2012-03-08 16:55:13 -06:00
|
|
|
break;
|
2010-05-30 07:17:32 -05:00
|
|
|
|
|
|
|
|
BNotification notification(B_PROGRESS_NOTIFICATION);
|
2021-06-22 01:06:00 -05:00
|
|
|
notification.SetGroup(BString(APP_NAME));
|
2010-05-30 07:17:32 -05:00
|
|
|
notification.SetTitle(title);
|
2021-07-18 15:39:30 -05:00
|
|
|
notification.SetIcon(looper->Protocol()->Icon());
|
2010-05-30 07:17:32 -05:00
|
|
|
notification.SetContent(message);
|
|
|
|
|
notification.SetProgress(progress);
|
2010-07-03 02:55:23 -05:00
|
|
|
notification.Send();
|
2010-05-30 07:17:32 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-18 15:39:30 -05:00
|
|
|
case IM_NOTIFICATION: {
|
|
|
|
|
_ProtocolNotification(_LooperFromMessage(msg),
|
|
|
|
|
msg->FindString("title"), msg->FindString("message"),
|
|
|
|
|
(notification_type)msg->GetInt32("type",
|
|
|
|
|
B_INFORMATION_NOTIFICATION));
|
2010-05-30 13:56:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-05 23:53:46 -05:00
|
|
|
case IM_PROTOCOL_RELOAD_COMMANDS:
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (looper == NULL) break;
|
|
|
|
|
looper->LoadCommands();
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-12 16:13:52 -05:00
|
|
|
case IM_PROTOCOL_READY:
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
2021-07-05 23:53:46 -05:00
|
|
|
if (looper == NULL) break;
|
2021-06-12 16:13:52 -05:00
|
|
|
|
2021-07-21 12:12:02 -05:00
|
|
|
fAccountEnabled.AddItem(looper->Protocol()->GetName(), true);
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
// Ready notification
|
2021-07-28 19:10:09 -05:00
|
|
|
if (AppPreferences::Get()->NotifyProtocolStatus == true)
|
2021-07-19 09:54:27 -05:00
|
|
|
_ProtocolNotification(looper, BString(B_TRANSLATE("Connected")),
|
|
|
|
|
BString(B_TRANSLATE("%user% has connected!")));
|
2021-06-12 21:42:10 -05:00
|
|
|
|
|
|
|
|
// Join cached rooms
|
|
|
|
|
BEntry entry;
|
|
|
|
|
char fileName[B_FILE_NAME_LENGTH] = {'\0'};
|
2021-07-18 15:39:30 -05:00
|
|
|
BDirectory dir(RoomsCachePath(looper->Protocol()->GetName()));
|
2021-06-12 21:42:10 -05:00
|
|
|
|
|
|
|
|
while (dir.GetNextEntry(&entry, true) == B_OK)
|
|
|
|
|
if (entry.GetName(fileName) == B_OK) {
|
2021-06-13 02:34:11 -05:00
|
|
|
int32 flags;
|
|
|
|
|
BFile file(&entry, B_READ_ONLY);
|
|
|
|
|
if (file.InitCheck() != B_OK)
|
|
|
|
|
continue;
|
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
if (file.ReadAttr("Chat:flags", B_INT32_TYPE, 0, &flags,
|
2021-06-13 02:34:11 -05:00
|
|
|
sizeof(int32)) < 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!(flags & ROOM_AUTOJOIN) && !(flags & ROOM_AUTOCREATE))
|
|
|
|
|
continue;
|
|
|
|
|
|
2021-06-12 21:42:10 -05:00
|
|
|
BMessage join(IM_MESSAGE);
|
2021-06-13 02:34:11 -05:00
|
|
|
int32 im_what = IM_JOIN_ROOM;
|
|
|
|
|
if (flags & ROOM_AUTOCREATE) {
|
|
|
|
|
im_what = IM_CREATE_CHAT;
|
|
|
|
|
join.AddString("user_id", fileName);
|
|
|
|
|
}
|
|
|
|
|
join.AddInt32("im_what", im_what);
|
2021-06-12 21:42:10 -05:00
|
|
|
join.AddString("chat_id", fileName);
|
|
|
|
|
looper->PostMessage(&join);
|
|
|
|
|
}
|
2021-07-21 12:12:02 -05:00
|
|
|
NotifyInteger(INT_ACCOUNTS_UPDATED, 0);
|
2021-06-12 16:13:52 -05:00
|
|
|
break;
|
|
|
|
|
}
|
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
|
|
|
case IM_PROTOCOL_DISABLE:
|
2021-07-18 15:39:30 -05:00
|
|
|
{
|
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
|
|
|
int64 instance = 0;
|
2021-07-21 12:12:02 -05:00
|
|
|
if (msg->FindInt64("instance", &instance) != B_OK)
|
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
|
|
|
result = B_SKIP_MESSAGE;
|
2021-07-21 12:12:02 -05:00
|
|
|
else
|
|
|
|
|
RemoveProtocolLooper(instance);
|
|
|
|
|
|
|
|
|
|
NotifyInteger(INT_ACCOUNTS_UPDATED, 0);
|
2021-07-18 15:39:30 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
void
|
|
|
|
|
Server::ImError(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
const char* error = NULL;
|
|
|
|
|
const char* detail = msg->FindString("detail");
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
if (msg->FindString("error", &error) != B_OK || looper == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// Format error message
|
|
|
|
|
BString errMsg(looper->Protocol()->GetName());
|
|
|
|
|
errMsg << " ― " << error;
|
|
|
|
|
if (detail)
|
|
|
|
|
errMsg << "\n\n" << detail;
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
BAlert* alert = new BAlert(B_TRANSLATE("Error"), errMsg.String(),
|
|
|
|
|
B_TRANSLATE("OK"), NULL, NULL, B_WIDTH_AS_USUAL, B_STOP_ALERT);
|
2021-07-18 15:39:30 -05:00
|
|
|
alert->Go();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-31 13:04:58 -05:00
|
|
|
void
|
2021-06-20 12:44:20 -05:00
|
|
|
Server::AddProtocolLooper(bigtime_t instanceId, ChatProtocol* cayap)
|
2021-05-31 13:04:58 -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
|
|
|
ProtocolLooper* looper = new ProtocolLooper(cayap, instanceId);
|
2021-05-31 13:04:58 -05:00
|
|
|
fLoopers.AddItem(instanceId, looper);
|
2021-06-01 21:43:19 -05:00
|
|
|
fAccounts.AddItem(cayap->GetName(), instanceId);
|
2021-07-21 12:12:02 -05:00
|
|
|
fAccountEnabled.AddItem(cayap->GetName(), false);
|
2021-08-05 19:28:05 -05:00
|
|
|
|
|
|
|
|
if (fStarted == true)
|
|
|
|
|
Login(looper);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
Server::RemoveProtocolLooper(bigtime_t instanceId)
|
|
|
|
|
{
|
2021-06-11 20:33:28 -05:00
|
|
|
ProtocolLooper* looper = GetProtocolLooper(instanceId);
|
|
|
|
|
if (looper == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
ChatMap chats = looper->Conversations();
|
|
|
|
|
for (int i = 0; i < chats.CountItems(); i++)
|
|
|
|
|
delete chats.ValueAt(i);
|
|
|
|
|
|
|
|
|
|
UserMap users = looper->Users();
|
|
|
|
|
for (int i = 0; i < users.CountItems(); i++)
|
|
|
|
|
delete users.ValueAt(i);
|
|
|
|
|
|
|
|
|
|
fLoopers.RemoveItemFor(instanceId);
|
|
|
|
|
fAccounts.RemoveItemFor(looper->Protocol()->GetName());
|
2021-07-21 12:12:02 -05:00
|
|
|
fAccountEnabled.AddItem(looper->Protocol()->GetName(), false);
|
2021-06-11 20:33:28 -05:00
|
|
|
looper->Lock();
|
|
|
|
|
looper->Quit();
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-01 21:43:19 -05:00
|
|
|
ProtocolLooper*
|
|
|
|
|
Server::GetProtocolLooper(bigtime_t instanceId)
|
|
|
|
|
{
|
|
|
|
|
bool found = false;
|
|
|
|
|
return fLoopers.ValueFor(instanceId, &found);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AccountInstances
|
|
|
|
|
Server::GetAccounts()
|
|
|
|
|
{
|
|
|
|
|
return fAccounts;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-07-21 12:12:02 -05:00
|
|
|
AccountInstances
|
|
|
|
|
Server::GetActiveAccounts()
|
|
|
|
|
{
|
|
|
|
|
AccountInstances fActive;
|
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++)
|
|
|
|
|
if (fAccountEnabled.ValueFor(fAccounts.KeyAt(i)) == true)
|
|
|
|
|
fActive.AddItem(fAccounts.KeyAt(i), fAccounts.ValueAt(i));
|
|
|
|
|
return fActive;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-31 13:04:58 -05:00
|
|
|
void
|
|
|
|
|
Server::SendProtocolMessage(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
// Skip null messages
|
|
|
|
|
if (!msg)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// Check if message contains the instance field
|
|
|
|
|
bigtime_t id;
|
|
|
|
|
if (msg->FindInt64("instance", &id) == B_OK) {
|
|
|
|
|
bool found = false;
|
|
|
|
|
ProtocolLooper* looper
|
|
|
|
|
= fLoopers.ValueFor(id, &found);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
Server::SendAllProtocolMessage(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
// Skip null messages
|
|
|
|
|
if (!msg)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// Send message to all protocols
|
|
|
|
|
for (uint32 i = 0; i < fLoopers.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueAt(i);
|
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RosterMap
|
|
|
|
|
Server::Contacts() const
|
|
|
|
|
{
|
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 contacts;
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
contacts.AddList(fruitLoop->Contacts());
|
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 contacts;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-23 14:39:07 -05:00
|
|
|
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
|
|
|
Server::ContactById(BString id, int64 instance)
|
2021-05-31 13:04:58 -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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
Contact* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->ContactById(id);
|
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
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
|
|
|
Server::AddContact(Contact* contact, int64 instance)
|
2021-05-31 13:04:58 -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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->AddContact(contact);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
UserMap
|
|
|
|
|
Server::Users() const
|
|
|
|
|
{
|
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 users;
|
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
users.AddList(fruitLoop->Users());
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return users;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
Server::UserById(BString id, int64 instance)
|
2021-05-31 13:04:58 -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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
User* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->UserById(id);
|
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
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
|
|
|
Server::AddUser(User* user, int64 instance)
|
2021-05-31 13:04:58 -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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->AddUser(user);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ChatMap
|
|
|
|
|
Server::Conversations() const
|
|
|
|
|
{
|
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 chats;
|
2021-05-31 13:04:58 -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
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
chats.AddList(fruitLoop->Conversations());
|
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 chats;
|
2021-05-31 13:04:58 -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
|
|
|
Conversation*
|
|
|
|
|
Server::ConversationById(BString id, int64 instance)
|
2021-05-31 13:04:58 -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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
Conversation* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->ConversationById(id);
|
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-04 16:32:18 -05:00
|
|
|
void
|
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
|
|
|
Server::AddConversation(Conversation* chat, int64 instance)
|
2021-06-04 16:32:18 -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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->AddConversation(chat);
|
2021-06-04 16:32:18 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-07-31 20:18:36 -05:00
|
|
|
CommandMap
|
|
|
|
|
Server::Commands(int64 instance)
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
CommandMap cmds = fCommands;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
cmds.AddList(looper->Commands());
|
|
|
|
|
return cmds;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-15 00:19:52 -05:00
|
|
|
ChatCommand*
|
2021-06-15 00:59:00 -05:00
|
|
|
Server::CommandById(BString id, int64 instance)
|
2021-06-15 00:19:52 -05:00
|
|
|
{
|
2021-06-15 00:59:00 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
ChatCommand* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->CommandById(id);
|
|
|
|
|
if (result == NULL)
|
|
|
|
|
result = fCommands.ValueFor(id);
|
|
|
|
|
return result;
|
2021-06-15 00:19:52 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-15 21:05:21 -05:00
|
|
|
BObjectList<BMessage>
|
2021-06-16 04:33:06 -05:00
|
|
|
Server::ChatPopUpItems()
|
2021-06-15 21:05:21 -05:00
|
|
|
{
|
|
|
|
|
return fChatItems;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BObjectList<BMessage>
|
|
|
|
|
Server::UserPopUpItems()
|
|
|
|
|
{
|
|
|
|
|
return fUserItems;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
ProtocolLooper*
|
|
|
|
|
Server::_LooperFromMessage(BMessage* message)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
if (!message)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
bigtime_t identifier;
|
|
|
|
|
|
|
|
|
|
if (message->FindInt64("instance", &identifier) == B_OK) {
|
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(identifier, &found);
|
|
|
|
|
if (found)
|
|
|
|
|
return looper;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-23 14:39:07 -05:00
|
|
|
Contact*
|
2021-05-31 11:56:45 -05:00
|
|
|
Server::_EnsureContact(BMessage* message)
|
2010-05-16 16:02:50 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
BString id = message->FindString("user_id");
|
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
|
|
|
ProtocolLooper* looper = _LooperFromMessage(message);
|
|
|
|
|
if (looper == NULL) return NULL;
|
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
|
|
|
Contact* contact = looper->ContactById(id);
|
|
|
|
|
|
|
|
|
|
if (contact == NULL && id.IsEmpty() == false && looper != NULL) {
|
2021-05-31 11:56:45 -05:00
|
|
|
contact = new Contact(id, Looper());
|
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
|
|
|
contact->SetProtocolLooper(looper);
|
|
|
|
|
looper->AddContact(contact);
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
return contact;
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
User*
|
|
|
|
|
Server::_EnsureUser(BMessage* message)
|
2021-05-24 01:47:21 -05:00
|
|
|
{
|
|
|
|
|
BString id = message->FindString("user_id");
|
2021-06-02 16:53:03 -05:00
|
|
|
return _EnsureUser(id, _LooperFromMessage(message));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
|
|
|
|
Server::_EnsureUser(BString id, ProtocolLooper* protoLooper)
|
|
|
|
|
{
|
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
|
|
|
User* user = protoLooper->UserById(id);
|
2021-05-24 01:47:21 -05:00
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
if (user == NULL && id.IsEmpty() == false) {
|
|
|
|
|
user = new User(id, Looper());
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetProtocolLooper(protoLooper);
|
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
|
|
|
protoLooper->AddUser(user);
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
return user;
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conversation*
|
|
|
|
|
Server::_EnsureConversation(BMessage* message)
|
|
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper;
|
|
|
|
|
if (!message || (looper = _LooperFromMessage(message)) == NULL)
|
2021-05-24 01:47:21 -05:00
|
|
|
return NULL;
|
|
|
|
|
|
2021-08-12 15:43:52 -05:00
|
|
|
BString chat_id = message->GetString("chat_id", "");
|
2021-05-24 01:47:21 -05:00
|
|
|
Conversation* item = NULL;
|
|
|
|
|
|
|
|
|
|
if (chat_id.IsEmpty() == false) {
|
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
|
|
|
item = looper->ConversationById(chat_id);
|
2010-05-07 04:47:10 -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
|
|
|
if (item == NULL) {
|
2021-05-24 01:47:21 -05:00
|
|
|
item = new Conversation(chat_id, Looper());
|
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
|
|
|
item->SetProtocolLooper(looper);
|
2021-08-10 18:03:32 -05:00
|
|
|
if (looper->GetOwnContact() != NULL)
|
|
|
|
|
item->AddUser(looper->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
|
|
|
looper->AddConversation(item);
|
2021-06-13 01:16:30 -05:00
|
|
|
|
|
|
|
|
BMessage meta(IM_MESSAGE);
|
|
|
|
|
meta.AddInt32("im_what", IM_GET_ROOM_METADATA);
|
|
|
|
|
meta.AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
|
|
BMessage users(IM_MESSAGE);
|
|
|
|
|
users.AddInt32("im_what", IM_GET_ROOM_PARTICIPANTS);
|
|
|
|
|
users.AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
|
|
looper->MessageReceived(&meta);
|
|
|
|
|
looper->MessageReceived(&users);
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return item;
|
|
|
|
|
}
|
2021-05-23 14:39:07 -05:00
|
|
|
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
void
|
|
|
|
|
Server::_ProtocolNotification(ProtocolLooper* looper, BString title,
|
|
|
|
|
BString desc, notification_type type)
|
|
|
|
|
{
|
|
|
|
|
if (looper == NULL || title.IsEmpty() == true) return;
|
|
|
|
|
title.ReplaceAll("%user%", looper->Protocol()->GetName());
|
|
|
|
|
desc.ReplaceAll("%user%", looper->Protocol()->GetName());
|
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
|
|
|
_SendNotification(title, desc, looper->Protocol()->Icon(), type);
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
|
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
|
|
|
void
|
|
|
|
|
Server::_SendNotification(BString title, BString content, BBitmap* icon,
|
|
|
|
|
notification_type type)
|
|
|
|
|
{
|
2021-07-18 15:39:30 -05:00
|
|
|
BNotification notification(type);
|
|
|
|
|
notification.SetGroup(BString(APP_NAME));
|
|
|
|
|
notification.SetTitle(title);
|
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
|
|
|
if (content.IsEmpty() == false)
|
|
|
|
|
notification.SetContent(content);
|
|
|
|
|
if (icon != NULL)
|
|
|
|
|
notification.SetIcon(icon);
|
2021-07-18 15:39:30 -05:00
|
|
|
notification.Send();
|
|
|
|
|
}
|
