Commit Graph

44 Enmetoj

Author SHA1 Message Date
Jaidyn Ann f19bcba62a Add Room Directory window
This window (Chat→Room directory) is to be used for either a list of
publicly available rooms (in most protocols), or for a list of
joined-but-hidden rooms (as it'll used with libpurple, to list its
ChatBuddies).

Each room is sent individually from protocols using IM_ROOM_DIRECTORY
messages sent in response to a IM_GET_ROOM_DIRECTORY message.
2021-08-27 11:00:04 -05:00
Jaidyn Ann 6e67401018 Remove unnecessary lib from Makefiles 2021-08-19 17:48:14 -05:00
Jaidyn Ann 8f159b7e8b Rename Cardie to Chat-O-Matic 2021-08-19 02:29:14 -05:00
Jaidyn Ann 901f7a8e05 Disable unusable settings, Notfications tab 2021-08-18 18:28:53 -05:00
Jaidyn Ann c492a46a65 Rename AccountManager to StatusManager 2021-08-16 10:40:18 -05:00
Jaidyn Ann 2e746a975a Split account preferences into dedicated window
Found in the new "Accounts" menubar option.
2021-08-06 12:21:17 -05:00
Jaidyn Ann 7c2362a851 Add 'Room info' dialogue
Fixes #55
2021-08-04 12:44:20 -05:00
Jaidyn Ann 984f066070 Multi-account StatusView; set info per-account
Now the StatusView (bottom-left corner, right below the room list) can
be used to set the nickname and status not only for all accounts at
once, but for managing the status/nick of individual accounts.

AccountManager now can set details of a single account, too.

MainWindow is no longer an Observer (as it just passed the information
along to StatusView― now StatusView manages that itself).

NicknameTextControl was removed, not being in use.
2021-08-03 13:24:36 -05:00
Jaidyn Ann 6d8be225ca Scaffolding of a multi-account StatusView
StatusView now allows the selecting of accounts through a MenuButton
with BitmapMenuItems― the button for selecting an account is nice and
discrete, just showing the bitmap of a protocol (in leiu of a label).
No functional changes, other than this menu.

I tried making all AccountsMenus use BitmapMenuItems, but that gets
unweildy pretty quickly― for now they remain in this menu. Maybe
optional ownership of bitmaps in BitmapMenuItems and caching of protocol
items would help.
2021-08-02 21:59:44 -05:00
Jaidyn Ann 8855464d02 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 15:01:04 -05:00
Jaidyn Ann e33dd92375 Save account selection in account menus 2021-07-28 10:13:31 -05:00
Jaidyn Ann 7df377d996 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
Jaidyn Ann 0ffe3e5ce8 Replace CreateAccountMenu() with dedicated class
CreateAccountMenu() is used to populate a BMenu with items corresponding
to the map of accounts provided to it― but when an account is disabled
or enabled, it can't update automatically.

A dedicated class, fAccountsMenu, now replaces it― it'll automatically
repopulate the list whenever the active accounts update.
2021-07-21 12:14:25 -05:00
Jaidyn Ann 1900b7c5ab Esperanto translation of app 2021-07-19 12:10:18 -05:00
Jaidyn Ann 82c06bba25 Localization, init catkeys 2021-07-19 09:54:27 -05:00
Jaidyn Ann 8a3f22d5e9 Move sendbox to conversation view, replace filter
The BTextBox used for sending messages has been moved from the main
window to individual ConversationViews, allowing seperate histories,
texts, etc., to exist in different conversations.

