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

87 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 "CayaConstants.h"
Support for "Roles" (user, moderator, admin, etc.) Add scaffodling support for arbitrary roles and permission-based (and varying!) UI. A new class, Role, represents a user's role in a given room, with three values: * The role's title * The role's permission-set * The role's priority The permission set is a bitmask value for various permissions (e.g., PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy. A user with higher priority (and PERM_BAN) can ban a user with lower priority, but not vice-versa. Two users with the same priority can't ban/kick/mute each other, etc. These permissions should be used to determine what UI elements are displayed― if the user doesn't have permission to ban users, then a "Ban" button shouldn't exist. If the user is muted, they shouldn't be able to type. So on and so forth. For now, permissions are sent with a IM_ROLECHANGE message and stored by the Conversation, but aren't really in use yet. This system should be flexible groundwork to account for the varying administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
#include "Notifier.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
class BBitmap;
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 ProtocolLooper;
Add user-list to the conversation view, menu tweaks UserListView and UserItem were added as the backbone of the user-list, and the (currently unused) Caya message CAYA_SEND_INVITE was established for inviting users to rooms. Some menus were reworked (e.g., pop-ups of the RosterListView) or generally tweaked to be more sensical or consistent.
2021-05-31 10:50:43 -05:00
class UserItem;
class UserPopUp;
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
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;
Add user-list to the conversation view, menu tweaks UserListView and UserItem were added as the backbone of the user-list, and the (currently unused) Caya message CAYA_SEND_INVITE was established for inviting users to rooms. Some menus were reworked (e.g., pop-ups of the RosterListView) or generally tweaked to be more sensical or consistent.
2021-05-31 10:50:43 -05:00
UserItem* GetListItem();
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
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();
Generate unique foreground for each user
2021-06-07 00:56:26 -05:00
rgb_color fItemColor;
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;
Add user-list to the conversation view, menu tweaks UserListView and UserItem were added as the backbone of the user-list, and the (currently unused) Caya message CAYA_SEND_INVITE was established for inviting users to rooms. Some menus were reworked (e.g., pop-ups of the RosterListView) or generally tweaked to be more sensical or consistent.
2021-05-31 10:50:43 -05:00
UserItem* fListItem;
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
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