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

88 lines
2.1 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>
Preferences dialog is progressing...
2010-05-08 14:35:28 -05:00
#include <libsupport/KeyMap.h>
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
#include "CayaConstants.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"
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
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
class CayaProtocol;
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
Rename ContactLinker to Contact
2021-05-23 14:39:07 -05:00
typedef KeyMap<BString, Contact*> RosterMap;
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
typedef KeyMap<BString, User*> UserMap;
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
typedef KeyMap<BString, Conversation*> ChatMap;
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;
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
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
class Server: public BMessageFilter {
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();
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);
Some style violations fixed.
2010-05-20 16:31:55 -05:00
void AddProtocolLooper(bigtime_t instanceId,
CayaProtocol* 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);
AccountInstances
GetAccounts();
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;
Contact* ContactById(BString id);
void AddContact(Contact* contact);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
UserMap Users() const;
User* UserById(BString id);
void AddUser(User* user);
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;
Conversation* ConversationById(BString id);
void AddConversation(Conversation* chat);
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
// TODO: there should be a contact for each account.
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
BString GetOwnContact();
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);
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
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
void _ReplicantStatusNotify(CayaStatus status);
RosterMap fRosterMap;
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
UserMap fUserMap;
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 fChatMap;
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;
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
AccountInstances
fAccounts;
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
BString fMySelf;
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
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
#endif // _SERVER_H
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