One other thing I wanted to add: I tried to mimic the Music/iTunes sdef reasonably closely, so I used the same FourCharCodes for equivalent commands/properties, and followed the FCC naming prefix convention (e for enum, p for property, etc.).

Hit close by accident. 🤦🏻‍♂️

More notes as I remember them:

• AppDelegate has a stub for handlePlayCommand:; it'll probably just forward to the frontmost player.
• play could take a file or URL, but using open might be better? Cocoa scripting conflates the direct parameter and the command target without some AppleEvents property finagling.

I'm guessing the build failed due to using key paths as functions and Travis not being updated to the Xcode 11.4 image yet.

Is there anything that looks missing from here that should be in for a first go?

Why leave the WIP label here?

@Wevah I forked your fork and merged the applescript branch. I can now open the sdef in Script Editor, but doing anything results in no actions (e.g. playpause, play, and pause don't work). Is this normal? My understanding is that your code works? Can you take a look if I'm doing anything wrong? https://github.com/sclsj/iina.

@sclsj Hm, the only things you should need are the .sdef, the files with the extensions on various classes and the minor tweaks to those classes (I think I added a referential property to at least one of them).

I.e., yeah, my branch should just work. :/

Why leave the WIP label here?

Good call; removed.

Well this is annoying: The xcworkspace file opens empty in the latest Xcode I can run on this old machine. 🤔

I might have to wait until my new MBP comes next month to make sure this is all still working.

Edit: Wait, nevermind: The xcodeproj can build; I just needed to re-download the prebuilt libs.

@Wevah I forked your fork and merged the applescript branch. I can now open the sdef in Script Editor, but doing anything results in no actions (e.g. playpause, play, and pause don't work). Is this normal? My understanding is that your code works? Can you take a look if I'm doing anything wrong? https://github.com/sclsj/iina.

I think I see the issue; you need to tell an individual player to playpause, etc., since conceivably someone could have multiple players open:

tell application "IINA"
	tell front player to playpause
end tell

Maybe I should add an app-wide version that automatically forwards to the first player?

Now I remember why it was marked as WIP still; I missed a few things.

@Wevah Your script worked. Additional question: How would I pause the currently playing player and how would I start the last playing player? (Basically controlling the "now playing widget" using applescript. Let me know if there is a better way of doing it.)

@sclsj You'd probably have to store a reference to the active player—or the player's id—somewhere if you've got multiple players open.

Some feedback from another IINA user...
Nice work!!

I successfully built the PR natively on an Apple Silicon Mac running Monterey 12.0.1 with mpv 0.34.0 and FFmpeg 4.4.1. I ran several AppleScript tests and they passed. Yeah!

I am not an AppleScript expert, so I could be wrong about some of the issues I'm about to bring up. See what others think.

This new warning is being emitted. Whatever is causing it needs to be fixed:

2021-11-21 17:19:18.691940-0500 IINA[44532:1033619] .sdef warning for argument 'FileType' of command 'save' in suite 'Standard Suite': 'saveable file format' is not a valid type name.

IINA's support for AppleScript should follow Apple standards as much as possible. In particular we want to insure the AppleScript capabilities provided by the Cocoa Framework work as expected. This shows a problem:

low-batt@gag ~$ osascript -e 'tell application "IINA"' -e 'activate' -e 'open "/Users/low-batt/Movies/issue-316.mp4"' -e 'end tell'
missing value

Running the same script against QuickTime shows what is wrong:

low-batt@gag ~$ osascript -e 'tell application "QuickTime Player"' -e 'activate' -e 'open "/Users/low-batt/Movies/issue-316.mp4"' -e 'end tell'
document issue-316.mp4

The IINA.sdef contains:

<xi:include href="file:///System/Library/ScriptingDefinitions/CocoaStandard.sdef" xpointer="xpointer(/dictionary/suite)"/>

Which is fine if you fully follow the Cocoa conventions. These standard definitions expect that NSDocument is being used. QuickTime is using documents. It makes sense for QuickTime because it is not just a player. It has operations like trim that make modifications that require saving, whereas IINA is strictly a player. Need to consider now if IINA will in the future add features that involve modifying and saving files. If so, then some thought should be given as to whether IINA should be using NSDocument. It is not hard to add that support.

The Cocoa Standard definition in question is:

<command name="open" code="aevtodoc" description="Open a document.">
  <direct-parameter description="The file(s) to be opened.">
    <type type="file"/>
    <type type="file" list="yes"/>
  </direct-parameter>
  <result description="The opened document(s).">
    <type type="document"/>
    <type type="document" list="yes"/>
  </result>
</command>

The open command must return a document if that definition is used. IINA must either adopt the Cocoa QuickTime "document" pattern or address this issue in another manner.

Looking at the definitions using the Script Editor:

The QuickTime definitions contains an "Internet Suite" with an "Open URL" command., would be nice if IINA had this.

Would be nice for IINA to have commands for "Next Frame" and "Previous Frame".

QuickTime has "audio volume" whereas IINA has "sound volume", the term used by the Music app . Since IINA refers to this as "audio / volume" in the menus the AppleScript definitions should match up with the naming used in the menus. Would also be good to provide some sort of indication of what values are expected like the QuickTime definitions do.

Apple's AppleScript naming guidelines stress the importance of not picking a name for a property that makes it seem like a command. I expect that is why the QuickTime property is named "muted". The IINA property is named "mute", likely coming from the Music app which failed to follow the guidelines and has a property named "mute".

IINA has a "pause" command, would be nice to have a "resume" command like QuickTime.

Hi @Wevah, I want to communicate with IINA via AppleScript in my app. This pr seems very promising and I’d like to work on it right now. I’m wondering if there will be major changes in sdef file. Small changes like renaming a property is acceptable. Or I need to wait a bit longer for the script interface to stabilize?

@ddddxxx It looks like this got merged into develop, so there probably won't be many more changes to the functionality as it exists now unless something breaks.

Edit: I misread the project this was merged into; see below.

Busy today, having to write this in a rush...

@ddddxxx Here is my own opinion on your question:

All bets are off until this feature is in an official released version of IINA. Program against the current proposed interface at your own risk.

The reason I say that is because of the issue you are raising. Unlike other IINA features where the user interface can be "tweaked" in future releases and humans can adjust to it, this feature requires that backward compatibility with programs and scripts be taken into account when making any future changes. For that reason this feature requires an intense detailed picky peer review as well as feedback from Beta test users. Since that has not been completed there is no guarantee that the interface will not change.

@Wevah has done some great work here. It is on my list to take a close look at this but I've been distracted, trying to fix other issues.

NOTE that this has NOT been merged into IINA yet. That is why this PR is still open. The merge notice seen above is because CarterLi merged it into his fork, "IINA-Plus".

Ahh, whoops! I may be heavily distracted. I did find it a bit odd, and should have looked closer…

... this feature requires that backward compatibility with programs and scripts be taken into account when making any future changes. For that reason this feature requires an intense detailed picky peer review as well as feedback from Beta test users.

You are right. However I don't think there are many Beta test users. No one can tell if an API is stable without actually using it ( implementing something based on it ). It can be a good time to prove this API is good enough to use or not.

iina-plus is a place experimenting bleeding-edge features, and I think it works well so far.

Thank you so much for AppleScript support. I can finally set global shortcuts to play and pause IINA, which is great for me as I learn to use Blender while watching the video tutorials. Hopefully there will be support for forward and backward (seek) actions in the future !