various: define builtin options and key bindings for images #15346

guidocella · 2024-11-21T17:03:28Z

This makes mpv a good image viewer out of the box, as it is currently hard to setup.

It adds a builtin image conditional profile that users can extend in mpv.conf. It is written to not restore and reapply the options on each image change, because that is slow for certain options (e.g. --d3d11-flip=no restarts the VO), and causes visible flicker when options like gamma are unapplied before changing image and reapplied on the next image. But it still restores the previous options after switching to a video or audio file.

etc/image-input.conf defines default key bindings for image, and ~/.config/mpv/image-input.conf can override them.

Files called image-input.conf are added to an input section called image, and builtin.conf enables it for images and disables it for non-images. Because enable-section and disable-section are only called in builtin.conf, they can be replaced with a different mechanism when deprecated input sections are removed without a breaking change.

Alternative to #15344, gives proper builtin support to image-input.conf instead of adding a new command to let user handle it. Input sections are only really useful for images, and it is fine to remove them if we support different image key bindings out of the box, and later disable them with a different mechanism, e.g. delete key bindings whose location contains image-input.conf. We already have many mechanisms to add key bindings anyway, input.conf, load-input-conf, mp.add_key_binding, the keybind command.

If this approach is considered good we can then actually decide the bindings and options.

Depends on #15314 and #15320

guidocella · 2024-11-23T09:57:04Z

Added options and bindings since there is no comment. Key bindings are mostly based on sxiv.

I am not sure if space should go the next image because it can be useful to pause slideshows.

kasper93 · 2024-11-23T10:29:26Z

DOCS/man/mpv.rst

+s
+    Toggle between showing images for 5 seconds in a slideshow and keeping them
+    open forever.


Why is this needed? Just pause the playback.

It doesn't just pause, it also enables the slideshow at runtime if you started with --image-display-duration=inf. I think this is a common feature in image viewers.

kasper93 · 2024-11-23T10:30:09Z

DOCS/man/mpv.rst

+P
+    Go to the previous sub-playlist.
+
+g-g


I see what you did here.

We can also bind HOME and END if desired.

Is this really image specific though?

No, but it is more useful for images than for videos. I also use it for videos and audio and would add it to the regular input.conf, but dunno if that's wanted, up to you. We do have G bound to add sub-scale unfortunately (I bind - and = for that).

kasper93 · 2024-11-23T10:31:44Z

DOCS/man/mpv.rst

+n
+    Go to the next playlist entry.
+
+p
+    Go to the previous playlist entry.


I would rebind frame-step to next in image mode. We already have < and > to navigate. We can make them without modifier , . for images.

, and . seem arbitrary and shoehorned just to mirror video key bindings, they don't specify a direction like < and >, what image viewer uses these key bindings? n and p (taken from sxiv) are also nice because they can be mirrored in shift+n and shift+p to navigate subplaylists. They could also be bound in the default input.conf to always use the same key bindings IMO, we bind p to cycle pause, but I don't see why you wouldn't use space for that, or why you need to hold shift for < > when there are free keys.

But we can also just bind both, they're all unused keys for images anyway, and they don't override user bindings.

Actually, it should be noted that these do override key bindings added by mp.add_key_binding without forced, because they're both builtin and the ones enabled last win. I did document how to disable these completely though.

kasper93 · 2024-11-23T10:32:46Z

DOCS/man/mpv.rst

