Reference design: https://www.figma.com/file/f8b2dHp9LJCMOqYP4mdrPZ/Client%2FChat?node-id=1%3A297
Adds new component `ChannelList` which makes up the sidebar channel
selector of the new chat design. Contains two separate fill flows for
public and private `ChannelItem` child components.
Exposed bindable `SelectorActive` to indicate current state of the "Add
more channels" button. Requires `Bindable<Channel>` from parent
component.
Renames and updates the `TestSceneChannelListItem` to
`TestSceneChannelList` to make use of new component and having both
tests seemed redundant.
Reference design: https://www.figma.com/file/f8b2dHp9LJCMOqYP4mdrPZ/Client%2FChat?node-id=1%3A297
Adds new component `ChatTextBox`.
Exposes `BindableBool` `ShowSearch` to change text input behaviour
between normal and search behaviour.
Adds new component `ChatTextBar`.
Exposes `BindableBool` `ShowSearch` which toggles between showing current
chat channel or search icon.
Additionally binds to child `ChatTextBox` components.
Requires a cached `Bindable<Channel>` instance to be managed by a parent
component.
This was in flyte's design (he was following discord) but doesn't feel
too correct when it's not aligned with anything else. We can revisit
this if/when we have better glyphs to represent channel types.
Test failed locally in `TestPublicChannelMention`. This test seems to
specify that the same message may arrive twice with the same ID, so
rather than overthinking this one I propose we just use `FirstOrDefault`.
```csharp
TearDown : System.AggregateException : One or more errors occurred.
(Sequence contains more than one matching element)
----> System.InvalidOperationException : Sequence contains more than
one matching element
--TearDown
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
CancellationToken cancellationToken)
at osu.Framework.Extensions.TaskExtensions.WaitSafely(Task task)
at osu.Framework.Testing.TestScene.checkForErrors()
--InvalidOperationException
at System.Linq.ThrowHelper.ThrowMoreThanOneMatchException()
at System.Linq.Enumerable.TryGetSingle[TSource](IEnumerable`1 source,
Func`2 predicate, Boolean& found)
at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1
source, Func`2 predicate)
at
osu.Game.Overlays.Chat.DrawableChannel.<processMessageHighlighting>b__14_0()
in
/Users/dean/Projects/osu/osu.Game/Overlays/Chat/DrawableChannel.cs:line
102
at osu.Framework.Threading.ScheduledDelegate.RunTaskInternal()
```
Adds new component `ChannelControlItem` and it's child components to be
used as the clickable control in the new chat sidebar for joined
channels.
Has public properties `HasUnread` and `MentionCount` to control the
display of the channel having unread messages or mentions of the user.
Channel select/join requests are exposed via `OnRequestSelect` and
`OnRequestLeave` events respectively which should be handled by a parent
component.
Requires a cached `Bindable<Channel>` instance to be managed by a parent
component.
Requires a cached `OveralayColourScheme` instance to be provided by a
parent component.
Without this change, there would be a couple of pixels between each list
item where nothing would be hovered. This is a pretty annoying UX which
we should be avoiding we possible.
Also removes the necessity of scheduling as it actually never worked as
intended, `Scheduler` will still update even when the chat line is
masked away, and the animation will never be held anyways.
The new duration of the animation should be enough for long scrolls
either way.
In the case a message arrives and the chat overlay is hidden, clicking
on the mention notification will not work as the `HighlightedMessage`
bindable callback will execute before the scheduled `newMessagesArrived`
logic (which was hanging since the message arrived until the chat
overlay became open because of the notification).
Simplify things by always scheduling the `HighlightedMessage` bindable
callback.
The callbacks are scheduled to the API thread, but hooked up in BDL
load. This causes a potential case of cross-thread collection
enumeration.
I've tested and it seems like the schedule logic should be fine for
short term. Longer term, we probably want to re-think how this works so
background operations aren't performed on the `DrawableChannel` in the
first place (chat shouldn't have an overhead like this when not
visible).
Closes#11231.
