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/Server.h

102 lines
2.9 KiB
C
Raw Normal View History

Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -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.
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
* Distributed under the terms of the MIT License.
*/
#ifndef _SERVER_H
#define _SERVER_H
#include <Message.h>
#include <MessageFilter.h>
Notify on account disabling, more detailed alerts Like the notification sent when accounts are ready (IM_PROTOCOL_READY), one's been added for when accounds have disconnected/are disabled: IM_PROTOCOL_DISABLED. Also, error BAlerts (created with IM_ERROR messages) are now more detailed, showing the associated accounts' name in the header.
2021-07-18 15:39:30 -05:00
#include <Notification.h>
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Preferences dialog is progressing...
2010-05-08 14:35:28 -05:00
#include <libsupport/KeyMap.h>
Change class names
2021-06-20 12:44:20 -05:00
#include "AppConstants.h"
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
#include "ChatCommand.h"
Rename ContactLinker to Contact
2021-05-23 14:39:07 -05:00
#include "Contact.h"
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
#include "Conversation.h"
Replace CreateAccountMenu() with dedicated class CreateAccountMenu() is used to populate a BMenu with items corresponding to the map of accounts provided to it― but when an account is disabled or enabled, it can't update automatically. A dedicated class, fAccountsMenu, now replaces it― it'll automatically repopulate the list whenever the active accounts update.
2021-07-21 12:12:02 -05:00
#include "Notifier.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 "ProtocolLooper.h"
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
#include "User.h"
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Change class names
2021-06-20 12:44:20 -05:00
class ChatProtocol;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
class RosterItem;
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
class ProtocolLooper;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
typedef KeyMap<bigtime_t, ProtocolLooper*> ProtocolLoopers;
Create JoinWindow and protocol messages for joining rooms Protocol messages was added to the API to allow joining abstract rooms by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in anticipation of future room-related calls, some messages' values have been shifted. A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in the main window), to allow joining a room with this protocol message. The user can select which account the room should be joined from through a drop-down menu in the lower left-hand corner― a design I think could be replicated in other parts of Caya well. Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and SetAddOnPath() respectively. GetName() and SetName() were also added, where "name" is the account name (aka the leaf of the protocols settings path). To Server, a new KeyMap was added for convenience (AccountInstances), to associate these account names with their instance IDs.
2021-06-01 21:43:19 -05:00
typedef KeyMap<BString, bigtime_t> AccountInstances;
Replace CreateAccountMenu() with dedicated class CreateAccountMenu() is used to populate a BMenu with items corresponding to the map of accounts provided to it― but when an account is disabled or enabled, it can't update automatically. A dedicated class, fAccountsMenu, now replaces it― it'll automatically repopulate the list whenever the active accounts update.
2021-07-21 12:12:02 -05:00
typedef KeyMap<BString, bool> BoolMap;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
Replace CreateAccountMenu() with dedicated class CreateAccountMenu() is used to populate a BMenu with items corresponding to the map of accounts provided to it― but when an account is disabled or enabled, it can't update automatically. A dedicated class, fAccountsMenu, now replaces it― it'll automatically repopulate the list whenever the active accounts update.
2021-07-21 12:12:02 -05:00
class Server: public BMessageFilter, public Notifier {
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
public:
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
Server();
Add own user to conversations' user lists Really, only one line changed in _EnsureConversation()― the rest is re-organizing the file.
2021-05-31 13:04:58 -05:00
void Quit();
void LoginAll();
Re-enabling of accounts after disable Accounts can now be toggled on-and-off freely. Fixes #42
2021-08-05 19:28:05 -05:00
void Login(ProtocolLooper* looper);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
virtual filter_result Filter(BMessage* message, BHandler** target);
filter_result ImMessage(BMessage* msg);
Notify on account disabling, more detailed alerts Like the notification sent when accounts are ready (IM_PROTOCOL_READY), one's been added for when accounds have disconnected/are disabled: IM_PROTOCOL_DISABLED. Also, error BAlerts (created with IM_ERROR messages) are now more detailed, showing the associated accounts' name in the header.
2021-07-18 15:39:30 -05:00
void ImError(BMessage* msg);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Some style violations fixed.
2010-05-20 16:31:55 -05:00
void AddProtocolLooper(bigtime_t instanceId,
Change class names
2021-06-20 12:44:20 -05:00
ChatProtocol* cayap);
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
void RemoveProtocolLooper(bigtime_t instanceId);
Create JoinWindow and protocol messages for joining rooms Protocol messages was added to the API to allow joining abstract rooms by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in anticipation of future room-related calls, some messages' values have been shifted. A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in the main window), to allow joining a room with this protocol message. The user can select which account the room should be joined from through a drop-down menu in the lower left-hand corner― a design I think could be replicated in other parts of Caya well. Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and SetAddOnPath() respectively. GetName() and SetName() were also added, where "name" is the account name (aka the leaf of the protocols settings path). To Server, a new KeyMap was added for convenience (AccountInstances), to associate these account names with their instance IDs.
2021-06-01 21:43:19 -05:00
ProtocolLooper* GetProtocolLooper(bigtime_t instanceId);
Replace CreateAccountMenu() with dedicated class CreateAccountMenu() is used to populate a BMenu with items corresponding to the map of accounts provided to it― but when an account is disabled or enabled, it can't update automatically. A dedicated class, fAccountsMenu, now replaces it― it'll automatically repopulate the list whenever the active accounts update.
2021-07-21 12:12:02 -05:00
AccountInstances GetAccounts();
AccountInstances GetActiveAccounts();
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
void SendProtocolMessage(BMessage* msg);
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
void SendAllProtocolMessage(BMessage* msg);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
RosterMap 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
Contact* ContactById(BString id, int64 instance);
void AddContact(Contact* contact, int64 instance);
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
UserMap 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
User* UserById(BString id, int64 instance);
void AddUser(User* user, int64 instance);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
ChatMap 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
Conversation* ConversationById(BString id, int64 instance);
void AddConversation(Conversation* chat, int64 instance);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Auto-completion for commands
2021-07-31 20:18:36 -05:00
CommandMap Commands(int64 instance);
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
ChatCommand* CommandById(BString id, int64 instance);
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
Custom chatlist pop-up items
2021-06-16 04:33:06 -05:00
BObjectList<BMessage> ChatPopUpItems();
Basis for custom userlist pop-up menu items
2021-06-15 21:05:21 -05:00
BObjectList<BMessage> UserPopUpItems();
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
private:
Added a new deskbar replicant with related classes and icons, disabled libdownload and curl depencency, fixed some warnings and style violations around the code
2011-12-14 17:36:27 -06:00
ProtocolLooper* _LooperFromMessage(BMessage* message);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Contact* _EnsureContact(BMessage* message);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
User* _EnsureUser(BMessage* message);
Receive lists and changes in room participants from protocols Two new messages were added to the protocol API to do this: M_ROOM_PARTICIPANTS, which can be used when someone joins a room, or on joining a room to send a full list of users, and IM_ROOM_PARTICIPANT_LEFT, for when a user has left the room/disconnected. IM_SET_STATUS no longer assumes received data comes from contacts, but any general user. UserItem was made to reflect changes in the User's name. Chat messages can now be reliably received in a given room. :)
2021-06-02 16:53:03 -05:00
User* _EnsureUser(BString id, ProtocolLooper* protoLooper);
Fix status view's avatar icon The StatusView (below the roomlist) now shows a default icon if no accounts have associated avatars, and will use an account's cached avatar if available.
2021-07-13 14:43:48 -05:00
Contact* _GetOwnContact(BMessage* message);
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Conversation* _EnsureConversation(BMessage* message);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
Notify on account disabling, more detailed alerts Like the notification sent when accounts are ready (IM_PROTOCOL_READY), one's been added for when accounds have disconnected/are disabled: IM_PROTOCOL_DISABLED. Also, error BAlerts (created with IM_ERROR messages) are now more detailed, showing the associated accounts' name in the header.
2021-07-18 15:39:30 -05:00
void _ProtocolNotification(ProtocolLooper* looper,
BString title, BString desc,
notification_type type=B_INFORMATION_NOTIFICATION);
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 _SendNotification(BString title, BString content,
Better protocol status notifications Now a notification is sent as soon as a protocol has been readied (before connection established), and all status notifications use the same message ID to avoid spamming the poor user.
2021-08-18 17:22:08 -05:00
BString id, BBitmap* icon=NULL,
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
notification_type type=B_INFORMATION_NOTIFICATION);
Notify on account disabling, more detailed alerts Like the notification sent when accounts are ready (IM_PROTOCOL_READY), one's been added for when accounds have disconnected/are disabled: IM_PROTOCOL_DISABLED. Also, error BAlerts (created with IM_ERROR messages) are now more detailed, showing the associated accounts' name in the header.
2021-07-18 15:39:30 -05:00
Change class names
2021-06-20 12:44:20 -05:00
void _ReplicantStatusNotify(UserStatus status);
Added a new deskbar replicant with related classes and icons, disabled libdownload and curl depencency, fixed some warnings and style violations around the code
2011-12-14 17:36:27 -06:00
ProtocolLoopers fLoopers;
Replace CreateAccountMenu() with dedicated class CreateAccountMenu() is used to populate a BMenu with items corresponding to the map of accounts provided to it― but when an account is disabled or enabled, it can't update automatically. A dedicated class, fAccountsMenu, now replaces it― it'll automatically repopulate the list whenever the active accounts update.
2021-07-21 12:12:02 -05:00
AccountInstances fAccounts;
BoolMap fAccountEnabled;
Re-enabling of accounts after disable Accounts can now be toggled on-and-off freely. Fixes #42
2021-08-05 19:28:05 -05:00
bool fStarted;
Replace CreateAccountMenu() with dedicated class CreateAccountMenu() is used to populate a BMenu with items corresponding to the map of accounts provided to it― but when an account is disabled or enabled, it can't update automatically. A dedicated class, fAccountsMenu, now replaces it― it'll automatically repopulate the list whenever the active accounts update.
2021-07-21 12:12:02 -05:00
CommandMap fCommands;
BObjectList<BMessage> fChatItems;
BObjectList<BMessage> fUserItems;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
};
#endif // _SERVER_H