+]
+    Skip 10 playlist entries forwards.
+
+[
+    Skip 10 playlist entries backwards.


oddly specific. How does 10 number were decided?

Copied from sxiv key bindings.

Anyone finds these useful? Else I will remove them later, as suggested by llyyr.

kasper93 · 2024-11-23T10:33:23Z

DOCS/man/mpv.rst

+    Rotate clockwise.
+
+v
+    Rotate by 180 degrees.


Add m for mirror too?

Do you mean flip or vflip? By the way, these are sxiv's keybindings if you want to copy the flip bindings (never needed flipping personally):

< Rotate image counter-clockwise by 90 degrees.
> Rotate image clockwise by 90 degrees.
? Rotate image by 180 degrees.
| Flip image horizontally.
_ Flip image vertically.

In sxiv r reloads the image, but I don't find that useful, so I bind r to rotate instead so you don't hold shift.

kasper93 · 2024-11-23T10:35:12Z

etc/builtin.conf

+profile-cond=(get('current-tracks/video', {}).image and not get('current-tracks/video', {}).albumart) or (not get('current-tracks/video') and get('user-data/mpv/image'))
+profile-restore=copy
+input-commands=no-osd set user-data/mpv/image 1; enable-section image allow-hide-cursor+allow-vo-dragging
+osc=no


I don't think this should be disabled.

osc completely breaks drag to pan from the bottom half of the window. We can also use script-opt=osc-visibility=never if preferred.

osc is useful for images, to see a title, playlist position, navigate, pause. I don't think we should make some other program with those settings, it still should be mpv.

As you wish but then drag to pan is completely broken (it would be nice if it worked like uosc). I didn't even understand why it wasn't working at first. Do you want to use --script-opt=osc-deadzonesize=0.9 at least?

kasper93 · 2024-11-23T10:35:54Z

etc/image-input.conf

+#LEFT        script-binding/positioning pan-x -0.2 # pan left
+#DOWN        script-binding/positioning pan-y  0.2 # pan down
+#UP          script-binding/positioning pan-y -0.2 # pan up
+#RIGHT       script-binding/positioning pan-x  0.2 # pan right
+#h           script-binding/positioning pan-x -0.2 # pan left
+#j           script-binding/positioning pan-y  0.2 # pan down
+#k           script-binding/positioning pan-y -0.2 # pan up
+#l           script-binding/positioning pan-x  0.2 # pan right
+#Shift+LEFT  script-binding/positioning pan-x -0.02 # pan left slowly
+#Shift+DOWN  script-binding/positioning pan-y  0.02 # pan down slowly
+#Shift+UP    script-binding/positioning pan-y -0.02 # pan up slowly
+#Shift+RIGHT script-binding/positioning pan-x  0.02 # pan right slowly
+#H           script-binding/positioning pan-x -0.02 # pan left slowly
+#J           script-binding/positioning pan-y  0.02 # pan down slowly
+#K           script-binding/positioning pan-y -0.02 # pan up slowly
+#L           script-binding/positioning pan-x  0.02 # pan right slowly


0.1 and 0.01 seems better imho.

It is impossible to predict the majority's preferences here. I will set what you prefer, unless we can get more feedback.

It is just consistent with other keybindings.

kasper93 · 2024-11-23T10:38:33Z

etc/image-input.conf

+#WHEEL_UP   script-message cursor-centric-zoom  0.1 # zoom in towards the cursor
+#WHEEL_DOWN script-message cursor-centric-zoom -0.1 # zoom out towards the cursor
+
+#s cycle-values image-display-duration 5 inf; no-osd set video-zoom 0; no-osd set panscan 0; no-osd set video-unscaled no # toggle slideshow


Why it resets zoom and others. This should only affect image duration, no?

Because if you're zoomed in and enable the slideshow, it is assumed that you want to keep viewing images without interaction and thus want to display the entire image fit to the window without having to change the zoom. But it can be removed, if you think it's too opinionated.

llyyr · 2024-11-23T13:57:37Z

etc/builtin.conf

@@ -97,3 +97,15 @@ sub-shadow-offset=4
 [box]
 profile=osd-box
 profile=sub-box
+
+[image]


I'd also add video-aspect-override=0 here because image files are never tagged properly and none of them actually have non-square pixels in most cases even if it claims to do so

Done, also replaced osc=no with script-opt=osc-deadzonesize=0.9.

Might as well go all the way with deadzonesize=1?

Oh I thought 1 was the whole window, but it's the area above the OSC. Done.

na-na-hi · 2024-11-23T15:07:56Z

etc/builtin.conf

@@ -97,3 +97,16 @@ sub-shadow-offset=4
 [box]
 profile=osd-box
 profile=sub-box
+
+[image]
+profile-cond=(get('current-tracks/video', {}).image and not get('current-tracks/video', {}).albumart) or (not get('current-tracks/video') and get('user-data/mpv/image'))


How can I disable this auto profile when this is built-in? I don't think this is good behavior, especially it's very confusing when image keybinds are completely different from normal ones. Also it doesn't work if mpv isn't compiled with lua support.

I think it's better to take this out to the documentation instead and let the user apply the image profile when needed. Putting it in the documentation also informs how to write a conditional profile for images.

You can override options in the profile by defining an image profile in mpv.conf, as is documented.

Already many fundamental things don't work without lua support, osc, console, ytdl_hook. You can still play videos basically without Lua regardless. Without lua you will have to manually apply the profile with a key binding.

Only key bindings already useless for images are different.

The whole point of including a builtin conditional profile is to make mpv a good image viewer out of the box, else we could just put a link to my config. Users can define extra image options without having to deal with this convoluted condition, and without having to recommend them to use enable-section and disable-section, only to remove later them.

How can I disable this auto profile when this is built-in? I don't think this is good behavior, especially it's very confusing when image keybinds are completely different from normal ones.

When would you want to disable this? Most of the video mode keybinds aren't very useful on an image anyway, and as long as playlist-{next,prev} etc. are still the same keybind (I know they aren't right now) it shouldn't inconvenience the user in any way.

