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

763 lines
17 KiB
C++
Raw Permalink Normal View History

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
/*
Fix checking of ConversationView's visibility Since ConversationViews were manually removed/added previously, now that a BCardLayout is used, the visibility-detection/some actions change (e.g., using BView::Show instead of BView::AttachedToWindow).
2022-02-21 18:01:36 -06:00
* Copyright 2021-2022, Jaidyn Levesque <jadedctrl@teknik.io>
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
* All rights reserved. Distributed under the terms of the MIT license.
*/
#include "Conversation.h"
Add system beeps for message/mention receiving
2021-08-18 20:19:11 -05:00
#include <Beep.h>
Localization, init catkeys
2021-07-19 09:54:27 -05:00
#include <Catalog.h>
Log message recieve times
2021-05-24 14:48:25 -05:00
#include <DateTimeFormat.h>
#include <Locale.h>
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
#include <Notification.h>
#include <StringFormat.h>
Log message recieve times
2021-05-24 14:48:25 -05:00
Add system beeps for message/mention receiving
2021-08-18 20:19:11 -05:00
#include "AppConstants.h"
Change class names
2021-06-20 12:44:20 -05:00
#include "AppPreferences.h"
#include "ChatProtocolMessages.h"
#include "RenderView.h"
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
#include "ChatCommand.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
#include "ConversationItem.h"
Use a single ChatWindow for all conversations All chats now stay in a single window, which removes and switches its current ConversationView with the appropriate one using Conversation::GetView(). This is a stepping-stone to merging the ChatWindow into the MainWindow.
2021-05-28 22:26:32 -05:00
#include "ConversationView.h"
Store default commands/menu items in resources
2021-06-30 14:27:58 -05:00
#include "Flags.h"
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
#include "ImageCache.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 "MainWindow.h"
Show/receive room subjects, show protocol icon in conversation view The conversation view now displays the protocol icon and room subject. Messages for receiving room names (IM_ROOM_NAME) and subjects (IM_ROOM_SUBJECT) were added, and support for the latter was given to the XMPP add-on. New message APIs were added, and several (room-related) im_what values were moved into the 150s/160s. UserItem::_TintColor() was moved to CayaUtils, because it can be used in several different contexts.
2021-06-04 13:57:04 -05:00
#include "NotifyMessage.h"
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
#include "ProtocolLooper.h"
#include "ProtocolManager.h"
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 "Role.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 "Server.h"
#include "TheApp.h"
Change class names
2021-06-20 12:44:20 -05:00
#include "Utils.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
Conversation::Conversation(BString id, BMessenger msgn)
:
fID(id),
fName(id),
fMessenger(msgn),
Use a single ChatWindow for all conversations All chats now stay in a single window, which removes and switches its current ConversationView with the appropriate one using Conversation::GetView(). This is a stepping-stone to merging the ChatWindow into the MainWindow.
2021-05-28 22:26:32 -05:00
fChatView(NULL),
Log message recieve times
2021-05-24 14:48:25 -05:00
fLooper(NULL),
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
fIcon(ImageCache::Get()->GetImage("kOnePersonIcon")),
Rework communication of room metadata, add room flags In the API, a firm distinction between initially fetching a room's metadata and receiving further changes has been made: IM_ROOM_METADATA will be sent to Caya on request (IM_GET_ROOM_METADATA) with the room's name, subject, etc. The other metadata-related messages should only be sent to Caya after the room is initialized, not as a means of initially setting its metadata. Basic room flags were added, though they aren't yet used― they should allow the protocol/add-on/user to configure some room features. Logging, auto-joining, etc.
2021-06-13 01:16:30 -05:00
fDateFormatter(),
fRoomFlags(0),
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
fDisallowedFlags(0),
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
fNotifyMessageCount(0),
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
fNotifyMentionCount(0),
fUserIcon(false)
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
{
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
fConversationItem = new ConversationItem(fName.String(), this);
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
RegisterObserver(fConversationItem);
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
}
Support temporary disabling of accounts Accounts can now be temporarily disabled (in a Pidgin-like style) through Preferences->Accounts. Work is still required to allow enabling/re-enabling of accounts on-the-fly, and for keeping an account's disabled state persistent.
2021-06-11 20:33:28 -05:00
Conversation::~Conversation()
{
((TheApp*)be_app)->GetMainWindow()->RemoveConversation(this);
Display message in chat when user changes nick
2021-08-10 18:03:32 -05:00
if (fLooper != NULL)
fLooper->RemoveConversation(this);
Support temporary disabling of accounts Accounts can now be temporarily disabled (in a Pidgin-like style) through Preferences->Accounts. Work is still required to allow enabling/re-enabling of accounts on-the-fly, and for keeping an account's disabled state persistent.
2021-06-11 20:33:28 -05:00
delete fChatView;
delete fConversationItem;
}
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
BString
Conversation::GetId() const
{
return fID;
}
void
Conversation::ImMessage(BMessage* msg)
{
int32 im_what = msg->FindInt32("im_what");
switch(im_what)
{
case IM_MESSAGE_RECEIVED:
{
Localization, init catkeys
2021-07-19 09:54:27 -05:00
#undef B_TRANSLATION_CONTEXT
#define B_TRANSLATION_CONTEXT "Conversation ― Notifications"
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
_EnsureUser(msg);
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
_LogChatMessage(msg);
Use a single ChatWindow for all conversations All chats now stay in a single window, which removes and switches its current ConversationView with the appropriate one using Conversation::GetView(). This is a stepping-stone to merging the ChatWindow into the MainWindow.
2021-05-28 22:26:32 -05:00
GetView()->MessageReceived(msg);
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
BString text = msg->FindString("body");
Contact* contact = GetOwnContact();
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
BWindow* win = fChatView->Window();
Toggling of room flags through right-click menu Room flags (e.g., whether or not to auto-join, whether notifications should be sent on message receive) can now be toggled through a room's right-click menu in the room-list. Two new room flags were added for notifications as well― ROOM_NOTIFY_DM and ROOM_NOTIFY_ALL. If ROOM_NOTIFY_DM is enabled, the user will receive notifications if they are in a one-on-one chat. If ROOM_NOTIFY_ALL, they will receive notifications on every message sent to the room. The default menu items for the room's pop-up menu were moved from Templates.rdef to be built into the app. Everything else in Templates.rdef should follow suit― B_TRANSLATE can't be used in rdef files!
2021-08-19 00:59:03 -05:00
bool winFocus = (win != NULL &&
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
(win->IsFront() && !(win->IsMinimized())));
Prevent false-positives for mentions
2021-07-31 11:43:09 -05:00
bool mentioned = ((contact->GetName().IsEmpty() == false
&& text.IFindFirst(contact->GetName()) != B_ERROR)
|| (text.IFindFirst(contact->GetId()) != B_ERROR));
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
Add system beeps for message/mention receiving
2021-08-18 20:19:11 -05:00
// Sound the bell, if appropriate
Toggling of room flags through right-click menu Room flags (e.g., whether or not to auto-join, whether notifications should be sent on message receive) can now be toggled through a room's right-click menu in the room-list. Two new room flags were added for notifications as well― ROOM_NOTIFY_DM and ROOM_NOTIFY_ALL. If ROOM_NOTIFY_DM is enabled, the user will receive notifications if they are in a one-on-one chat. If ROOM_NOTIFY_ALL, they will receive notifications on every message sent to the room. The default menu items for the room's pop-up menu were moved from Templates.rdef to be built into the app. Everything else in Templates.rdef should follow suit― B_TRANSLATE can't be used in rdef files!
2021-08-19 00:59:03 -05:00
if (winFocus == false) {
if (mentioned == true
&& AppPreferences::Get()->SoundOnMention == true)
system_beep(APP_MENTION_BEEP);
else if (AppPreferences::Get()->SoundOnMessageReceived == true
&& ((fUsers.CountItems() <=2 && (fRoomFlags & ROOM_NOTIFY_DM))
|| (fRoomFlags & ROOM_NOTIFY_ALL)))
system_beep(APP_MESSAGE_BEEP);
}
Add system beeps for message/mention receiving
2021-08-18 20:19:11 -05:00
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
// Send a notification, if appropriate
Toggling of room flags through right-click menu Room flags (e.g., whether or not to auto-join, whether notifications should be sent on message receive) can now be toggled through a room's right-click menu in the room-list. Two new room flags were added for notifications as well― ROOM_NOTIFY_DM and ROOM_NOTIFY_ALL. If ROOM_NOTIFY_DM is enabled, the user will receive notifications if they are in a one-on-one chat. If ROOM_NOTIFY_ALL, they will receive notifications on every message sent to the room. The default menu items for the room's pop-up menu were moved from Templates.rdef to be built into the app. Everything else in Templates.rdef should follow suit― B_TRANSLATE can't be used in rdef files!
2021-08-19 00:59:03 -05:00
if (winFocus == false && AppPreferences::Get()->NotifyNewMessage) {
Localization, init catkeys
2021-07-19 09:54:27 -05:00
BString notifyTitle = B_TRANSLATE("New mention");
BString notifyText = B_TRANSLATE("You've been summoned from "
"%source%.");
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
if (mentioned == false) {
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
fNotifyMessageCount++;
Localization, init catkeys
2021-07-19 09:54:27 -05:00
notifyTitle.SetTo(B_TRANSLATE("New message"));
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
notifyText.SetTo("");
Localization, init catkeys
2021-07-19 09:54:27 -05:00
BStringFormat pmFormat(B_TRANSLATE("{0, plural,"
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
"=1{You've got a new message from %source%.}"
Localization, init catkeys
2021-07-19 09:54:27 -05:00
"other{You've got # new messages from %source%.}}"));
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
pmFormat.Format(notifyText, fNotifyMessageCount);
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
}
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
else
fNotifyMentionCount++;
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
notifyText.ReplaceAll("%source%", GetName());
Toggling of room flags through right-click menu Room flags (e.g., whether or not to auto-join, whether notifications should be sent on message receive) can now be toggled through a room's right-click menu in the room-list. Two new room flags were added for notifications as well― ROOM_NOTIFY_DM and ROOM_NOTIFY_ALL. If ROOM_NOTIFY_DM is enabled, the user will receive notifications if they are in a one-on-one chat. If ROOM_NOTIFY_ALL, they will receive notifications on every message sent to the room. The default menu items for the room's pop-up menu were moved from Templates.rdef to be built into the app. Everything else in Templates.rdef should follow suit― B_TRANSLATE can't be used in rdef files!
2021-08-19 00:59:03 -05:00
if ((fUsers.CountItems() <= 2 && (fRoomFlags & ROOM_NOTIFY_DM))
|| (fRoomFlags & ROOM_NOTIFY_ALL) || mentioned == true)
{
BBitmap* icon = IconBitmap();
if (icon == NULL)
icon = ProtocolBitmap();
BNotification notification(B_INFORMATION_NOTIFICATION);
notification.SetGroup(BString(APP_NAME));
notification.SetTitle(notifyTitle);
notification.SetIcon(icon);
notification.SetContent(notifyText);
notification.SetMessageID(fID);
notification.Send();
}
Move notifications from ConversationView to Conversation itself
2021-07-16 16:28:58 -05:00
}
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
Add workspace-switching and window-raising options
2021-08-19 02:00:11 -05:00
// Misc. features Caya contributors planned on adding
BWindow* mainWin = ((TheApp*)be_app)->GetMainWindow();
Fix checking of ConversationView's visibility Since ConversationViews were manually removed/added previously, now that a BCardLayout is used, the visibility-detection/some actions change (e.g., using BView::Show instead of BView::AttachedToWindow).
2022-02-21 18:01:36 -06:00
if (winFocus == false && AppPreferences::Get()->MarkUnreadWindow == true)
Add workspace-switching and window-raising options
2021-08-19 02:00:11 -05:00
mainWin->SetTitle(BString(mainWin->Title()).Prepend("[!]"));
Fix checking of ConversationView's visibility Since ConversationViews were manually removed/added previously, now that a BCardLayout is used, the visibility-detection/some actions change (e.g., using BView::Show instead of BView::AttachedToWindow).
2022-02-21 18:01:36 -06:00
if (winFocus == false && AppPreferences::Get()->MoveToCurrentWorkspace)
Add workspace-switching and window-raising options
2021-08-19 02:00:11 -05:00
mainWin->SetWorkspaces(B_CURRENT_WORKSPACE);
if (win == NULL && AppPreferences::Get()->RaiseOnMessageReceived)
mainWin->Activate(true);
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
// If unattached, highlight the ConversationItem
Fix checking of ConversationView's visibility Since ConversationViews were manually removed/added previously, now that a BCardLayout is used, the visibility-detection/some actions change (e.g., using BView::Show instead of BView::AttachedToWindow).
2022-02-21 18:01:36 -06:00
if ((win == NULL || GetView()->IsHidden() == true) && mentioned == true)
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
NotifyInteger(INT_NEW_MENTION, fNotifyMentionCount);
Fix checking of ConversationView's visibility Since ConversationViews were manually removed/added previously, now that a BCardLayout is used, the visibility-detection/some actions change (e.g., using BView::Show instead of BView::AttachedToWindow).
2022-02-21 18:01:36 -06:00
else if (win == NULL || GetView()->IsHidden())
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
NotifyInteger(INT_NEW_MESSAGE, fNotifyMessageCount);
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
break;
}
Re-enable logging, make appending messages to ConversationView safer Now all instances of sending messages (bar status changes) to a conversation's CayaRenderView only happen when attached to the window. Messages sent by user appear after the protocol confirms it's been sent (IM_MESSAGE_SENT), rather than appearing right after the user sends it to the protocol (IM_SEND_MESSAGE). Logs are now re-enabled (since they can safely be appended under any circumstance).
2021-05-30 19:07:50 -05:00
case IM_MESSAGE_SENT:
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
{
_LogChatMessage(msg);
Re-enable logging, make appending messages to ConversationView safer Now all instances of sending messages (bar status changes) to a conversation's CayaRenderView only happen when attached to the window. Messages sent by user appear after the protocol confirms it's been sent (IM_MESSAGE_SENT), rather than appearing right after the user sends it to the protocol (IM_SEND_MESSAGE). Logs are now re-enabled (since they can safely be appended under any circumstance).
2021-05-30 19:07:50 -05:00
GetView()->MessageReceived(msg);
break;
}
case IM_SEND_MESSAGE:
{
Localization, init catkeys
2021-07-19 09:54:27 -05:00
#undef B_TRANSLATION_CONTEXT
#define B_TRANSLATION_CONTEXT "Conversation ― Command info"
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
BString body;
if (msg->FindString("body", &body) != B_OK)
break;
if (IsCommand(body.String()) == false) {
fMessenger.SendMessage(msg);
break;
}
BString name = CommandName(body);
BString args = CommandArgs(body);
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
ChatCommand* cmd = Server::Get()->CommandById(name, fLooper->GetInstance());
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
Fix handling of commands (barring /me)
2021-08-03 14:32:30 -05:00
if (cmd == NULL) {
if (name == "me")
fMessenger.SendMessage(msg);
else
_WarnUser(BString(B_TRANSLATE("That isn't a valid command. "
"Try /help for a list.")));
/me now formats /me properly /me waves arms in the air like a maniac /me knocks over a nearby cup of coffee /me gasps when the coffee spills onto the adjacent laptop /me cries out “Fore! Wait, four! Wait, fire!” when the laptop bursts into flames /me burns to a crisp
2021-07-31 20:39:13 -05:00
break;
}
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
BString error("");
if (cmd->Parse(args, &error, this) == false)
_WarnUser(error);
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
break;
}
Rework communication of room metadata, add room flags In the API, a firm distinction between initially fetching a room's metadata and receiving further changes has been made: IM_ROOM_METADATA will be sent to Caya on request (IM_GET_ROOM_METADATA) with the room's name, subject, etc. The other metadata-related messages should only be sent to Caya after the room is initialized, not as a means of initially setting its metadata. Basic room flags were added, though they aren't yet used― they should allow the protocol/add-on/user to configure some room features. Logging, auto-joining, etc.
2021-06-13 01:16:30 -05:00
case IM_ROOM_METADATA:
{
BString name;
if (msg->FindString("chat_name", &name) == B_OK)
SetNotifyName(name.String());
BString subject;
if (msg->FindString("subject", &subject) == B_OK)
SetNotifySubject(subject.String());
int32 defaultFlags;
if (msg->FindInt32("room_default_flags", &defaultFlags) == B_OK)
if (fRoomFlags == 0)
fRoomFlags = defaultFlags;
int32 disabledFlags;
if (msg->FindInt32("room_disallowed_flags", &disabledFlags) == B_OK)
fDisallowedFlags = disabledFlags;
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
_CacheRoomFlags();
Rework communication of room metadata, add room flags In the API, a firm distinction between initially fetching a room's metadata and receiving further changes has been made: IM_ROOM_METADATA will be sent to Caya on request (IM_GET_ROOM_METADATA) with the room's name, subject, etc. The other metadata-related messages should only be sent to Caya after the room is initialized, not as a means of initially setting its metadata. Basic room flags were added, though they aren't yet used― they should allow the protocol/add-on/user to configure some room features. Logging, auto-joining, etc.
2021-06-13 01:16:30 -05:00
break;
}
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
case IM_ROOM_PARTICIPANTS:
{
// Get rid of implicity-defined users rq
for (int i = 0; i < fGuests.CountStrings(); i++) {
RemoveUser(UserById(fGuests.StringAt(i)));
fGuests.Remove(i);
}
BStringList ids;
BStringList names;
msg->FindStrings("user_name", &names);
if (msg->FindStrings("user_id", &ids) != B_OK)
break;
for (int i = 0; i < ids.CountStrings(); i++) {
BMessage user;
user.AddString("user_name", names.StringAt(i));
user.AddString("user_id", ids.StringAt(i));
_EnsureUser(&user, false);
}
break;
}
Show users' joins/parts in chat view New API messages were added to distinguish between a user leaving of their own volition and being kicked/banned. Messages are now shown in the chat view when a user leaves or or kicked/banned, etc.
2021-06-07 00:03:15 -05:00
case IM_ROOM_PARTICIPANT_JOINED:
{
BString user_id;
if (msg->FindString("user_id", &user_id) != B_OK)
break;
if (UserById(user_id) == NULL) {
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
_EnsureUser(msg, false);
Show users' joins/parts in chat view New API messages were added to distinguish between a user leaving of their own volition and being kicked/banned. Messages are now shown in the chat view when a user leaves or or kicked/banned, etc.
2021-06-07 00:03:15 -05:00
GetView()->MessageReceived(msg);
}
break;
}
case IM_ROOM_PARTICIPANT_LEFT:
case IM_ROOM_PARTICIPANT_KICKED:
case IM_ROOM_PARTICIPANT_BANNED:
{
BString user_id = msg->FindString("user_id");
User* user;
if (user_id.IsEmpty() == true || (user = UserById(user_id)) == NULL)
break;
GetView()->MessageReceived(msg);
RemoveUser(user);
break;
}
Set room topic/name through conversation view If the user has permission to change a room's subject or name, they can now edit the text views displaying them (toward the top of the window). When enter is pressed, the changes will be sent to the protocol. To do this, a BTextView subclass was added to libinterface (splitting somewhat from SendTextView)― EnterTextView sends a message containing the text to the given target when the user hits enter sans modifiers.
2021-07-29 22:00:01 -05:00
case IM_ROOM_ROLECHANGED:
{
BString user_id;
Role* role = _GetRole(msg);
if (msg->FindString("user_id", &user_id) != B_OK || role == NULL)
break;
SetRole(user_id, role);
GetView()->MessageReceived(msg);
break;
}
Display message in chat when user changes nick
2021-08-10 18:03:32 -05:00
case IM_USER_NICKNAME_SET:
{
BString user_id = msg->FindString("user_id");
BString user_name = msg->FindString("user_name");
if (user_id.IsEmpty() == false && user_name.IsEmpty() == false) {
User* user = UserById(user_id);
BString text(B_TRANSLATE("** %old% has changed their nick to %new%."));
text.ReplaceAll("%new%", user_name);
if (user != NULL)
text.ReplaceAll("%old%", user->GetName());
else
text.ReplaceAll("%old%", user_id);
BMessage* notify = new BMessage(IM_MESSAGE);
notify->AddInt32("im_what", IM_MESSAGE_RECEIVED);
notify->AddString("body", text);
GetView()->MessageReceived(notify);
}
break;
}
Re-enable logging, make appending messages to ConversationView safer Now all instances of sending messages (bar status changes) to a conversation's CayaRenderView only happen when attached to the window. Messages sent by user appear after the protocol confirms it's been sent (IM_MESSAGE_SENT), rather than appearing right after the user sends it to the protocol (IM_SEND_MESSAGE). Logs are now re-enabled (since they can safely be appended under any circumstance).
2021-05-30 19:07:50 -05:00
case IM_LOGS_RECEIVED:
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
default:
Use a single ChatWindow for all conversations All chats now stay in a single window, which removes and switches its current ConversationView with the appropriate one using Conversation::GetView(). This is a stepping-stone to merging the ChatWindow into the MainWindow.
2021-05-28 22:26:32 -05:00
GetView()->MessageReceived(msg);
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
Conversation::ObserveString(int32 what, BString str)
{
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
GetView()->InvalidateUserList();
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
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
Conversation::ObserveInteger(int32 what, int32 value)
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
{
Fix checking of ConversationView's visibility Since ConversationViews were manually removed/added previously, now that a BCardLayout is used, the visibility-detection/some actions change (e.g., using BView::Show instead of BView::AttachedToWindow).
2022-02-21 18:01:36 -06:00
if (what == INT_CONV_VIEW_SELECTED) {
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
fNotifyMessageCount = 0;
fNotifyMentionCount = 0;
}
else
GetView()->InvalidateUserList();
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
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
Conversation::ObservePointer(int32 what, void* ptr)
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
{
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
GetView()->InvalidateUserList();
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
}
Update conversation name & window title Allow updating a conversation's name through IM_ROOM_NAME, and change the Caya window's title whenever a new chat is selected.
2021-06-06 18:06:46 -05:00
void
Conversation::SetNotifyName(const char* name)
{
if (BString(name) == fName)
return;
fName = name;
NotifyString(STR_ROOM_NAME, fName.String());
}
Show/receive room subjects, show protocol icon in conversation view The conversation view now displays the protocol icon and room subject. Messages for receiving room names (IM_ROOM_NAME) and subjects (IM_ROOM_SUBJECT) were added, and support for the latter was given to the XMPP add-on. New message APIs were added, and several (room-related) im_what values were moved into the 150s/160s. UserItem::_TintColor() was moved to CayaUtils, because it can be used in several different contexts.
2021-06-04 13:57:04 -05:00
void
Conversation::SetNotifySubject(const char* subject)
{
if (BString(subject) == fSubject)
return;
fSubject = subject;
NotifyString(STR_ROOM_SUBJECT, fSubject.String());
}
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
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
bool
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
Conversation::SetNotifyIconBitmap(BBitmap* icon)
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
{
if (icon != NULL) {
fIcon = icon;
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
NotifyPointer(PTR_ROOM_BITMAP, (void*)icon);
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
return true;
}
return false;
}
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
BMessenger
Conversation::Messenger() const
{
return fMessenger;
}
void
Conversation::SetMessenger(BMessenger messenger)
{
fMessenger = messenger;
}
ProtocolLooper*
Conversation::GetProtocolLooper() const
{
return fLooper;
}
void
Conversation::SetProtocolLooper(ProtocolLooper* looper)
{
fLooper = looper;
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
_LoadRoomFlags();
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
}
Show/receive room subjects, show protocol icon in conversation view The conversation view now displays the protocol icon and room subject. Messages for receiving room names (IM_ROOM_NAME) and subjects (IM_ROOM_SUBJECT) were added, and support for the latter was given to the XMPP add-on. New message APIs were added, and several (room-related) im_what values were moved into the 150s/160s. UserItem::_TintColor() was moved to CayaUtils, because it can be used in several different contexts.
2021-06-04 13:57:04 -05:00
BBitmap*
Conversation::ProtocolBitmap() const
{
Change class names
2021-06-20 12:44:20 -05:00
ChatProtocol* protocol = fLooper->Protocol();
ChatProtocolAddOn* addOn
Show/receive room subjects, show protocol icon in conversation view The conversation view now displays the protocol icon and room subject. Messages for receiving room names (IM_ROOM_NAME) and subjects (IM_ROOM_SUBJECT) were added, and support for the latter was given to the XMPP add-on. New message APIs were added, and several (room-related) im_what values were moved into the 150s/160s. UserItem::_TintColor() was moved to CayaUtils, because it can be used in several different contexts.
2021-06-04 13:57:04 -05:00
= ProtocolManager::Get()->ProtocolAddOn(protocol->Signature());
return addOn->ProtoIcon();
}
BBitmap*
Conversation::IconBitmap() const
{
return fIcon;
}
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
BString
Conversation::GetName() const
{
return fName;
}
Update room subject; accept user_name in OWN_CONTACT_INFO
2021-06-21 02:32:49 -05:00
BString
Conversation::GetSubject() const
{
return fSubject;
}
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
ConversationView*
Conversation::GetView()
{
if (fChatView != NULL)
return fChatView;
fChatView = new ConversationView(this);
Highlight room list-items, auto-scroll in chat When a new message is posted (or the user is messaged), the room's item in the roomlist is now highlighted, like Vision. Chat also auto-scrolls when new messages are posted.
2021-07-17 00:23:56 -05:00
fChatView->RegisterObserver(fConversationItem);
fChatView->RegisterObserver(this);
RegisterObserver(fChatView);
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
Remove obselete CayaProtocol::SaveLogs(), add ::Commands() With the new use of RoomFlags for signifying whether or not a room's chat should be populated with local logs (ROOM_POPULATE_LOGS), SaveLogs() is redundant. A Commands() method was added to the CayaProtocol class returning a CommandMap, which will be used by Caya when searching for commands. KeyList::AddList() and List::AddList() were also added to libsupport, for convenience.
2021-06-15 14:40:28 -05:00
if (!(fRoomFlags & ROOM_POPULATE_LOGS))
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
return fChatView;
Store chatlogs in binary and text formats If chat logs are stored in an endless plain-text file, they're going to be a pain to parse. If they're stored in a binary file, they're a pain for the user to `grep` or go through manually, but they're easier to parse. Why not both? Logs are now stored with a BMessage (with BStringLists) in the 'logs' attribute, and the plain-text logs in the file itself. The attribute will only store 20 messages, but the file itself will be appended to forever. The logs directory also changed, from ~/config/settings/Caya/Cache/Logs to ~/config/settings/Caya/Logs. Useful functions for reading/writing messages to and from an attribute were borrowed from BePodder's libfunky. :-)
2021-06-06 12:02:26 -05:00
BMessage logMsg;
if (_GetChatLogs(&logMsg) == B_OK)
fChatView->MessageReceived(&logMsg);
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
return fChatView;
}
void
Conversation::ShowView(bool typing, bool userAction)
{
((TheApp*)be_app)->GetMainWindow()->SetConversation(this);
}
ConversationItem*
Conversation::GetListItem()
{
return fConversationItem;
}
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
UserMap
Conversation::Users()
{
return fUsers;
}
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
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
Conversation::UserById(BString id)
{
bool found = false;
return fUsers.ValueFor(id, &found);
}
void
Conversation::AddUser(User* user)
{
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
if (user == NULL)
return;
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
BMessage msg;
msg.AddString("user_id", user->GetId());
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
msg.AddString("user_name", user->GetName());
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
_EnsureUser(&msg, false);
Sort conversation and user lists
2021-07-25 14:42:38 -05:00
_SortConversationList();
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
}
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
void
Conversation::RemoveUser(User* user)
{
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
if (user == NULL)
return;
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
fUsers.RemoveItemFor(user->GetId());
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
user->UnregisterObserver(this);
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
GetView()->UpdateUserList(fUsers);
Sort conversation and user lists
2021-07-25 14:42:38 -05:00
_SortConversationList();
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
_UpdateIcon();
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
NotifyInteger(INT_ROOM_MEMBERS, fUsers.CountItems());
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
}
Remove own user from contacts; fix roster bitmaps It doesn't make sense to lump the user themself with their contacts list― their Contact object is now stored seperately. BBitmap loading for RosterItems are fixed, as well. Fixes #33
2021-07-06 14:46:28 -05:00
Contact*
Conversation::GetOwnContact()
Add Vision-like Window menu, conversation list tweaks ALT-↑ and ALT-↓ change the active conversation, based on its position in the main window's ConversationListView. If a conversation is registered by the main window, and no other conversation is selected, it is automatically selected.
2021-05-30 20:45:24 -05:00
{
Remove own user from contacts; fix roster bitmaps It doesn't make sense to lump the user themself with their contacts list― their Contact object is now stored seperately. BBitmap loading for RosterItems are fixed, as well. Fixes #33
2021-07-06 14:46:28 -05:00
return fLooper->GetOwnContact();
Add Vision-like Window menu, conversation list tweaks ALT-↑ and ALT-↓ change the active conversation, based on its position in the main window's ConversationListView. If a conversation is registered by the main window, and no other conversation is selected, it is automatically selected.
2021-05-30 20:45:24 -05:00
}
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
void
Conversation::SetRole(BString id, Role* role)
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
{
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
Role* oldRole = fRoles.ValueFor(id);
if (oldRole != NULL) {
fRoles.RemoveItemFor(id);
delete oldRole;
}
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
if (role != NULL)
fRoles.AddItem(id, role);
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
}
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
Role*
Conversation::GetRole(BString id)
Add Vision-like Window menu, conversation list tweaks ALT-↑ and ALT-↓ change the active conversation, based on its position in the main window's ConversationListView. If a conversation is registered by the main window, and no other conversation is selected, it is automatically selected.
2021-05-30 20:45:24 -05:00
{
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
return fRoles.ValueFor(id);
Add Vision-like Window menu, conversation list tweaks ALT-↑ and ALT-↓ change the active conversation, based on its position in the main window's ConversationListView. If a conversation is registered by the main window, and no other conversation is selected, it is automatically selected.
2021-05-30 20:45:24 -05:00
}
Toggling of room flags through right-click menu Room flags (e.g., whether or not to auto-join, whether notifications should be sent on message receive) can now be toggled through a room's right-click menu in the room-list. Two new room flags were added for notifications as well― ROOM_NOTIFY_DM and ROOM_NOTIFY_ALL. If ROOM_NOTIFY_DM is enabled, the user will receive notifications if they are in a one-on-one chat. If ROOM_NOTIFY_ALL, they will receive notifications on every message sent to the room. The default menu items for the room's pop-up menu were moved from Templates.rdef to be built into the app. Everything else in Templates.rdef should follow suit― B_TRANSLATE can't be used in rdef files!
2021-08-19 00:59:03 -05:00
void
Conversation::SetFlags(int32 flags)
{
fRoomFlags = flags;
_CacheRoomFlags();
}
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
void
Conversation::_WarnUser(BString message)
{
BMessage* warning = new BMessage(IM_MESSAGE);
warning->AddInt32("im_what", IM_MESSAGE_RECEIVED);
warning->AddString("body", message.Append('\n', 1).InsertChars("-- ", 0));
GetView()->MessageReceived(warning);
}
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
void
Conversation::_LogChatMessage(BMessage* msg)
{
New binary log format, with color/face support Binary logs are no longer stored as a single message with a list of strings and int64s ("body", "user_name", "user_id", "when"), but a message with sub-messages (IM_MESSAGE_RECEIVED) verbatim saved. This has the main benefit of preserving message formatting (coloring, bold, italics, etc).
2021-08-17 13:22:20 -05:00
// Binary logs
// TODO: Don't hardcode 31, expose maximum as a setting
const int32 MAX = 31;
BMessage logMsg(IM_MESSAGE);
if (_GetChatLogs(&logMsg) != B_OK) {
logMsg.what = IM_MESSAGE;
logMsg.AddInt32("im_what", IM_LOGS_RECEIVED);
}
BMessage last;
if (logMsg.FindMessage("message", MAX, &last) == B_OK)
logMsg.RemoveData("message", 0);
msg->AddInt64("when", time(NULL));
logMsg.AddMessage("message", msg);
BFile logFile(fCachePath.Path(), B_READ_WRITE | B_OPEN_AT_END | B_CREATE_FILE);
WriteAttributeMessage(&logFile, "Chat:logs", &logMsg);
Searching through chat with TextSearch
2021-08-31 22:04:19 -05:00
BString mime = BString("text/plain");
logFile.WriteAttr("BEOS:TYPE", B_MIME_STRING_TYPE, 0, mime.String(),
mime.CountChars() + 1);
New binary log format, with color/face support Binary logs are no longer stored as a single message with a list of strings and int64s ("body", "user_name", "user_id", "when"), but a message with sub-messages (IM_MESSAGE_RECEIVED) verbatim saved. This has the main benefit of preserving message formatting (coloring, bold, italics, etc).
2021-08-17 13:22:20 -05:00
// Plain-text logs
// Gotta make sure the formatting's pretty!
Log message recieve times
2021-05-24 14:48:25 -05:00
BString date;
fDateFormatter.Format(date, time(0), B_SHORT_DATE_FORMAT, B_MEDIUM_TIME_FORMAT);
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
BString id = msg->FindString("user_id");
Store users' names in binary chat logs
2021-08-11 20:22:42 -05:00
BString name = msg->FindString("user_name");
Store chatlogs in binary and text formats If chat logs are stored in an endless plain-text file, they're going to be a pain to parse. If they're stored in a binary file, they're a pain for the user to `grep` or go through manually, but they're easier to parse. Why not both? Logs are now stored with a BMessage (with BStringLists) in the 'logs' attribute, and the plain-text logs in the file itself. The attribute will only store 20 messages, but the file itself will be appended to forever. The logs directory also changed, from ~/config/settings/Caya/Cache/Logs to ~/config/settings/Caya/Logs. Useful functions for reading/writing messages to and from an attribute were borrowed from BePodder's libfunky. :-)
2021-06-06 12:02:26 -05:00
BString body = msg->FindString("body");
New binary log format, with color/face support Binary logs are no longer stored as a single message with a list of strings and int64s ("body", "user_name", "user_id", "when"), but a message with sub-messages (IM_MESSAGE_RECEIVED) verbatim saved. This has the main benefit of preserving message formatting (coloring, bold, italics, etc).
2021-08-17 13:22:20 -05:00
if (id.IsEmpty() == true && name.IsEmpty() == true)
Add '/help' command
2021-06-15 00:45:51 -05:00
return;
New binary log format, with color/face support Binary logs are no longer stored as a single message with a list of strings and int64s ("body", "user_name", "user_id", "when"), but a message with sub-messages (IM_MESSAGE_RECEIVED) verbatim saved. This has the main benefit of preserving message formatting (coloring, bold, italics, etc).
2021-08-17 13:22:20 -05:00
else if (name.IsEmpty() == true) {
Store users' names in binary chat logs
2021-08-11 20:22:42 -05:00
User* user = UserById(id);
New binary log format, with color/face support Binary logs are no longer stored as a single message with a list of strings and int64s ("body", "user_name", "user_id", "when"), but a message with sub-messages (IM_MESSAGE_RECEIVED) verbatim saved. This has the main benefit of preserving message formatting (coloring, bold, italics, etc).
2021-08-17 13:22:20 -05:00
name = user ? user->GetName() : id;
Store chatlogs in binary and text formats If chat logs are stored in an endless plain-text file, they're going to be a pain to parse. If they're stored in a binary file, they're a pain for the user to `grep` or go through manually, but they're easier to parse. Why not both? Logs are now stored with a BMessage (with BStringLists) in the 'logs' attribute, and the plain-text logs in the file itself. The attribute will only store 20 messages, but the file itself will be appended to forever. The logs directory also changed, from ~/config/settings/Caya/Cache/Logs to ~/config/settings/Caya/Logs. Useful functions for reading/writing messages to and from an attribute were borrowed from BePodder's libfunky. :-)
2021-06-06 12:02:26 -05:00
}
Log message recieve times
2021-05-24 14:48:25 -05:00
BString logLine("[");
Store users' names in binary chat logs
2021-08-11 20:22:42 -05:00
logLine << date << "] <" << name << "> " << body << "\n";
Store chatlogs in binary and text formats If chat logs are stored in an endless plain-text file, they're going to be a pain to parse. If they're stored in a binary file, they're a pain for the user to `grep` or go through manually, but they're easier to parse. Why not both? Logs are now stored with a BMessage (with BStringLists) in the 'logs' attribute, and the plain-text logs in the file itself. The attribute will only store 20 messages, but the file itself will be appended to forever. The logs directory also changed, from ~/config/settings/Caya/Cache/Logs to ~/config/settings/Caya/Logs. Useful functions for reading/writing messages to and from an attribute were borrowed from BePodder's libfunky. :-)
2021-06-06 12:02:26 -05:00
logFile.Write(logLine.String(), logLine.Length());
Populate conversations with logs, if any saved Also adds a function to protocols to toggle this― if CayaProtocol::SaveLogs() returns true, then local logs will be used to popualte conversation windows. Otherwise, it's up to the protocol itself. A new protocol IM_MESSAGE was also created, IM_LOGS_RECEIVED, which can be used to populate conversations with old logs.
2021-05-24 19:12:42 -05:00
}
Store chatlogs in binary and text formats If chat logs are stored in an endless plain-text file, they're going to be a pain to parse. If they're stored in a binary file, they're a pain for the user to `grep` or go through manually, but they're easier to parse. Why not both? Logs are now stored with a BMessage (with BStringLists) in the 'logs' attribute, and the plain-text logs in the file itself. The attribute will only store 20 messages, but the file itself will be appended to forever. The logs directory also changed, from ~/config/settings/Caya/Cache/Logs to ~/config/settings/Caya/Logs. Useful functions for reading/writing messages to and from an attribute were borrowed from BePodder's libfunky. :-)
2021-06-06 12:02:26 -05:00
status_t
Conversation::_GetChatLogs(BMessage* msg)
Populate conversations with logs, if any saved Also adds a function to protocols to toggle this― if CayaProtocol::SaveLogs() returns true, then local logs will be used to popualte conversation windows. Otherwise, it's up to the protocol itself. A new protocol IM_MESSAGE was also created, IM_LOGS_RECEIVED, which can be used to populate conversations with old logs.
2021-05-24 19:12:42 -05:00
{
Auto-join cached rooms on log-in Rooms are now cached in ~/config/settings/Caya/Cache/$account/Rooms/, with each file representing a seperate room. The filename is used as the identifier, and these files now also serve as log files. The log attribute name has also changed from "logs" to "Caya:logs". When a protocol has succesfuly connected, all cached rooms are automatically joined.
2021-06-12 21:42:10 -05:00
_EnsureCachePath();
BFile logFile(fCachePath.Path(), B_READ_WRITE | B_CREATE_FILE);
Change class names
2021-06-20 12:44:20 -05:00
return ReadAttributeMessage(&logFile, "Chat:logs", msg);
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
}
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
void
Conversation::_CacheRoomFlags()
{
_EnsureCachePath();
BFile cacheFile(fCachePath.Path(), B_READ_WRITE | B_CREATE_FILE);
if (cacheFile.InitCheck() != B_OK)
return;
Change class names
2021-06-20 12:44:20 -05:00
cacheFile.WriteAttr("Chat:flags", B_INT32_TYPE, 0, &fRoomFlags, sizeof(int32));
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
}
void
Conversation::_LoadRoomFlags()
{
_EnsureCachePath();
BFile cacheFile(fCachePath.Path(), B_READ_ONLY);
if (cacheFile.InitCheck() != B_OK)
return;
Change class names
2021-06-20 12:44:20 -05:00
cacheFile.ReadAttr("Chat:flags", B_INT32_TYPE, 0, &fRoomFlags, sizeof(int32));
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
}
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
void
Auto-join cached rooms on log-in Rooms are now cached in ~/config/settings/Caya/Cache/$account/Rooms/, with each file representing a seperate room. The filename is used as the identifier, and these files now also serve as log files. The log attribute name has also changed from "logs" to "Caya:logs". When a protocol has succesfuly connected, all cached rooms are automatically joined.
2021-06-12 21:42:10 -05:00
Conversation::_EnsureCachePath()
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
{
Auto-join cached rooms on log-in Rooms are now cached in ~/config/settings/Caya/Cache/$account/Rooms/, with each file representing a seperate room. The filename is used as the identifier, and these files now also serve as log files. The log attribute name has also changed from "logs" to "Caya:logs". When a protocol has succesfuly connected, all cached rooms are automatically joined.
2021-06-12 21:42:10 -05:00
if (fCachePath.InitCheck() == B_OK)
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
return;
Pass relevant cache paths directly to add-ons Now, instead of using Utils.cpp's AccountCachePath and AddOnCachePath, and add-on should implement ChatProtocol::SetAccountCachePath and ChatProtocol::SetAddOnCachePath. In addition, most path-related functions in Utils now return BPaths― and some of interest to chat add-ons can accept the path given by ChatProtocol::SetAccountCachePath as the main argument.
2022-02-18 15:42:06 -06:00
fCachePath = RoomCachePath(fLooper->Protocol()->GetName(), fID.String());
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
}
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
User*
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
Conversation::_EnsureUser(BMessage* msg, bool implicit)
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
{
BString id = msg->FindString("user_id");
Show users' joins/parts in chat view New API messages were added to distinguish between a user leaving of their own volition and being kicked/banned. Messages are now shown in the chat view when a user leaves or or kicked/banned, etc.
2021-06-07 00:03:15 -05:00
BString name = msg->FindString("user_name");
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
if (id.IsEmpty() == true) return NULL;
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
User* user = UserById(id);
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers Previously, all Conversations/Contacts/Users were stored in the Server, each in their respective KeyMaps, identified solely by their identifiers. This leads to the glaring problem of overlap― if the user has multiple accounts, some users/rooms might be used or present in multiple accounts at the same time. Now, each accounts' Contacts, Conversations, and Users are stored in its ProtocolLooper, making this overlap impossible. An oversight of only allowing one user identifier to be stored (fMySelf) in Server was also fixed this way. This is the bulk of the work required for multi-account support― now, the user can join the same XMPP room on two seperate accounts, and it works perfectly.
2021-06-10 15:16:43 -05:00
User* serverUser = fLooper->UserById(id);
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
Show users' joins/parts in chat view New API messages were added to distinguish between a user leaving of their own volition and being kicked/banned. Messages are now shown in the chat view when a user leaves or or kicked/banned, etc.
2021-06-07 00:03:15 -05:00
// Not here, but found in server
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
if (user == NULL && serverUser != 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
user = serverUser;
Show users' joins/parts in chat view New API messages were added to distinguish between a user leaving of their own volition and being kicked/banned. Messages are now shown in the chat view when a user leaves or or kicked/banned, etc.
2021-06-07 00:03:15 -05:00
// Not anywhere; create 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
else if (user == NULL) {
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
user = new User(id, Server::Get()->Looper());
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
user->SetProtocolLooper(fLooper);
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers Previously, all Conversations/Contacts/Users were stored in the Server, each in their respective KeyMaps, identified solely by their identifiers. This leads to the glaring problem of overlap― if the user has multiple accounts, some users/rooms might be used or present in multiple accounts at the same time. Now, each accounts' Contacts, Conversations, and Users are stored in its ProtocolLooper, making this overlap impossible. An oversight of only allowing one user identifier to be stored (fMySelf) in Server was also fixed this way. This is the bulk of the work required for multi-account support― now, the user can join the same XMPP room on two seperate accounts, and it works perfectly.
2021-06-10 15:16:43 -05:00
fLooper->AddUser(user);
Ensure implicit room-members are real If a message/event is sent to a room that's tied to a user that hasn't been formally declared (through IM_ROOM_PARTICIPANTS or IM_ROOM_PARTICIPANT_JOINED), that user won't be unconditionally kept anymore. Now, after adding an implicit user, the participant list will be requested again― upon receiving the list, all implicitly-defined users will be removed. If they really existed to begin with, they should be re-added quickly through this re-sending of IM_ROOM_PARTICIPANTS. Ghosts should be treated as ghosts, not users.
2021-08-18 14:18:24 -05:00
}
// It's been implicitly defined (rather than explicit join), shame!
if (UserById(id) == NULL && implicit == true) {
fGuests.Add(id);
// The response to this will be used to determine if this guest stays
BMessage msg(IM_MESSAGE);
msg.AddInt32("im_what", IM_GET_ROOM_PARTICIPANTS);
msg.AddString("chat_id", fID);
fLooper->MessageReceived(&msg);
}
if (UserById(id) == NULL) {
fUsers.AddItem(id, 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
fUsers.AddItem(id, user);
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
GetView()->UpdateUserList(fUsers);
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
_UpdateIcon(user);
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
NotifyInteger(INT_ROOM_MEMBERS, fUsers.CountItems());
Ensure MUC nicks are respected
2021-06-10 16:44:35 -05:00
}
Show users' joins/parts in chat view New API messages were added to distinguish between a user leaving of their own volition and being kicked/banned. Messages are now shown in the chat view when a user leaves or or kicked/banned, etc.
2021-06-07 00:03:15 -05:00
Display message in chat when user changes nick
2021-08-10 18:03:32 -05:00
if (name.IsEmpty() == false && user->GetName() != name)
Ensure MUC nicks are respected
2021-06-10 16:44:35 -05:00
user->SetNotifyName(name);
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
user->RegisterObserver(this);
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
return user;
}
Set room topic/name through conversation view If the user has permission to change a room's subject or name, they can now edit the text views displaying them (toward the top of the window). When enter is pressed, the changes will be sent to the protocol. To do this, a BTextView subclass was added to libinterface (splitting somewhat from SendTextView)― EnterTextView sends a message containing the text to the given target when the user hits enter sans modifiers.
2021-07-29 22:00:01 -05:00
Role*
Conversation::_GetRole(BMessage* msg)
{
if (!msg)
return NULL;
BString title;
int32 perms;
int32 priority;
if (msg->FindString("role_title", &title) != B_OK
|| msg->FindInt32("role_perms", &perms) != B_OK
|| msg->FindInt32("role_priority", &priority) != B_OK)
return NULL;
return new Role(title, perms, priority);
}
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
void
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
Conversation::_UpdateIcon(User* user)
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
{
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
if (_IsDefaultIcon(fIcon) == false && fUserIcon == false)
return;
// If it's a one-on-one chat, try to use the other user's icon
if (user != NULL && fUsers.CountItems() == 2
&& user->GetId() != GetOwnContact()->GetId()
&& _IsDefaultIcon(user->AvatarBitmap()) == false) {
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
fUserIcon = SetNotifyIconBitmap(user->AvatarBitmap());
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
return;
}
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
switch (fUsers.CountItems())
{
case 0:
case 1:
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
SetNotifyIconBitmap(ImageCache::Get()->GetImage("kOnePersonIcon"));
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
break;
case 2:
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
SetNotifyIconBitmap(ImageCache::Get()->GetImage("kTwoPeopleIcon"));
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
break;
case 3:
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
SetNotifyIconBitmap(ImageCache::Get()->GetImage("kThreePeopleIcon"));
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
break;
case 4:
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
SetNotifyIconBitmap(ImageCache::Get()->GetImage("kFourPeopleIcon"));
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
break;
default:
Make User/ConversationInfoWindow Observers Now they will observe changes in their corresponding object (if the room's name changes, so will the label in the ConversationInfoWindow, etc).
2021-08-04 13:51:31 -05:00
SetNotifyIconBitmap(ImageCache::Get()->GetImage("kMorePeopleIcon"));
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
break;
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
}
Set default room icon based on user-count If a room doesn't have a set icon (and it isn't a one-on-one chat, for which the icon'll come from the other user's avatar), the default icon is now determined based on user count. If there's X users, an icon with X people will be displayed, up to four. After that, a "+" is overlayed on the icon. Not really necessary… but I think it's cute. :-)
2021-07-31 14:57:43 -05:00
fUserIcon = false;
}
bool
Conversation::_IsDefaultIcon(BBitmap* icon)
{
return (icon == NULL
|| icon == ImageCache::Get()->GetImage("kPersonIcon")
|| icon == ImageCache::Get()->GetImage("kOnePersonIcon")
|| icon == ImageCache::Get()->GetImage("kTwoPeopleIcon")
|| icon == ImageCache::Get()->GetImage("kThreePeopleIcon")
|| icon == ImageCache::Get()->GetImage("kFourPeopleIcon")
|| icon == ImageCache::Get()->GetImage("kMorePeopleIcon"));
Default chat icon, use other user's avatar For one-on-one chats without a custom icon, the other user's avatar will be used as the chat's icon. A default chat icon was also added (haiku/data/artwork/icons/WebsiteComments).
2021-07-27 19:51:55 -05:00
}
Sort conversation and user lists
2021-07-25 14:42:38 -05:00
void
Conversation::_SortConversationList()
{
if (fUsers.CountItems() <= 2 || fUsers.CountItems() == 3)
((TheApp*)be_app)->GetMainWindow()->SortConversation(this);
}