Conversation
pajlada
left a comment
pajlada
left a comment
There was a problem hiding this comment.
I'm OK with this approach & direction
| using ChannelPtr = std::shared_ptr<Channel>; | ||
|
|
||
| /// An entry for a single provider | ||
| struct EmoteHolderItem { |
There was a problem hiding this comment.
I don't like the term "item" or "entry", at least not when it's this generic.
How about something like "provider handle"?
There was a problem hiding this comment.
It's not a handle, because it's specific to a channel, and it's only stored in the holder (users of the class won't store this). I'll try to find something else.
There was a problem hiding this comment.
Renamed to ProviderData since it's data for a provider in a channel.
| Q_LOGGING_CATEGORY(chatterinoCrashhandler, "chatterino.crashhandler", | ||
| logThreshold); | ||
| Q_LOGGING_CATEGORY(chatterinoEmoji, "chatterino.emoji", logThreshold); | ||
| Q_LOGGING_CATEGORY(chatterinoEmotes, "chatterino.emotes", logThreshold); |
There was a problem hiding this comment.
Random thought unrelated to your change here: It would be nice if emote providers would have their own logging category, and if that didn't require us to define something here
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
pajlada
left a comment
pajlada
left a comment
There was a problem hiding this comment.
incomplete review / questions
2 participants
This is part 1/4 of refactoring emotes. It introduces the framework for emote providers but doesn't use it for any provider yet (except in tests). See https://github.com/Nerixyz/chatterino2/tree/refactor/third-party-emotes for all providers.
It introduces
EmoteProviders. These are the services (BTTV/FFZ/7TV) that provide emotes. They are managed by theEmoteController. In a channel, the emotes are managed byChannelEmotes.The core idea hasn't changed since #6436 - this contains a more detailed explanation.