I suppose you could allow disabling this by checking for user-data/mpv/disable-image or something, could even map that to an option.

You can override options in the profile by defining an image profile in mpv.conf, as is documented.

This is even more problematic because it treats a profile name specially that may cause unexpected behavior. For example if I already have a profile called "image" that I only use when I want (by aliasing image viewer command to mpv --profile=image for example) it will now be loaded no matter what.

Only key bindings already useless for images are different.

The whole point is that these key bindings behaving differently is an issue. When I have a playlist with mixed images and videos I have to know whether an image or video is displayed before determining which keybinds are activated. Silently changing what keys do when I go forwards and backwards in a playlist is confusing because it's easy to carry the keybind "mental model" to the next file played which can result in unexpected behavior.

When would you want to disable this?

The mentioned keybind behavior

prefetch-playlist is unwanted if the next item in the playlist is a video or on network

video-aspect-override=0 briefly affects next video item in the playlist because conditional profiles are applied asynchronously

If you already have a profile named image that you enable manually enabling it automatically is an intended upgrade, it is a feature not an issue. And if you don't want certain options, you can override them.

The key bindings behaving differently when changing between images and videos is again the intended feature and not an issue, because changed key bindings are useless for images, and replaced with useful ones. You don't need to seek within images. And you can disable them in the profile if you want.

I don't understand how prefetch-playlist is unwanted if the next item is a video, or especially if on network, which is exactly when it's most useful. But again, you can disable it in the profile.

I am not sure about video-aspect-override=0, since I never used it, but according to haasn/llyyr/occivink it is useful for certain images, so it should be worth briefly affecting the next video. But again, you can disable it if it bothers you. This is supposed to be useful defaults, we can't handle every edge case.

and as long as playlist-{next,prev} etc. are still the same keybind (I know they aren't right now)

< and > still work for images, these just extend default key bindings. No key binding that is useful for both videos and images (e.g. stats, gamma) is changed.

What about holding RIGHT to skim over a video and when EOF has been reached and the player jumps to the next playlist item which is an image, the key suddenly changes its behavior?

What about holding RIGHT to skin over a video and when EOF has been reached and the player jumps to the next playlist item and they accidentally skim through the next file too? This can be a problem even on master itself, what you're asking for an option for mpv to release key presses when switching playlist item. Open an issue tracker so someone can work on it later. I don't see how it's related to this PR.

My point is implementing conditional options intended for one type of files in a way that may have side effects for other types is flawed.

What are these side effects and what is flawed? Please elaborate. Do you mean to say track-list/N/image may be unreliable to detect images?

What are these side effects and what is flawed? Please elaborate.

Sorry I didn't make myself clear: Profile conditions are evaluated asynchronously, so there is a chance that options meant for images will affect other types of files shortly.

And yes, I see that this is not likely to happen, but again, the possibility is there. If maintainers decide this can be tolerated, that's perfectly fine.

auto_profiles.lua already evaluates profiles within synchronous hooks, so applying the profile from C wouldn't magically make it more synchronous as far as I know, it just does the same thing with more code and more risk of memory issues.

OK somehow I missed your reply. If that's true then all my concerns have been addressed :) (except maybe for the "profile-cond=" thing, but that's mostly an aesthetic issue)

auto_profiles.lua already evaluates profiles within synchronous hooks, so applying the profile from C wouldn't magically make it more synchronous as far as I know

It only applies profiles for some hooks, and these hooks happen too early for the image file condition that it can only determine its final value after the last file loading hook is handled. So in the end this particular condition is handled asynchronously.

off-topic: why are we discussing this in a sub-thread attached to a single line change? it's inconvenient

libplacebo supports sliced texel uploads on d3d11 and vulkan, and mpv no longer defaults to opengl on any platform so this shouldn't be an issue.

I don't see how that's related since texture limits will still apply, won't they?

