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

108 lines
2.2 KiB
C
Raw 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
/*
* Copyright 2021, Jaidyn Levesque <jadedctrl@teknik.io>
* All rights reserved. Distributed under the terms of the MIT license.
*/
#ifndef CONVERSATION_H
#define CONVERSATION_H
Log message recieve times
2021-05-24 14:48:25 -05:00
#include <DateTimeFormat.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 <Messenger.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 <Path.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 <libsupport/KeyMap.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 "Observer.h"
Support for "Roles" (user, moderator, admin, etc.) Add scaffodling support for arbitrary roles and permission-based (and varying!) UI. A new class, Role, represents a user's role in a given room, with three values: * The role's title * The role's permission-set * The role's priority The permission set is a bitmask value for various permissions (e.g., PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy. A user with higher priority (and PERM_BAN) can ban a user with lower priority, but not vice-versa. Two users with the same priority can't ban/kick/mute each other, etc. These permissions should be used to determine what UI elements are displayed― if the user doesn't have permission to ban users, then a "Ban" button shouldn't exist. If the user is muted, they shouldn't be able to type. So on and so forth. For now, permissions are sent with a IM_ROLECHANGE message and stored by the Conversation, but aren't really in use yet. This system should be flexible groundwork to account for the varying administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
#include "Role.h"
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
#include "Server.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 "User.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
class BBitmap;
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
class ConversationItem;
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
class ConversationView;
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
class ProtocolLooper;
class Server;
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
typedef KeyMap<BString, User*> UserMap;
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
typedef KeyMap<BString, Role*> RoleMap;
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
class Conversation : public Notifier, public Observer {
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
public:
Conversation(BString id, BMessenger msgn);
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();
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 GetId() const;
void ImMessage(BMessage* msg);
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
// Tell the ConversationView to invalidate user list
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 ObserveString(int32 what, BString str);
void ObserveInteger(int32 what, int32 value);
void ObservePointer(int32 what, void* ptr);
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 SetNotifyName(const char* name);
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 SetNotifySubject(const char* subject);
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 Messenger() const;
void SetMessenger(BMessenger messenger);
ProtocolLooper* GetProtocolLooper() const;
void SetProtocolLooper(ProtocolLooper* looper);
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* ProtocolBitmap() const;
BBitmap* IconBitmap() const;
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
BString GetName() const;
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
ConversationView* GetView();
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 ShowView(bool typing, bool userAction);
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
ConversationItem* GetListItem();
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
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 Users();
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
User* UserById(BString 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
BString GetOwnId();
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
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 AddUser(User* user);
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 RemoveUser(User* 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
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 SetRole(BString id, Role* role);
Role* GetRole(BString id);
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
int32 GetFlags(int32 flags) { return fRoomFlags; }
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
private:
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 _LogChatMessage(BMessage* msg);
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 _GetChatLogs(BMessage* msg);
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
Cache roomflags, autojoin/autocreate based on them Fixes #3
2021-06-13 02:34:11 -05:00
void _CacheRoomFlags();
void _LoadRoomFlags();
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
void _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
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* _EnsureUser(BMessage* 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
BMessenger fMessenger;
ProtocolLooper* fLooper;
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
ConversationView* fChatView;
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
ConversationItem* 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 fID;
BString fName;
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
BString fSubject;
BBitmap* 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
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
BPath fCachePath;
Log message recieve times
2021-05-24 14:48:25 -05:00
BDateTimeFormat fDateFormatter;
Add text logging of chats Now chat sessions are logged to ~/config/settings/Caya/Cache/Logs/.
2021-05-24 14:20:57 -05:00
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
int32 fRoomFlags;
int32 fDisallowedFlags;
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 fUsers;
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
RoleMap fRoles;
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
};
#endif // CONVERSATION_H