Commit Graph

14 Enmetoj

Author SHA1 Message Date
Jaidyn Ann 5b5840a79e 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
Jaidyn Ann 5ecf254ada Move window files to application/windows 2021-06-08 20:42:20 -05:00
Jaidyn Ann 37512144a1 Receive room invitations, allow user to accept or deny
A BAlert is used to inform the user of room invitations― InviteDialogue―
and to send their response directly to the protocol's looper.

Some new protocol messages were added (and older ones were moved around
to compenstate)― IM_ROOM_SEND_INVITE, IM_ROOM_INVITE_REFUSED,
IM_ROOM_INVITE_RECEIVED, IM_ROOM_INVITE_ACCEPT, and
IM_ROOM_INVITE_REFUSE.
2021-06-08 15:32:04 -05:00
Jaidyn Ann 75de08a18b Create JoinWindow and protocol messages for joining rooms
Protocol messages was added to the API to allow joining abstract rooms
by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in
anticipation of future room-related calls, some messages' values have
been shifted.

A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in
the main window), to allow joining a room with this protocol message.
The user can select which account the room should be joined from through
a drop-down menu in the lower left-hand corner― a design I think could
be replicated in other parts of Caya well.

Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and
SetAddOnPath() respectively. GetName() and SetName() were also added,
where "name" is the account name (aka the leaf of the protocols settings
path).

To Server, a new KeyMap was added for convenience (AccountInstances), to
associate these account names with their instance IDs.
2021-06-01 21:50:17 -05:00
Jaidyn Ann 2143de94c1 Remove unused WindowManager class 2021-05-31 16:08:50 -05:00
Jaidyn Ann 63d8bbef26 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
Jaidyn Ann f0492a995d Merge MainWindow and ChatWindow 2021-05-29 15:47:54 -05:00
Jaidyn Ann 3ace145248 Move bulk of chat window into a dedicated ConvesationView
This will help to move to a single-window layout, instead of having a
dedicated window per-chat.
2021-05-28 08:38:33 -05:00
Jaidyn Ann 13ea8fecdf 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
Jaidyn Ann 0326cee687 Move roster into its own generic window
The roster list is now split from MainWindow into RosterWindow, which
can be used arbitrarily for selecting something from contacts. The
im_what, title, and target can be specified.

Right now it's in use under the Chat menu, "New chat…". Chats can only
have two members (DM/PM), so "New chat…" directly leads to the roster
list.

In the future, roster list might be extended to allow specification of
non-contact users based on their identifiers, or filtering based on
protocol/account― this could help it with "invites" to future rooms,
etc.

IM_CREATE_CHAT and IM_CHAT_CREATED were also added to the protocol API,
allowing a new chat to be explicitly created from Caya or the protocol.
2021-05-26 07:48:25 -05:00
Jaidyn Ann 48d0b7bc96 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
Jaidyn Ann 7822ec0449 Split 'Contact' class into two
This dichotomy is useful and necessary in multi-user chats, so I split
Contact into a parent class, User. User should be used for generic
members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
Jaidyn Ann fc16b9b090 Rename ContactLinker to Contact 2021-05-23 14:39:07 -05:00
Jaidyn Ann df55e1d9f5 Switch from Jam to Make 2021-05-19 16:12:19 -05:00