This changes the behaviour of the following commands:
- `/ban`
- `/timeout`
- `/untimeout`
- `/unban`
All of those commands now accept one or more `--channel` parameters to override which channel the action should take place in.
The `--channel` parameter accepts a channel ID or channel name with the same syntax as the other "user targets" do (e.g. `id:11148817` or `pajlada`)
examples
Ban user in the chat you're typing in:
`/ban weeb123`
Ban user in the chat you're typing in, with a reason specified:
`/ban weeb123 the ban reason`
Ban user in a separate chat, with a reason specified:
`/ban --channel pajlada weeb123 the ban reason`
Ban user in two separate chats, with a reason specified:
`/ban --channel pajlada --channel id:117166826 weeb123 the ban reason`
Timeout user in the chat you're typing in:
`/timeout weeb123`
Timeout user in the chat you're typing in, with a reason specified:
`/timeout weeb123 10m the timeout reason`
Timeout user in a separate chat, with a reason specified:
`/timeout --channel pajlada weeb123 10m the timeout reason`
Timeout user in two separate chats, with a reason specified:
`/timeout --channel pajlada --channel id:117166826 weeb123 10m the timeout reason`
Unban user in the chat you're typing in:
`/unban weeb123`
Unban user in a separate chat:
`/unban --channel pajlada weeb123`
Unban user in two separate chats:
`/unban --channel pajlada --channel id:117166826 weeb123`
It's no longer a singleton
It's now a unique_ptr that dies together with the Application
* Add getChatLogger to EmptyApplication
* unrelated change: Access Application::instance statically
* fix logging init order
* Add changelog entry
This means it's no longer a singleton, and its lifetime is bound to our application.
This felt like a good small experiment to see how its changes would look
if we did this.
As a shortcut, `getApp` that is already a mega singleton keeps a
reference to Args, this means places that are a bit more difficult to
inject into call `getApp()->getArgs()` just like other things are
accessed.
Miniaudio now runs everything in a separate audio thread - this uses boost::asio's io_context.
Our miniaudio implementation is now also much simplified - it does not use its own resource manager or device. This might end up being stupid if sounds don't work after changing output device or locking or w/e
I've made the sound controller into an interface, meaning we can support multiple sound backends in Chatterino. I've added a Null sound backend that disables all sound. A QMediaPlayer or QSoundEffect or Qt backend could be added.
Miniaudio might idle & disable the device now too, not sure
I've added some unrelated changes in the form of a new setting type, and a new setting page helper function for it, which will hopefully make adding new enum settings easier in the future.
This setting stores its value as a string instead of an int, and uses magic_enum to convert between that string value and its enum value.
nerix