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

86 lines
1.9 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.
Program-wide avatar cache Add a program-wide avatar cache― whenever a contact or user's avatar has changed, it gets cached in ~/config/settings/Caya/Cache/$account/People (for contacts) or $account/Users (for everyone else). ImageCache is now used, only for caching the kPersonIcon resource image― it might be useful later for other commonly used images (status indicators, etc). Fixes #4
2021-06-13 17:34:30 -05:00
* Copyright 2021, Jaidyn Levesque. All rights reserved.
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
* 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
Split AppConstants.h into UserStatus.h
2021-08-19 17:04:33 -05:00
#include <GraphicsDefs.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 <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>
Program-wide avatar cache Add a program-wide avatar cache― whenever a contact or user's avatar has changed, it gets cached in ~/config/settings/Caya/Cache/$account/People (for contacts) or $account/Users (for everyone else). ImageCache is now used, only for caching the kPersonIcon resource image― it might be useful later for other commonly used images (status indicators, etc). Fixes #4
2021-06-13 17:34:30 -05:00
#include <Path.h>
Split AppConstants.h into UserStatus.h
2021-08-19 17:04:33 -05:00
#include <String.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
Use Server::Get(), clean up header usage Instead of passing around pointers to the Server, Server::Get() returns the server's pointer (simplifying some things a good bit). As a result, headers have been cleaned up, and some redundant KeyMaps have been placed in Maps.h.
2022-02-23 15:42:46 -06:00
#include "Maps.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 AppConstants.h into UserStatus.h
2021-08-19 17:04:33 -05:00
#include "UserStatus.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 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
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;
Change class names
2021-06-20 12:44:20 -05:00
UserStatus GetNotifyStatus() const;
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 GetNotifyPersonalStatus() const;
void SetNotifyName(BString name);
void SetNotifyAvatarBitmap(BBitmap* bitmap);
Change class names
2021-06-20 12:44:20 -05:00
void SetNotifyStatus(UserStatus status);
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 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:
Program-wide avatar cache Add a program-wide avatar cache― whenever a contact or user's avatar has changed, it gets cached in ~/config/settings/Caya/Cache/$account/People (for contacts) or $account/Users (for everyone else). ImageCache is now used, only for caching the kPersonIcon resource image― it might be useful later for other commonly used images (status indicators, etc). Fixes #4
2021-06-13 17:34:30 -05:00
virtual void _EnsureCachePath();
BBitmap* _GetCachedAvatar();
void _SetCachedAvatar(BBitmap* avatar);
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
BMessenger fMessenger;
ProtocolLooper* fLooper;
BString fID;
BString fName;
BString fPersonalStatus;
BBitmap* fAvatarBitmap;
Program-wide avatar cache Add a program-wide avatar cache― whenever a contact or user's avatar has changed, it gets cached in ~/config/settings/Caya/Cache/$account/People (for contacts) or $account/Users (for everyone else). ImageCache is now used, only for caching the kPersonIcon resource image― it might be useful later for other commonly used images (status indicators, etc). Fixes #4
2021-06-13 17:34:30 -05:00
BPath fCachePath;
Change class names
2021-06-20 12:44:20 -05:00
UserStatus fStatus;
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
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