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/views/UserItem.h

37 lines
692 B
C
Raw Normal View History

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
/*
* Copyright 2021, Jaidyn Levesque <jadedctrl@teknik.io>
* All rights reserved. Distributed under the terms of the MIT license.
*/
#ifndef USERITEM_H
#define USERITEM_H
Recolor user's item when status changes
2021-06-03 23:41:23 -05:00
#include <GraphicsDefs.h>
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
#include <StringItem.h>
#include "Observer.h"
class User;
class UserItem : public BStringItem, public Observer {
public:
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
UserItem(User* user);
~UserItem();
Recolor user's item when status changes
2021-06-03 23:41:23 -05:00
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
virtual void DrawItem(BView* owner, BRect frame, bool complete);
Recolor user's item when status changes
2021-06-03 23:41:23 -05:00
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
virtual void ObserveString(int32 what, BString str);
virtual void ObserveInteger(int32 what, int32 value);
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
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
User* GetUser();
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
protected:
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
rgb_color _GetTextColor(rgb_color highColor);
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
private:
User* fUser;
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
int fStatus;
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
};
#endif // USERITEM_H