Replies: 11 comments 15 replies
-
|
A plugin that allows for dynamic filtering & highlighting of messages. This can be more extensible than we currently allow in Chatterino, applying your own logic and storing previous messages from the specific user etc |
Beta Was this translation helpful? Give feedback.
-
This could be relatively easy since libcommuni defines |
Beta Was this translation helpful? Give feedback.
-
|
A look into how possible Message Received event could be exposed to plugins can be found here: https://github.com/hemirt/chatterino2/tree/plugin_message_received_basic, this could be used as a starting point if anyone wants to take a look at this and implement this. Imo the best way would be to implement this first at the Irc message part (1), though this showcases possible events at building part (2). This should be in my opinion implemented first and soon, as it enables a very large portion of new possibilities.
There was not much thought put into this exact implementation (especially the lua c++ binding part), so this should be viewed only as example and to spark ideas. I just figured getting the ball rolling on usable plugin feature would be nice. An example of replacing message content is below, although something else could be done instead, e.g. custom commands such as timing out users based on messages, or highlighting messages from special users, or logic and data based ignores, timeouts, or highlights, or automatic translation of foreign languages, playing special highlight sounds...
function onMessage(message)
local content = message.content
local changed = {
content = "",
}
changed.content = "This message was replaced by the plugin"
return changed
end
c2.register_callback(c2.EventType.MessageReceived, onMessage){
"name": "Test message plugin",
"description": "Test message",
"authors": [
"hemirt"
],
"homepage": "",
"tags": [
"test",
"message"
],
"version": "0.0.1",
"license": "NO LICENSE",
"permissions": [
]
} |
Beta Was this translation helpful? Give feedback.
-
Maybe. My concern is that we're tied to IRC by doing this. At some point, I can see us supporting EventSub. If we add this, we should make it very clear that users are hooking into IRC, not some generic message-received event. Furthermore, users probably want to have a way to filter messages by their channel.
That's a nice example, unfortunately, it doesn't work if the message has emotes and could throw our logic for replies off.
Although we copy left and right when building messages, we should put some thought into message APIs. The main problem I see with the current approach is that we need to copy (and transcode) the content of every incoming message. I'm no Lua expert, but from what I can tell from the Sol2 docs, usertypes allow us to define properties. By making messages a usertype, we can avoid copying stuff to Lua unless necessary. A message type could be backed by a |
Beta Was this translation helpful? Give feedback.
-
That is an issue that I believe I made a mention in code, that I did not take care of this, which is why I would advocate that the easiest solution is to catch the message at the earliest, i.e. before the IRCMessage is started being further processed. content = getApp()->getPlugins()->handleMessage(content);
// what about tags or other possible things
// twitch emotes could also bug out
I don't think copying stuff hurts much, but yeah could be looked into, though if this takes long time to figure out or engineer out or takes too much code - I think it should not be prematurely overoptimized, and imo the plugins would most likely either read the message (const&) or replace the message, so maybe there's no need to overcomplicate thing, and make it read only, with some return types, i.e. isChanged, or sth.
TBH I believe rapid prototyping is much better in this instance rather than careful c++ standard committee like planning (modules? networking?). Large changes to this mechanism are going to be behind major release version anyways and there's no problem running an older version of chatterino for your plugin to work before its updated, this is not a online only game that needs to be latest version. Plugins are afterall an optionally compiled-in enabled feature anyways. And by IRC Message, obviously we can choose what parts we want and how, e.g. tags, channel, message, user, is there even anything else? There's no need for extra IRC stuff. We could also want to enable plugins to put in emotes, be they native twitch (though probably only if the user (current? or message-sender? has access to them)), third party (bttv, ffz, 7tv - enabled in chat? or any? user 7tv emotes?), or fourth party (i.e. plugin ones), or badges too - so thats another thing that could be a plugin idea - to enable plugins to register emotes with chatterino. Or disable emotes you dont like or change them, i.e. if you dont celebrate christmas, you might not want to have santa hatted emotes, that some providers change their global emotes to. There could be some thinking about whether to let the plugins register message event globally, or per channel (or even per split?), though the filtering will probably happen anyway, so there's not much difference if we do |
Beta Was this translation helpful? Give feedback.
-
This really depends on what you're trying to do. From the original feature-request: "A plugin that allows for dynamic filtering & highlighting of messages." If you wanted to check whether a BTTV emote was present in the message, you'd be better off looking at the built message. If you want to filter based on IRC tags, you must see the original message. Should we do both? What if we would pass both the built message and the original IRC message to the plugin? That's what this discussion is about.
Your code currently copies the contents into Lua. My comment was that we can use usertypes to avoid copying stuff we don't need (i.e. we'd pass
Yes, we should prototype things. That's what the nightly release is about. But even in the nightly releases, we try to maintain compatibility and not break existing installations. To achieve that, we can make high-level plans on what the interface should look like. This can include prototypes like yours where we can evaluate strengths and weaknesses. We won't get the design right the first time. We have the Lua meta file (it's like TypeScript/JSdoc for Lua). A high-level design can be a snippet from a Lua meta file (maybe with some example code). That's (probably) enough to talk about the general interface and doesn't require any C++ code.
Users do use nightly versions. Not as many, but they exist. Even with major version bumps, we should be careful about compatibility with older versions. "You can just use the old version until the plugin is updated" will inevitably happen, but we should avoid it. For users, this is annoying.
They're enabled by default in CI.
Should probably be a separate comment (...so we can discuss potential designs).
This is far-fetched, but if we know that a plugin is modifying messages in a channel, we could have some visual indicator or other things (e.g. in settings). |
Beta Was this translation helpful? Give feedback.
-
|
summarizing some of the previous ideas: #4885 - add buttons to profile card that can open web links #4449 - read message (tags) and play sound #2091 - replace message content (or add message) #4931 - open a websocket & populate some custom split with system messages |
Beta Was this translation helpful? Give feedback.
-
|
I believe #4449 is essentially just requesting a highlight. |
Beta Was this translation helpful? Give feedback.
-
|
Many of my ideas are related to what I'm missing in Chatterino, because it doesn't use GraphQL. But I think this can be implemented using plugins. Here is my list of ideas:
From the Chatterino API, the following would be required for this:
This is just what recently came to my mind. 🫠 |
Beta Was this translation helpful? Give feedback.
-
|
When it comes to the list of moderators thing, you could make a website that republishes the list of moderators of willing broadcasters and then use that for
This would be nice. Honestly I wouldn't be opposed to making this a Chatterino function instead of a plugin. Modifying message context menus with the ability to tell what element was clicked is would also be nice.
I would like to be able for plugins to be able to generally modify and build messages on the level similar to our internal message elements, maybe even exposing an API for some of them.
I would actually prefer for the plugins to never be able to see the token but instead be able to perform authenticated requests on behalf of the user. This ensures that they won't just take it and send it off to wherever the author pleases.
I would actually prefer that plugins won't be able to modify our existing viewer list but would instead make their own via some kind of GUI API, maybe even using the same class but our implementation probably shouldn't need to worry about choosing a source of the viewer list.
This is probably too niche unless we decide that pseudo-guis with custom messages and abusing splits is the way we want plugins to do GUI (tbh it is quite tempting).
I'm not sure what use cases there are for this apart from getting data you sadly can't get with third-party-accessible APIs. If there are none, this might not get implemented. |
Beta Was this translation helpful? Give feedback.
-
|
I converted this into an idea Adding 7TV / BetterTTV emotes using the context menu on links #5328 and also duplicated the discussion of this topic so that the discussion about the possibility of implementing this as a built-in feature in Chatterino could be continued. |
Beta Was this translation helpful? Give feedback.
-
Just wanted to add, this isn't really feasible unless you're the broadcaster. The bitrate shown in the web player advanced settings comes from the video decoder, and the bitrate/stream health panel shown in the stream manager is only visible to the broadcaster's auth token over GQL. |
Beta Was this translation helpful? Give feedback.
-
|
Possibly move IRC support to a plugin. We already want to have plugins be able to create messages. For this we also would need for plugins to be able to grab a channel like |
Beta Was this translation helpful? Give feedback.
-
|
A few plugin ideas:
|
Beta Was this translation helpful? Give feedback.
-
|
game/title change alerts (e.g., alert me when x streamer switches to y category) |
Beta Was this translation helpful? Give feedback.
-
|
Chat history for a channel in the plugins channel object would be cool |
Beta Was this translation helpful? Give feedback.
-
|
API Feature
Channel-specific commands or text/emote replacements. An example of this would be setting a replacement for
Another plugin feature would be a similar feature, except global replacements but this time matching specific [emoteId, emoteName] and replacing it with [emoteIds...] where emoteIds[0] > emotesId[1] > emotesId[2] > etc.
|
Beta Was this translation helpful? Give feedback.
-
|
QtCreator added a C++ plugin to load Lua plugins (blog article). The source can be found here (permalink). It uses sol3 in C++. It provides the following features (also kinda applicable to Chatterino): Especially for something like GUI, sol3 seems to be easier to use than manually working with the C API of Lua, thus allows more people to contribute. |
Beta Was this translation helpful? Give feedback.
-
Custom completion APIsGoal: I want to create some completion engine, mainly for custom emote completion, but current API has significant limitations
|
Beta Was this translation helpful? Give feedback.
-
|
This would be breaking APIs, so getting it right would be nice.
|
Beta Was this translation helpful? Give feedback.
-
|
#2091 (mentioned in #4999 (comment)) wants to build a chat translator. To do this, plugins need the ability to add rich messages (not just system messages). I'm proposing a minimal API as a start. With this API, plugins can create the same messages as the C++ code. Currently, a few things like links and images are hidden, so only text and linebreaks can be added. Plugins can't introspect or change messages once they're created. These can be future additions. I haven't implemented this in C++ yet. The following should be possible with the proposed API: c2.register_command("/hello-world", function (ctx)
local msg = c2.Message.new({
elements = {
{
type = "text",
text = "Hello,",
color = "#ff0000",
},
{
type = "text",
text = "world",
color = "#00ff00",
trailing_space = false,
},
{
type = "text",
text = "!",
color = "#0000ff",
}
},
id = "my-unique-message",
flags = c2.MessageFlag.System
})
ctx.channel:add_message(msg)
end)Type definitions---@class c2.Message
c2.Message = {}
---@class MessageInit A table to initialize a new message
---@field flags? c2.MessageFlag Message flags (see `c2.MessageFlags`)
---@field id? string The (ideally unique) message ID
---@field parse_time? number Time the message was parsed
---@field search_text? string Text to that is compared when searching for messages
---@field message_text? string The message text (used for filters for example)
---@field login_name? string The login name of the sender
---@field display_name? string The display name of the sender
---@field localized_name? string The localized name of the sender (this is used for CJK names, otherwise it's empty)
---@field username_color? string The color of the username
---@field server_received_time? number The time the server received the message
---@field highlight_color? string|nil The color of the highlight (if any)
---@field elements MessageElementInit[] The elements of the message
---@class MessageElementInitBase A base table to initialize a new message element
---@field flags? c2.MessageElementFlag Message element flags (see `c2.MessageElementFlags`)
---@field tooltip? string Tooltip text
---@field trailing_space? boolean Whether to add a trailing space after the element (default: true)
---@alias MessageColor "text"|"system"|string A color for a text element - "text" and "system" are special values that take the current theme into account
---@class (exact) TextElementInit : MessageElementInitBase A table to initialize a new message text element
---@field type "text" The type of the element
---@field text string The text of this element
---@field color? MessageColor The color of the text
---@field font_style? c2.FontStyle The font style of the text
---@class (exact) SingleLineTextElementInit : MessageElementInitBase A table to initialize a new message single-line text element
---@field type "single-line-text" The type of the element
---@field text string The text of this element
---@field color? MessageColor The color of the text
---@field font_style? c2.FontStyle The font style of the text
---@class (exact) MentionElementInit : MessageElementInitBase A table to initialize a new mention element
---@field type "mention" The type of the element
---@field display_name string The display name of the mentioned user
---@field login_name string The login name of the mentioned user
---@field fallback_color MessageColor The color of the element in case the "Colorize @usernames" is disabled
---@field user_color MessageColor The color of the element in case the "Colorize @usernames" is enabled
---@class (exact) TimestampElementInit : MessageElementInitBase A table to initialize a new timestamp element
---@field type "timestamp" The type of the element
---@field time number? The time of the timestamp (in milliseconds since epoch). If not provided, the current time is used.
---@class (exact) TwitchModerationElementInit : MessageElementInitBase A table to initialize a new Twitch moderation element (all the custom moderation buttons)
---@field type "twitch-moderation" The type of the element
---@class (exact) LinebreakElementInit : MessageElementInitBase A table to initialize a new linebreak element
---@field type "linebreak" The type of the element
---@class (exact) ReplyCurveElementInit : MessageElementInitBase A table to initialize a new reply curve element
---@field type "reply-curve" The type of the element
---@alias MessageElementInit TextElementInit|SingleLineTextElementInit|MentionElementInit|TimestampElementInit|TwitchModerationElementInit|LinebreakElementInit|ReplyCurveElementInit
---@enum c2.MessageFlag
c2.MessageFlag = {
None = 0,
System = 0,
Timeout = 0,
Highlighted = 0,
-- ...
}
---@enum c2.MessageElementFlag
c2.MessageElementFlag = {
None = 0,
Misc = 0,
Text = 0,
Username = 0,
Timestamp = 0,
-- ...
}
---@enum c2.FontStyle
c2.FontStyle = {
Tiny = {}, ---@type c2.FontStyle.Tiny
ChatSmall = {}, ---@type c2.FontStyle.ChatSmall
-- ...
}
--- Creates a new message
---
---@param init MessageInit The message initialization table
---@return c2.Message msg The new message
function c2.Message.new(init) end
---@enum c2.MessageContext Context of the message being added to a channel
c2.MessageContext = {
--- This message is the original
Original = {}, ---@type c2.MessageContext.Original
--- This message is a repost of a message that has already been added in a channel
Repost = {}, ---@type c2.MessageContext.Repost
}
--- Adds a message to the channel
---
---@param message c2.Message The message to add
---@param context? c2.MessageContext The context of the message being added
---@param override_flags? c2.MessageFlag|nil Flags to override the message's flags (some splits might filter for this)
function c2.Channel:add_message(message, context, override_flags) end |
Beta Was this translation helpful? Give feedback.
-
|
I would expect the API for adding a new message element to an existing message to be the same as creating a new message from scratch. Also internally we have helpers like |
Beta Was this translation helpful? Give feedback.
-
|
Since we're giving the ability to change text color dynamically, does QT support stylizing text such as bold, italicizing, underlining, etc.? |
Beta Was this translation helpful? Give feedback.
-
Yes, |
Beta Was this translation helpful? Give feedback.
-
Got an idea for a plugin that you feel like would be useful in Chatterino, but might not make sense in Chatterino itself?
Post it here - we're looking to see how the API should be designed, so getting some ideas as to what you'd like to be able to do with plugins is useful.
Beta Was this translation helpful? Give feedback.
All reactions