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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "UserItem.h"
|
|
|
|
|
2021-06-03 23:41:23 -05:00
|
|
|
#include <InterfaceDefs.h>
|
|
|
|
#include <View.h>
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "AppConstants.h"
|
2021-06-02 16:53:03 -05:00
|
|
|
#include "NotifyMessage.h"
|
2021-05-31 10:50:43 -05:00
|
|
|
#include "User.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "Utils.h"
|
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
|
|
|
UserItem::UserItem(User* user)
|
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
|
|
|
BStringItem(user->GetName()),
|
2021-06-03 23:41:23 -05:00
|
|
|
fUser(user),
|
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
|
|
|
fStatus(user->GetNotifyStatus())
|
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->RegisterObserver(this);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
UserItem::~UserItem()
|
|
|
|
{
|
|
|
|
fUser->UnregisterObserver(this);
|
2021-05-31 10:50:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-03 23:41:23 -05:00
|
|
|
void
|
|
|
|
UserItem::DrawItem(BView* owner, BRect frame, bool complete)
|
2021-05-31 10:50:43 -05:00
|
|
|
{
|
2021-06-03 23:41:23 -05:00
|
|
|
rgb_color highColor = owner->HighColor();
|
2021-06-04 13:57:04 -05:00
|
|
|
owner->SetHighColor(_GetTextColor(highColor));
|
2021-06-03 23:41:23 -05:00
|
|
|
|
|
|
|
BStringItem::DrawItem(owner, frame, complete);
|
|
|
|
|
|
|
|
owner->SetHighColor(highColor);
|
2021-05-31 10:50:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
UserItem::ObserveString(int32 what, BString str)
|
|
|
|
{
|
2021-06-02 16:53:03 -05:00
|
|
|
switch (what) {
|
|
|
|
case STR_CONTACT_NAME:
|
|
|
|
SetText(str);
|
|
|
|
break;
|
|
|
|
}
|
2021-05-31 10:50:43 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-03 23:41:23 -05:00
|
|
|
void
|
|
|
|
UserItem::ObserveInteger(int32 what, int32 value)
|
|
|
|
{
|
|
|
|
switch (what) {
|
|
|
|
case INT_CONTACT_STATUS:
|
|
|
|
{
|
2021-06-04 13:57:04 -05:00
|
|
|
fStatus = value;
|
2021-06-03 23:41:23 -05:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
|
|
|
UserItem::GetUser()
|
|
|
|
{
|
|
|
|
return fUser;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-04 13:57:04 -05:00
|
|
|
rgb_color
|
|
|
|
UserItem::_GetTextColor(rgb_color highColor)
|
2021-06-03 23:41:23 -05:00
|
|
|
{
|
2021-06-04 13:57:04 -05:00
|
|
|
switch (fStatus)
|
2021-06-03 23:41:23 -05:00
|
|
|
{
|
2021-06-20 12:44:20 -05:00
|
|
|
case STATUS_AWAY:
|
|
|
|
return TintColor(ui_color(B_LIST_ITEM_TEXT_COLOR), 1);
|
|
|
|
case STATUS_INVISIBLE:
|
|
|
|
case STATUS_DO_NOT_DISTURB:
|
|
|
|
return TintColor(ui_color(B_LIST_ITEM_TEXT_COLOR), 2);
|
|
|
|
case STATUS_OFFLINE:
|
|
|
|
return TintColor(ui_color(B_LIST_ITEM_TEXT_COLOR), 3);
|
2021-06-03 23:41:23 -05:00
|
|
|
}
|
2021-06-04 13:57:04 -05:00
|
|
|
return highColor;
|
2021-06-03 23:41:23 -05:00
|
|
|
}
|