@svobs Should be able to explain how to add the shortcut for the menu item.

I think adding the keybinding in "IINA Default" input config and it can be automatically matched and show up in the menu.

We do need to get the menu shortcut working. The one suggested is ⌘R. I checked Mac keyboard shortcuts and this is how Apple uses that key:

Command-R: (1) When an alias is selected in the Finder: show the original file for the selected alias. (2) In some apps, such as Calendar or Safari, refresh or reload the page. (3) In Software Update, check for software updates again.

I don't think it is unreasonable to use ⌘R, but I'm not that familiar with IINA's key binding code. Need to hear from @svobs and @lhc70000.

@svobs Should be able to explain how to add the shortcut for the menu item.

Add the 2 lines below to the case statement of handleIINACommand, in PlayerWindowController.swift:

internal func handleIINACommand(_ cmd: IINACommand) {
    switch cmd {
    // […]
    case .showCurrentFileInFinder:
      menuActionHandler.menuShowCurrentFileInFinder(.dummy)
    // […]

Having connectivity problems here...strange... After adding the code I posted above, everything will be in place for the end user to add a row like this one to your Key Bindings configuration:
Key column: Meta+r
Action column: #@iina show-current-file-in-finder

I confirm that it is now possible to set a keyboard shortcut in the settings and it works.

One thing I noticed that when I use two screens MacOS opens the Finder on the built-in screen and does not focus on it, meaning the focus remains on the IINA window. When I only use the built-in screen it doesn't happen. But I'm guessing this is a macOS bug and not something we should be dealing with.

One thing I noticed that when I use two screens MacOS opens the Finder on the built-in screen and does not focus on it, meaning the focus remains on the IINA window. When I only use the built-in screen it doesn't happen.

I believe it has something to do with the Assign To setting in the Dock. Try setting this to different values for Finder and for IINA, respectively.

Some combinations appear to focus on the new Finder window and some do not. For me, using Desktop on Display 1 (main display) for Finder and All Desktops for IINA correctly changed the focus. So I suspect when some combinations don't give focus to the Finder window, that is by design for some reason.

I haven't been able to find documentation for this feature. From playing around, it looks like the All Desktops option will open windows for the app in the same screen that the mouse is currently in at the time of open. But I can't figure out what the None option is supposed to do. And I have no idea why sometimes multiple options are checked. If anyone has any info, please share :)

The shortcut key still needs to be added to iina-default-input.conf, yes? I've not looked to see if that key is available in the other key bindings.

Add the 2 lines below to the case statement of handleIINACommand, in PlayerWindowController.swift

I was in a little bit of a hurry when I wrote that, but I found time to re-evaluate and have determined that adding a case to handleIINACommand is no longer needed. There is a newer mechanism introduced by the fix to #4567 which makes it mostly obsolete. Although it shouldn't hurt anything to leave it there, it can be removed.

I filed a PR, #5012, which has more info if curious.

I'm not sure that Cmd+R fits here, because it's usually used to refresh (in browsers, XCode, etc.)
Might we want it for a streaming refresh? Thoughts?

Apple guidance on custom keyboard shortcuts can be found here. Don't be confused by the entries in the Recommended usage column that are in the wrong row. It indicates the ⌘ key is preferred:

Prefer the Command key as the main modifier key in a custom keyboard shortcut.

Focusing on the keys that trigger IINA actions we can see there isn't a consistent pattern but many use ⇧⌘:

So ⇧⌘ and one of the keys not already used seems right.

Not meant to divert the discussion too much, but there's an alternative is to not set any default keybindings for that and let the user to set whatever they want.

I thought about that, but configuring key bindings is a bit advanced. I would not be surprised if many users looked at the new menu item, saw there was no keyboard shortcut and gave up. Therefore I think it is important we provide a default key binding. I'm thinking ⌃⌘R due to the use of ⌘R by Spotlight.

I suggest ⇧⌘R.

We use ⇧⌘ when possible and I prefer it over ⌃⌘ because it's more comfortable when pressing. The reason we have other modifiers for some shortcuts are

• ⌘3, ⌘+, ⌘- for adjusting window size: these are major functions and should have corresponding mpv commands, but we have custom commands because they need extra handling
• ⌃⌘P for PIP: ⇧⌘P is occupied (show playlist)
• ⌥⌘M for music mode: TBH I couldn't remember 😢

I agree, ⇧⌘R.

We also use the ⇧⌘ convention for the mpv defaults as well, but it looks like we switched to ⌥⌘ for Movist and VLC. So ⌥⌘R for Moviest and VLC?

Note that Apple says:

• Prefer the Shift key as a secondary modifier that complements a related shortcut
• Use the Option modifier sparingly for less-common commands or power features
• Avoid using the Control key as a modifier. The system uses Control in many systemwide features and shortcuts, like moving focus or capturing screenshots

⇧⌘R meets those requirements, yes? We can use that for the IINA and mpv defaults. We will have to hear from others as to why the Moviest and VLC did not use that and instead used option, ⌥, instead of shift, ⇧. To match up with the existing conventions in those key bindings we should use ⌥⌘R in them. See what the other developers say.

• Prefer the Shift key as a secondary modifier that complements a related shortcut
• Use the Option modifier sparingly for less-common commands or power features

That seems almost backwards, no? Some menu items can have "alternate" versions which offer slightly different functionality. These can display an alternate title by holding down the Option key when clicking on the menu. Their key equivalent also incorporates Option.

Example in IINA: Open In New Window… with alternate, Open…

I added ⇧⌘R to iina-default-input.conf. Waiting for a decision about VLC and Movist files.

Please also add ⇧⌘R to input.conf which is the mpv bindings.

Filtering the VLC key bindings shows for some reason ⌥⌘ was used instead of the ⇧⌘ convention:

I'd go ahead and change the Moviest and VLC key bindings to use ⌥⌘R to match up with the existing convention in those key bindings.

I verified the key bindings. I would remove the ⇧ from the Moviest and VLC key bindings and just use ⌥⌘R to match up with many of the other key bindings that bind to IINA functions:

I would remove the ⇧ from the Moviest and VLC key bindings and just use ⌥⌘R to match up with many of the other key bindings that bind to IINA functions

Isn't that what I did? I'm confused

#@iina Alt+Meta+R show-current-file-in-finder

i got it. The R should be a lowercase letter, otherwise Shift is added to the shortcut. pushes a fix...

Great! I will see if I can get the other developers to get this one approved and merged.

@ShlomoCode Thanks for addressing #5001

It doesn't appear in my file menu and doesn't work when added as a key binding. 1.3.5 Build 141|

@cmbail This change has been merged into the development version of IINA. It is not in the current release of IINA.

Issue #5001 was closed automatically by GitHub when this pull request was merged. The downside of that is that it makes it look to users like the issue has been addressed and should be working in the latest release of IINA. I have been trying to re-open issues and leave them open until the change is in the released version of IINA, but it is exhausting to keep up with GitHub's automatic actions. GitHub users have been asking for a way to turn off this auto close feature, but last I looked GitHub has not provided a way to do that.

It is a philosophical different. GitHub views issues as tasks for developers to do. Once a change has been merged then the developer has nothing more to do and GitHub closes the issue. The IINA project views issues as the public defect and feature request database. With that point of view you would not close issues until the features are available to users. Currently the GitHub view dominates.

Sorry about the confusion.

Thanks for clearing that up.