neither does any image viewer using imlib2

okay? that just means those other image viewers are also bad

Are you OK with enabling it globally by default?

If it works and has no other undesirable effects: sure why not.

I never saw even one of these images bigger than GL max texture sizes in years of real world usage,

I agree it's not very common but I have wanted to view big images in real usage.

image-input.conf is a workaround to not use deprecated input sections, which let you specify key bindings with {image} in the same input.conf

AFAIK input sections are only deprecated for what users do with mpv. there's no reason we can't add new features inside mpv that rely on them, for example encoding does too.

Or what usefulness does seeking with arrow keys have on an image file with 1 frame?

see sunpenghao's response for this.
Introducing a dynamically switched second set of controls has to be done carefully to avoid confusing situations. Not saying we can't do it.

There would no advantage to make it keep seeking, because seeking images doesn't do anything.

~~Doesn't it go to the next playlist item when you reach EOF?~~ (it doesn't)

What about holding RIGHT to skin over a video and when EOF has been reached and the player jumps to the next playlist item and they accidentally skim through the next file too?

What? This is literally working as designed, because the RIGHT key has a defined meaning and it keeps getting applied if you hold the key.

anyway:
Personally I think a dedicated image viewing mode is scope creep and I would rather suggest making it an user script and maybe prominently advertising it, but not including it in mpv core.

na-na-hi · 2024-11-23T15:12:44Z

input/input.c

@@ -1477,9 +1481,13 @@ static bool parse_config_file(struct input_ctx *ictx, char *file)
    bstr data = stream_read_file2(file, tmp, STREAM_ORIGIN_DIRECT | STREAM_READ,
                                  ictx->global, 1000000);
    if (data.start) {
+        bstr section = (bstr){0};
+        if (!strcmp(mp_basename(file), "image-input.conf"))


Add a section parameter to parse_config_file instead of this hard coding.

Though the advantage of having there was that if you load-input-conf image-input.conf later, it is added to image key bindings.

Added the check in load-input-conf too.

guidocella · 2024-11-27T15:59:40Z

(continuing in the base thread)

It only applies profiles for some hooks, and these hooks happen too early for the image file condition that it can only determine its final value after the last file loading hook is handled. So in the end this particular condition is handled asynchronously.

I don't understand what you mean here since tracks are available in on_preloaded. If it's really faster in C, we can try to apply the profile from there though.

For input sections I got the feeling from the commit message that wm4 wanted the replace the mechanism itself, but indeed encoding mode uses them, just recently a user on IRC wanted to rebind seek and other keys in encoding mode and I explained to him that he needs to add them in the encoding section, how will he do that if they are totally removed? So that would be another reason to keep using them.

For seeking, it doesn't change playlist entry in images because they are treated like videos with infinite duration, as we already discussed in IRC.

llyyr · 2024-11-27T16:19:53Z

Personally I think a dedicated image viewing mode is scope creep and I would rather suggest making it an user script and maybe prominently advertising it, but not including it in mpv core.

I'd argue displaying images is a subset of an application dedicated to displaying video, this is supported by the fact that all it needs for mpv to become a fully fledged image viewer is input bindings and a lua script for cursor centric zoom and better panning (and the Lua script is useful on videos anyway, so it should be merged even if you decide you don't want the image viewer bindings).

guidocella · 2024-11-27T16:25:43Z

I'd argue displaying images is a subset of an application dedicated to displaying video, this is supported by the fact that all it needs for mpv to become a fully fledged image viewer is input bindings and a lua script for cursor centric zoom and better panning (and the Lua script is useful on videos anyway, so it should be merged even if you decide you don't want the image viewer bindings).

Yeah I agree that images are a subset of videos, same as audio, and as a consequence it doesn't require adding much code to improve browsing them. It's not like we're turning it into a PDF viewer.

Dudemanguy · 2024-11-27T17:00:24Z

I didn't look at the specific bindings in question (and probably won't anytime soon; gonna be busy), but I have conceptually no problem with this. I view images in mpv quite often, we're almost certainly the best native wayland image viewer, and keybinds that do things like control volume are 100% useless on images.

BergmannAtmet · 2024-11-28T00:59:23Z

keybinds that do things like control volume are 100% useless on images.

Wrong!

Mixed-media playlists (videos, audio, images) are common (e.g. mpv <folder>). And a user may decide for example to lower the volume for upcoming items in a playlist while viewing an image (or a video without audio). I do this myself sometimes, and any change to that would break my expected workflow.

