2021-05-31 10:50:43 -05:00
|
|
|
/*
|
|
|
|
* Copyright 2021, Jaidyn Levesque <jadedctrl@teknik.io>
|
|
|
|
* All rights reserved. Distributed under the terms of the MIT license.
|
|
|
|
*/
|
|
|
|
#ifndef CONVERSATIONLIST_H
|
|
|
|
#define CONVERSATIONLIST_H
|
|
|
|
|
|
|
|
#include <ListView.h>
|
|
|
|
|
2021-06-15 21:05:21 -05:00
|
|
|
#include "Role.h"
|
|
|
|
|
2021-05-31 10:50:43 -05:00
|
|
|
class BPopUpMenu;
|
Support generally setting own nick, own UserItems
Seperate UserItems are now created for each list, too, rather than a
single one being created per-user. This functionally works a lot nicer.
But onto more important things… now setting the user's own nick should
work quite well. Finally. =w=
This has given me a good bit of trouble over the past couple of days―
setting the user's nick *worked*, but it wouldn't propagate to its
corresponding UserItem nor its UserInfoDialog. It would, however, work
with the StatusView.
These are all registered Observers of the User itself, so if one works,
they *all* should, them all being registered to the same User.
Now, if a given User isn't found in the ProtocolLooper's user-list,
the Conversation class will take it upon itself to create a new
one and add it to both of their respective lists.
So the user's own contact would be set in the ProtocolLooper― but it
*wouldn't* be added to the user-list.
Hilarity ensues as two seperate objects for the user's own contact would
be created.
Since the StatusView is registered to the ProtocolLooper's "real" own contact
slot, it would receive all updates… but since Conversations' user-lists and
items would be registered to the Conversation-created "fake" user, they
would be borked.
Simple oversight, but wow it hecked with me. :P
2021-08-05 14:10:21 -05:00
|
|
|
|
2021-06-06 01:49:11 -05:00
|
|
|
class Conversation;
|
Support generally setting own nick, own UserItems
Seperate UserItems are now created for each list, too, rather than a
single one being created per-user. This functionally works a lot nicer.
But onto more important things… now setting the user's own nick should
work quite well. Finally. =w=
This has given me a good bit of trouble over the past couple of days―
setting the user's nick *worked*, but it wouldn't propagate to its
corresponding UserItem nor its UserInfoDialog. It would, however, work
with the StatusView.
These are all registered Observers of the User itself, so if one works,
they *all* should, them all being registered to the same User.
Now, if a given User isn't found in the ProtocolLooper's user-list,
the Conversation class will take it upon itself to create a new
one and add it to both of their respective lists.
So the user's own contact would be set in the ProtocolLooper― but it
*wouldn't* be added to the user-list.
Hilarity ensues as two seperate objects for the user's own contact would
be created.
Since the StatusView is registered to the ProtocolLooper's "real" own contact
slot, it would receive all updates… but since Conversations' user-lists and
items would be registered to the Conversation-created "fake" user, they
would be borked.
Simple oversight, but wow it hecked with me. :P
2021-08-05 14:10:21 -05:00
|
|
|
class User;
|
2021-05-31 10:50:43 -05:00
|
|
|
|
|
|
|
|
2021-06-06 16:31:25 -05:00
|
|
|
enum
|
|
|
|
{
|
|
|
|
kUserInfo = 'ULui',
|
|
|
|
kDeafenUser = 'UMdu',
|
|
|
|
kUndeafenUser = 'UMud',
|
|
|
|
kMuteUser = 'UMmu',
|
|
|
|
kUnmuteUser = 'UMum',
|
|
|
|
kKickUser = 'UMku',
|
|
|
|
kBanUser = 'UMbu'
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2021-05-31 10:50:43 -05:00
|
|
|
class UserListView : public BListView {
|
|
|
|
public:
|
2021-07-25 14:42:38 -05:00
|
|
|
UserListView(const char* name);
|
2021-05-31 10:50:43 -05:00
|
|
|
|
2021-07-25 14:42:38 -05:00
|
|
|
virtual void MouseDown(BPoint where);
|
2021-05-31 10:50:43 -05:00
|
|
|
|
2021-07-25 14:42:38 -05:00
|
|
|
void Sort();
|
|
|
|
|
Support generally setting own nick, own UserItems
Seperate UserItems are now created for each list, too, rather than a
single one being created per-user. This functionally works a lot nicer.
But onto more important things… now setting the user's own nick should
work quite well. Finally. =w=
This has given me a good bit of trouble over the past couple of days―
setting the user's nick *worked*, but it wouldn't propagate to its
corresponding UserItem nor its UserInfoDialog. It would, however, work
with the StatusView.
These are all registered Observers of the User itself, so if one works,
they *all* should, them all being registered to the same User.
Now, if a given User isn't found in the ProtocolLooper's user-list,
the Conversation class will take it upon itself to create a new
one and add it to both of their respective lists.
So the user's own contact would be set in the ProtocolLooper― but it
*wouldn't* be added to the user-list.
Hilarity ensues as two seperate objects for the user's own contact would
be created.
Since the StatusView is registered to the ProtocolLooper's "real" own contact
slot, it would receive all updates… but since Conversations' user-lists and
items would be registered to the Conversation-created "fake" user, they
would be borked.
Simple oversight, but wow it hecked with me. :P
2021-08-05 14:10:21 -05:00
|
|
|
bool HasUser(User* user);
|
|
|
|
void AddUser(User* user);
|
|
|
|
void RemoveUser(User* user);
|
|
|
|
|
2021-07-25 14:42:38 -05:00
|
|
|
void SetConversation(Conversation* chat) { fChat = chat; }
|
2021-06-06 01:49:11 -05:00
|
|
|
|
2021-05-31 10:50:43 -05:00
|
|
|
private:
|
2021-07-25 14:42:38 -05:00
|
|
|
BPopUpMenu* _UserPopUp();
|
|
|
|
BPopUpMenu* _BlankPopUp();
|
2021-06-06 01:49:11 -05:00
|
|
|
|
2021-07-25 14:42:38 -05:00
|
|
|
void _ModerationAction(int32 im_what);
|
|
|
|
void _ProcessItem(BMessage* itemMsg, BPopUpMenu* menu,
|
|
|
|
Role* user, Role* target, BString target_id);
|
2021-06-06 16:31:25 -05:00
|
|
|
|
2021-06-06 01:49:11 -05:00
|
|
|
Conversation* fChat;
|
2021-05-31 10:50:43 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
#endif // CONVERSATIONLIST_H
|