EditingFilter (a filter that hooked into MainWindow) was previously used
to field special key combos with this textbox, including "ENTER" for
sending, but this has been replaced with a new textview subclass
(SendTextView).
2021-07-08 16:07:03 -05:00
Jaidyn Ann fb070e841a Store default commands/menu items in resources 2021-06-30 14:27:58 -05:00
Jaidyn Ann 6f3b375232 Consolidate Main and TheApp 2021-06-23 14:15:22 -05:00
Jaidyn Ann de09ff9ad6 Rename Caya to Cardie 2021-06-22 01:06:00 -05:00
Jaidyn Ann fbe6e66743 Change class names 2021-06-20 12:44:20 -05:00
Jaidyn Ann 4905d95787 Remove Caya icons 2021-06-20 11:44:16 -05:00
Jaidyn Ann b1254494cb Replace JoinWindow with a TemplateWindow 2021-06-19 18:51:45 -05:00
Jaidyn Ann f4342d9310 Roster management, adding new contacts
The base for roster management (RosterEditWindow) has been made, and
adding new contacts works. Up next is contact removal and editing.

This leverages a new template (as defined in a protocol's
CayaProtocol::SettingsTemplate()), "roster," which should contain all
slots pertinent to editing/adding a contact member.

Two new API messages were added for this― IM_CONTACT_LIST_CONTACT_ADDED
and IM_CONTACT_LIST_CONTACT_REMOVED. The former will functionally just
be IM_CONTACT_INFO, but with some semantical meaning.

A new CayaMessage (CAYA_EDIT_ROSTER) was also added.

TemplateWindow was also edited to this end: Now, like RosterWindow/View,
it can be given a specific accounts' instance id, and it will prevent
the selection of another account. A new constructor was also added, to
allow a ProtocolTemplate to be explicitly passed to it― probably from
the program itself.
2021-06-19 18:25:58 -05:00
Jaidyn Ann 9d72c53dd9 Split RosterWindow into per-account RosterView
Most of RosterWindow's special functions have been split into a special
BGroupView (including both the roster search-box and roster list),
RosterView.

This will give some more flexibility in other uses of the roster list.

In addition, RosterViews can be tied to a specific account by its
looper's instance ID, allowing it to either show all contacts (globally;
if the ID is set to -1) or only those of the specified account.

This can be useful, for example, when inviting contacts to a room―
you can only invite contacts that use the same protocol, and are
associated with your account, so showing all contacts doesn't make
sense.

The SearchBarTextControl class was removed, as it isn't particularly
necessary.
2021-06-18 16:41:09 -05:00
Jaidyn Ann 7c002d8fcc Room creation window; Catch-all template window
Explicit room-creation using protocol's own "room" template is now
supported.

Two new protocol API messages were added― IM_CREATE_ROOM and
IM_ROOM_CREATED, which are parallels to IM_CREATE_CHAT and
IM_CHAT_CREATED. Rather than the latter two, though, these are wholy
based on the "room" template― their slots are completely determined by
the protocol.

A generic "TemplateWindow" was created, which allows catch-all creation
of windows that leverage protocols' templates. It's used for the
room-creation window (Chat->New Room / Alt+N), for example.

At some point, it ideally should replace even the JoinRoom window, and
maybe others.
2021-06-18 01:13:02 -05:00
Jaidyn Ann 3fbe072d42 Generalize protocol settings' GUI templating
A nice templating system is used for account settings dialogues― the
required slots are specified by the protocol, and are reflected in the
settings dialogue.

To generalize this templating system (and eventually use elsewhere),
ProtocolSettings was split into two classes― ProtocolSettings and
ProtocolTemplate.

The CayaProtocol::SettingsTemplate() call was also edited to require a
string parameter, naming the specific template that should be returned.

"account" is used for the account settings dialogue, and other values
are TBA.
2021-06-17 17:02:29 -05:00
Jaidyn Ann 9eaeac24e6 Split icons into seperate RDEF files 2021-06-17 11:49:42 -05:00
Jaidyn Ann 66b8150eeb Basis for custom userlist pop-up menu items 2021-06-15 21:05:21 -05:00
Jaidyn Ann 46d6d0a0b0 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:22:35 -05:00
Jaidyn Ann 552e937e51 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
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