And I would have been doubly confused if I didn't stumble upon this PR, because I would naturally debug with mpv --input-test -, and that would presumably have made my head scratch harder!

This is in part why, IMHO, and beyond scope creep already mentioned, this is probably conceptually a bad idea.

llyyr · 2024-11-28T02:15:31Z

Mixed-media playlists (videos, audio, images) are common (e.g. mpv <folder>). And a user may decide for example to lower the volume for upcoming items in a playlist while viewing an image (or a video without audio). I do this myself sometimes, and any change to that would break my expected workflow.

https://xkcd.com/1172/

Hi,

there are multiple bindings for changing the volume in mpv. Wheel up/down, / and *, numpad divide/numpad multiply, 9 and 0. The only key bindings that are being changed is wheel up/down. The rest still change volume on your image file. Even if your workflow involved changing the volume specifically with mouse wheel on an image because you anticipate a loud video on the next playlist item, you'd see that the keybind is not doing what it is supposed to. Wonder why it changed, maybe ask about it in IRC/issues/discussion or find the documentation/changelog yourself, disable the image bindings forever and never think about it again.

Of course if enough people think a few bindings changing is really that bad, it can be opt-in instead of opt-out.

na-na-hi · 2024-11-28T02:35:52Z

The only key bindings that are being changed is wheel up/down. The rest still change volume on your image file.

mpv/etc/image-input.conf

Line 59 in 3d1de9c

#0 no-osd set video-zoom 0; no-osd set panscan 0 # reset zoom

there are multiple bindings for changing the volume in mpv. Wheel up/down, / and *, numpad divide/numpad multiply, 9 and 0.

Only Wheel up/down and 9 and 0 make sense on a laptop, and both of them are modified by the image keybinds.

BergmannAtmet · 2024-11-28T11:35:45Z

https://xkcd.com/1172/

Yeah, I wanted to write "no XKCD reference intended" when I mentioned workflow. But then I thought that might sound passive-aggressive since only a junior's mind would immediately go there.

guidocella · 2024-11-28T11:44:13Z

Literally XKCD 1172, default image key bindings shouldn't be optimized for a use case as ridiculous changing volume in images. If you don't want them you can disable them.

Moved all the key bindings in the image section so as to use 1 input.conf. I never believed that somebody is going to rewrite the whole input section system without wm4 anyway.

github-actions · 2024-11-28T11:53:47Z

Download the artifacts for this pull request:

Windows

macOS

BergmannAtmet · 2024-11-28T12:14:53Z

Literally XKCD 1172

Really? What undisputed bug does this fix that me or anyone else complained about?

And if changing volume doesn't make sense when there is no audio, then should it be removed from videos with no audio tracks too? (an average user would ramp up volume before noticing there is no audio track with F9). That incidentally is how mpv behaved a very long time ago before wm4 fixed it.

I'm sure someone somewhere has some script that does something with such files. Maybe printing "NO AUDIO" on the video, or activating some lip-reading transcriber. Should mpv make such a script builtin behavior and rebind 9 and 0 to adjust some parameters from it?

Arguably, that line of thought would be closer to what that comic describes (what a silly thing to center an argument around).

Samillion · 2024-11-28T12:26:45Z

And if changing volume doesn't make sense when there is no audio, then should it be removed from videos with no audio tracks too?

Honestly, yes. To be more precise, in this focused mode (image mode) it would be useful to use what you'd expect to be available for viewing images (as an image viewer would).

I feel the discussion has gone way over the top in fear of change. This is a genuine addition to mpv's feature spectrum of possibility and can be customized by any specific use case. I'm not sure why there is a panic.

P.S.
I genuinely appreciate these additions, which will enhance my image viewer mode

Also, to the note about removing elements, this has been requested on the osc I maintain, which I implemented in ModernZ#244

llyyr · 2024-11-28T12:27:34Z

Really? What undisputed bug does this fix that me or anyone else complained about?

It introduces a new feature, an image viewer mode that makes mpv a capable image viewer. The pros of this mode have already been listed, of course you're free to not want to use mpv as your image viewer and it's trivial to disable it if you don't like it.

Your "workflow" is stupid and not worth considering, sorry.

guidocella · 2024-11-28T12:30:54Z

Really? What undisputed bug does this fix that me or anyone else complained about?

Improving image viewing is a feature, not a bug. But see #7983 for an example of people requesting it.

