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

96 lines
2.1 KiB
C
Raw Normal View History

Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
/*
Update copyright year.
2011-12-03 16:38:03 -06:00
* Copyright 2009-2011, Andrea Anzani. All rights reserved.
* Copyright 2009-2011, Pier Luigi Fiorini. All rights reserved.
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
* Copyright 2021, Jaidyn Levesque. All rights reserved.
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
* Distributed under the terms of the MIT License.
*/
#ifndef _PROTOCOL_LOOPER_H
#define _PROTOCOL_LOOPER_H
#include <Looper.h>
Register commands & pop-up items through messages Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for registering commands and user-list pop-up items. The former replaces CayaProtocol::Commands(), which was a real bad idea in the first place. Just awful. No idea why I did that instead of this, which is nicer and significantly easier anyway.
2021-06-15 23:29:38 -05:00
#include <ObjectList.h>
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
#include <String.h>
#include <libsupport/KeyMap.h>
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
#include "CayaProtocol.h"
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
#include "ChatCommand.h"
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -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
class Contact;
class Conversation;
Group rooms in roomlist by account The ConversationListView is now an BOutlineListView, and rooms are added as subitems to the item of their associated account. Right now, account items aren't selectable or useful.
2021-06-11 17:24:04 -05:00
class ConversationAccountItem;
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
class User;
typedef KeyMap<BString, Conversation*> ChatMap;
typedef KeyMap<BString, Contact*> RosterMap;
typedef KeyMap<BString, User*> UserMap;
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
class ProtocolLooper : public BLooper {
public:
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
ProtocolLooper(CayaProtocol* protocol, int64 instance);
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
~ProtocolLooper();
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
void MessageReceived(BMessage* msg);
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -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
CayaProtocol* Protocol();
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -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
ChatMap Conversations() const;
Conversation* ConversationById(BString id);
void AddConversation(Conversation* chat);
void RemoveConversation(Conversation* chat);
RosterMap Contacts() const;
Contact* ContactById(BString id);
void AddContact(Contact* contact);
UserMap Users() const;
User* UserById(BString id);
void AddUser(User* user);
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
CommandMap Commands() const;
ChatCommand* CommandById(BString id);
Register commands & pop-up items through messages Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for registering commands and user-list pop-up items. The former replaces CayaProtocol::Commands(), which was a real bad idea in the first place. Just awful. No idea why I did that instead of this, which is nicer and significantly easier anyway.
2021-06-15 23:29:38 -05:00
void AddCommand(ChatCommand* cmd);
BObjectList<BMessage>
UserPopUpItems() const;
void AddUserPopUpItem(BMessage* archived);
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
Custom chatlist pop-up items
2021-06-16 04:33:06 -05:00
BObjectList<BMessage>
ChatPopUpItems() const;
void AddChatPopUpItem(BMessage* archived);
Base for custom menubar items Fixes #8
2021-06-16 05:03:10 -05:00
BObjectList<BMessage>
MenuBarItems() const;
void AddMenuBarItem(BMessage* archived);
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();
void SetOwnId(BString user_id);
int64 GetInstance();
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
Group rooms in roomlist by account The ConversationListView is now an BOutlineListView, and rooms are added as subitems to the item of their associated account. Right now, account items aren't selectable or useful.
2021-06-11 17:24:04 -05:00
ConversationAccountItem*
GetListItem();
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
private:
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
CayaProtocol* fProtocol;
int64 fInstance;
BString fMySelf;
ChatMap fChatMap;
RosterMap fRosterMap;
UserMap fUserMap;
Register commands & pop-up items through messages Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for registering commands and user-list pop-up items. The former replaces CayaProtocol::Commands(), which was a real bad idea in the first place. Just awful. No idea why I did that instead of this, which is nicer and significantly easier anyway.
2021-06-15 23:29:38 -05:00
Per-protocol commands, precedence over default commands Fixes #10
2021-06-15 00:59:00 -05:00
CommandMap fCommands;
Register commands & pop-up items through messages Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for registering commands and user-list pop-up items. The former replaces CayaProtocol::Commands(), which was a real bad idea in the first place. Just awful. No idea why I did that instead of this, which is nicer and significantly easier anyway.
2021-06-15 23:29:38 -05:00
BObjectList<BMessage> fUserItems;
Custom chatlist pop-up items
2021-06-16 04:33:06 -05:00
BObjectList<BMessage> fChatItems;
Base for custom menubar items Fixes #8
2021-06-16 05:03:10 -05:00
BObjectList<BMessage> fMenuItems;
Group rooms in roomlist by account The ConversationListView is now an BOutlineListView, and rooms are added as subitems to the item of their associated account. Right now, account items aren't selectable or useful.
2021-06-11 17:24:04 -05:00
ConversationAccountItem*
fListItem;
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
};
#endif // _PROTOCOL_LOOPER_H