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.cpp

230 lines
3.3 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.
*
* Authors:
* Andrea Anzani, andrea.anzani@gmail.com
* Dario Casalinuovo
*/
#include "User.h"
#include <libinterface/BitmapUtils.h>
#include "CayaProtocolAddOn.h"
#include "CayaResources.h"
#include "CayaUtils.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"
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 "NotifyMessage.h"
#include "ProtocolLooper.h"
#include "ProtocolManager.h"
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
#include "UserItem.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 "UserPopUp.h"
User::User(BString id, BMessenger msgn)
:
fID(id),
fName(id),
fMessenger(msgn),
fLooper(NULL),
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
fListItem(NULL),
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
fStatus(CAYA_OFFLINE),
fPopUp(NULL)
{
}
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
User::RegisterObserver(Conversation* chat)
{
Notifier::RegisterObserver(chat);
fConversations.AddItem(chat->GetId(), chat);
}
void
User::UnregisterObserver(Conversation* chat)
{
Notifier::UnregisterObserver(chat);
fConversations.RemoveItemFor(chat->GetId());
}
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
User::ShowPopUp(BPoint where)
{
if (fPopUp == NULL) {
fPopUp = new UserPopUp(this);
RegisterObserver(fPopUp);
}
fPopUp->Show();
fPopUp->MoveTo(where);
}
void
User::HidePopUp()
{
if ((fPopUp != NULL) && !fPopUp->IsHidden())
fPopUp->Hide();
}
void
User::DeletePopUp()
{
if (fPopUp == NULL)
return;
if (fPopUp->Lock()) {
UnregisterObserver(fPopUp);
fPopUp->Quit();
fPopUp = NULL;
}
}
BString
User::GetId() const
{
return fID;
}
BMessenger
User::Messenger() const
{
return fMessenger;
}
void
User::SetMessenger(BMessenger messenger)
{
fMessenger = messenger;
}
ProtocolLooper*
User::GetProtocolLooper() const
{
return fLooper;
}
BString
User::GetName() const
{
return fName;
}
BBitmap*
User::AvatarBitmap() const
{
return fAvatarBitmap;
}
BBitmap*
User::ProtocolBitmap() const
{
CayaProtocol* protocol = fLooper->Protocol();
CayaProtocolAddOn* addOn
= ProtocolManager::Get()->ProtocolAddOn(protocol->Signature());
return addOn->ProtoIcon();
}
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*
User::GetListItem()
{
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
if (fListItem == NULL) {
Changes to Notifier→Observer relations The new Notifier→Observer relation chain: * Conversation → ConversationItem, ConversationView * User → UserListItem, UserInfoWindow, UserPopUp * Contact → RosterItem These line up pretty intuitively― if something changes in the conversation, you want the list item and view to change too. But there's one more here that's less intuitive: * User → Conversation If Conversation observes something from a user (i.e., status change), it immediately knows to do one thing only: invalidate the user list, because something's changed.
2021-06-03 23:39:50 -05:00
fListItem = new UserItem(fName, this, (int32)fStatus);
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
RegisterObserver(fListItem);
}
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
return 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
CayaStatus
User::GetNotifyStatus() const
{
return fStatus;
}
BString
User::GetNotifyPersonalStatus() const
{
return fPersonalStatus;
}
void
User::SetProtocolLooper(ProtocolLooper* looper)
{
if (looper) {
fLooper = looper;
// By default we use the Person icon as avatar icon
BResources* res = CayaResources();
BBitmap* bitmap = IconFromResources(res,
kPersonIcon, B_LARGE_ICON);
SetNotifyAvatarBitmap(bitmap);
}
}
void
User::SetNotifyName(BString name)
{
if (fName.Compare(name) != 0) {
fName = name;
NotifyString(STR_CONTACT_NAME, name);
}
}
void
User::SetNotifyAvatarBitmap(BBitmap* bitmap)
{
if ((fAvatarBitmap != bitmap) && (bitmap != NULL)) {
fAvatarBitmap = bitmap;
NotifyPointer(PTR_AVATAR_BITMAP, (void*)bitmap);
}
}
void
User::SetNotifyStatus(CayaStatus status)
{
if (fStatus != status) {
fStatus = status;
NotifyInteger(INT_CONTACT_STATUS, (int32)fStatus);
}
}
void
User::SetNotifyPersonalStatus(BString personalStatus)
{
if (fPersonalStatus.Compare(personalStatus) != 0) {
fPersonalStatus = personalStatus;
NotifyString(STR_PERSONAL_STATUS, 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
User::Conversations()
{
return fConversations;
}