And if changing volume doesn't make sense when there is no audio, then should it be removed from videos with no audio tracks too? (an average user would ramp up volume before noticing there is no audio track with F9). That incidentally is how mpv behaved a very long time ago before wm4 fixed it.

It is not worth defining different key bindings for videos without audio but they don't benefit it from it nearly as much as images. Software isn't black or white, we need to consider when changes are worth it.

I'm sure someone somewhere has some script that does something with such files. Maybe printing "NO AUDIO" on the video, or activating some lip-reading transcriber. Should mpv make such a script builtin behavior and rebind 9 and 0 to adjust some parameters from it?

But this PR doesn't override user key bindings, those take priority.

This makes mpv a good image viewer out of the box, as it is currently hard to setup. It adds a builtin image conditional profile that users can extend in mpv.conf. It is written to not restore and reapply the options on each image change, because that is slow for certain options (e.g. --d3d11-flip=no restarts the VO), and causes visible flicker when options like gamma are unapplied before changing image and reapplied on the next image. But it still restores the previous options after switching to a video or audio file. Default image key bindings are defined in the image input section. sxiv is their main inspiration.

guidocella force-pushed the image branch from 4717c28 to e5a64a1 Compare November 23, 2024 09:55

guidocella force-pushed the image branch from e5a64a1 to 8625f2c Compare November 23, 2024 10:09

kasper93 reviewed Nov 23, 2024

View reviewed changes

guidocella force-pushed the image branch from 8625f2c to 9a03ede Compare November 23, 2024 11:14

llyyr reviewed Nov 23, 2024

View reviewed changes

guidocella force-pushed the image branch 2 times, most recently from 59ede19 to 1e0cb0a Compare November 23, 2024 14:48

na-na-hi reviewed Nov 23, 2024

View reviewed changes

guidocella force-pushed the image branch 2 times, most recently from e44d86e to a3bf619 Compare November 24, 2024 07:11

guidocella mentioned this pull request Nov 24, 2024

command: add unload-input-conf command #15344

Closed

guidocella force-pushed the image branch 4 times, most recently from 16b5e00 to f8315df Compare November 24, 2024 16:39

guidocella marked this pull request as ready for review November 24, 2024 16:43

guidocella force-pushed the image branch 6 times, most recently from 769bd5d to 3d1de9c Compare November 27, 2024 14:20

guidocella force-pushed the image branch from 3d1de9c to a3077f1 Compare November 28, 2024 11:39

guidocella force-pushed the image branch from a3077f1 to 469dfb8 Compare November 28, 2024 13:54

various: define builtin options and key bindings for images #15346

Are you sure you want to change the base?

various: define builtin options and key bindings for images #15346

Conversation

guidocella commented Nov 21, 2024 • edited Loading

guidocella commented Nov 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kasper93 Nov 23, 2024 • edited Loading

Choose a reason for hiding this comment

guidocella Nov 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

llyyr Nov 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sunpenghao Nov 26, 2024 • edited Loading

Choose a reason for hiding this comment

sunpenghao Nov 26, 2024 • edited Loading

Choose a reason for hiding this comment

na-na-hi Nov 26, 2024 • edited Loading

Choose a reason for hiding this comment

sfan5 Nov 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guidocella commented Nov 27, 2024

llyyr commented Nov 27, 2024

guidocella commented Nov 27, 2024

Dudemanguy commented Nov 27, 2024

BergmannAtmet commented Nov 28, 2024

llyyr commented Nov 28, 2024

na-na-hi commented Nov 28, 2024

BergmannAtmet commented Nov 28, 2024

guidocella commented Nov 28, 2024

github-actions bot commented Nov 28, 2024 • edited Loading

BergmannAtmet commented Nov 28, 2024

Samillion commented Nov 28, 2024

llyyr commented Nov 28, 2024

guidocella commented Nov 28, 2024

guidocella commented Nov 21, 2024 •

edited

Loading

kasper93 Nov 23, 2024 •

edited

Loading

guidocella Nov 23, 2024 •

edited

Loading

llyyr Nov 23, 2024 •

edited

Loading

sunpenghao Nov 26, 2024 •

edited

Loading

sunpenghao Nov 26, 2024 •

edited

Loading

na-na-hi Nov 26, 2024 •

edited

Loading

sfan5 Nov 27, 2024 •

edited

Loading

github-actions bot commented Nov 28, 2024 •

edited

Loading