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

82 lines
1.8 KiB
C
Raw Normal View History

Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
/*
* Copyright 2009-2011, Andrea Anzani. All rights reserved.
* Copyright 2012, Dario Casalinuovo. All rights reserved.
* Distributed under the terms of the MIT License.
*/
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
#ifndef USER_H
#define USER_H
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
#include <String.h>
#include <Message.h>
#include <Messenger.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 <ObjectList.h>
#include <libsupport/KeyMap.h>
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
#include "Notifier.h"
#include "CayaConstants.h"
class BBitmap;
class ChatWindow;
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
class Conversation;
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
class UserPopUp;
class ProtocolLooper;
class RosterItem;
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;
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
class User : public Notifier {
public:
User(BString id, BMessenger msgn);
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
void RegisterObserver(Conversation* chat);
void RegisterObserver(Observer* obs) { Notifier::RegisterObserver(obs); }
void UnregisterObserver(Conversation* chat);
void UnregisterObserver(Observer* obs) { Notifier::UnregisterObserver(obs); }
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
void ShowPopUp(BPoint where);
void DeletePopUp();
void HidePopUp();
BString GetId() const;
BMessenger Messenger() const;
void SetMessenger(BMessenger messenger);
ProtocolLooper* GetProtocolLooper() const;
void SetProtocolLooper(ProtocolLooper* looper);
BBitmap* ProtocolBitmap() const;
BString GetName() const;
BBitmap* AvatarBitmap() const;
CayaStatus GetNotifyStatus() const;
BString GetNotifyPersonalStatus() const;
void SetNotifyName(BString name);
void SetNotifyAvatarBitmap(BBitmap* bitmap);
void SetNotifyStatus(CayaStatus status);
void SetNotifyPersonalStatus(BString personalStatus);
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();
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
protected:
BMessenger fMessenger;
ProtocolLooper* fLooper;
BString fID;
bigtime_t fInstance;
BString fName;
BString fPersonalStatus;
BBitmap* fAvatarBitmap;
CayaStatus fStatus;
UserPopUp* fPopUp;
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 fConversations;
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -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
#endif // USER_H