Allow interapplication communication between apps on macOS using JavaScript for Automation.

JXA Documentation

Posts under JXA tag

4 Posts
Sort by:
Post not yet marked as solved
2 Replies
466 Views
I'm trying to automate making accurate alarms to help me estimate when I need to leave to be on time for meetings. To do this accurately, I want to access Apple Maps (or Google Maps services, or ...) to get an estimate of driving times given current driving conditions. So I'd like to query the maps service reasonably close to departure time. (If I get an estimate on Sunday evening at for an appoint on Monday at rush hour leaving from a different location, it's obviously going to be inaccurate.) Ideally, I'd like to directly access my Apple Calendar to get the appointments and their locations. But if that's too complicated, I'll just create a formatted text file or sqlite file or whatever with the information. I've considered doing this with Shortcuts, Automator, AppleScript, JXA, Hammerspoon, Python, etc. It seems that each technology has part of what I need, but not all. But I don't have deep knowledge of any of them. Perhaps someone can advise me on the most appropriate technology. Here are my impressions: Shortcuts: Has built in access to driving time estimates and Calendar events, but awkward and possibly too limited in terms of program logic. Automator: Is more capable than Shortcuts in some ways, less in others. AppleScript: I don't know. JXA: I prefer Javascript to AppleScript, but it seems hard to find good documentation. Python: I'm quite proficient in Python, but I don't know if I can access things like Calendar events. If not, I'm willing to keep a separate file manually. (I could perhaps create the Calendar events from this, except that some appointments are set up by my work.) Hammerspoon: I don't have any experience with it and don't know it's capabilities. Any advice appreciated.
Posted
by Addle.
Last updated
.
Post not yet marked as solved
0 Replies
330 Views
I am attempting to automate the movement of my mouse fully through Apple software. I have tried a variety of things, and I am now on the Dev Forums because I've ran out of ideas. Some of the things I have attempted are: Full Keyboard Access, Mouse Keys, Accessibility Keyboard with Panel Editor actions. Please, feel free to share any advice you may have. My goal is to only move the mouse enough for the computer to know it is active. That could be one pixel. Mouse keys works, but I can't get it to automate, I still have to click "u" and "o" to move the mouse. Thanks for any advice y'all may have! Have a blessed day!
Posted
by Overcomer.
Last updated
.
Post not yet marked as solved
0 Replies
876 Views
I'm specifically talking about macOS because the others are very different beasts. Since, well literally the first release of OS X 10.0, there has not been a coherent automation framework on the Mac. The last OS to offer that was Mac OS 9.X To define terms, by coherent, I mean from the command line environment up through the user interface. A single, coherent automation framework that is usable across the entire OS, ala PowerShell on windows. That doesn't exist for current macOS, nor has it ever existed for any variant of macOS since again, Mac OS 9.X At best it has been a pastiche of completely different frameworks, operating modalities and languages all desperately trying to work together via osascript and do shell script. That any of it works at all is like a talking dog: the fact the dog talks is a miracle, bad grammar is minor. Yes, I know Shortcuts exist, but shortcuts are a developer managed bit of pseudo-automation. If I limit myself to Shortcuts, then I have little to no ability to do anything beyond what the developer of that application chooses to allow me to do. For example, at least as of Ventura, Dictionary, Font Book, iMovie and others have no shortcuts. I can't create my own shortcut for those apps, the devs have to do that. (the fact that Apple is not flooding us with Shortcuts shows how little Apple cares as a company about this. Individual teams wax good and bad, but clearly, Apple doesn't think dogfooding here is important.) (Note: if your only comment is to ask why anyone would care about automating , that's absolutely not the point. The idea is to make it possible for everyone, not just developers, to create in ways no one can predict outside of an application's constraints.) "Well, there's always AppleScript/JXA" I will not write down the laughter here, but there is laughter. As of Ventura, there are no less than 32 Apple applications with no scripting dictionary at all, so neither AppleScript/JXA can work. You might be able to use UI scripting, but no guarantee there, and UI scripting is a fragile thing, at best suited to a last resort option. Again, Apple could lead the way, they choose not to. But that's only the UI levels. Below the UI, then there's no coherency at all. You're stuck with shell scripts and whatever a given utility's author chose to allow, and sharing data and information is no better than at the UI level, and neither the command line level nor the UI level know the other exists. The only way to combine the two is again: Do Shell Script Osascript That is not a coherent automation framework. Then of course, there's the lack of documentation. AppleScript has inherited at least the language guide, which is well-written and usable, but the command line level has man pages. Which are the most inconsistent things. Some utilities' man pages are remarkably useful, others don't even have man pages. At all. Other utilities man pages have syntax errors for the command that brings up the help page and that is all the man page does. Ponder the disconnect there: --help provides detailed usage information that is not in the man page. The man page says use ---help which is bad syntax. This seems odd, but why is the --help output not also in the man page? Is that not the purpose of the man page? Man page inconsistencies aside, Apple developer support has only ever barely acknowledged automation/scripting and really never supported it except for accidentally. Even in a language like AppleScriptObjecttiveC, (ASOC) which one can use for real apps in the MAS, the response from DTS for help was "use the mailing list." (not that DTS is that good anyway, I had an issue with CoreWLAN in ventura, and have since been ghosted on any notification that the OS bug that was causing me problems has been fixed. Maybe it has, maybe it hasn't. I can test for it, but why did DTS ghost an actual SwiftUI issue for an app written in Swift? ¯_(ツ)_/¯ This is a solveable problem, Microsoft has solved it in terms of language, documentation and coherency, with PowerShell. Leaving aside architectural issues that make it almost impossible to properly secure windows, the way MS treats PowerShell is the example. Windows as an OS has excellent support for automation, the documentation for PowerShell is amazing, (the documentation for a scripting language is better than Apple's entire developer docs, which is just inexcusable.) The difference between automating either platform is night and day, and in a race with two horses, Apple is a distant fifth. The language syntax here is almost a non-issue. In fact, I think using a "powershell'd" version of Swift would be an excellent idea. Create a simpler version of swift in the way PowerShell is a simpler version of C#. Make it so if you need to call a framework outside of the main automation framework, you can do so with ease, ala PowerShell. For example, PowerShell has no GUI primitives the way AppleScript does, so to create a file choose browser in PowerShell, you instead invoke the correct .NET framework: Add-Type -AssemblyName System.Windows.Forms $FileBrowser = New-Object System.Windows.Forms.OpenFileDialog -Property @{ InitialDirectory = [Environment]::GetFolderPath('Desktop') } $null = $FileBrowser.ShowDialog() Ironically, you can do this with ASOC, but only for items that have ObjC interfaces, which will be shrinking. Having a coherent automation framework with a primary language that allows people using it to more easily use "full" Swift and its frameworks as needed is a force-multiplier for Apple. It would help people do more with macOS and maybe other platforms depending on implementation, not less. It would not force people to beg the developers of their apps to write Yet Another Shortcut to do this thing that they can't do, (or have to do the dance to convince the dev that their need is worth the trouble), and it would allow people to solve their problems in their own ways for their own needs. But, it requires Apple to care about this at all, and that is where the problem is. This is fixable, Apple has the resources to fix it, what they lack is interest and desire. But creating and fully supporting a proper automation framework would add so much to macOS and the other platforms by extension that there's no logic behind not doing so. Maybe next year. (in the best lol of all, you can't even create an automation tag for a post. sigh.)
Posted Last updated
.
Post not yet marked as solved
0 Replies
507 Views
I can't seem to execute Voiceover command with JXA. The following AppleScript works. tell application "VoiceOver" tell commander to perform command "item chooser" end tell However, the following script in JXA throws a mystery error. vo = Application("VoiceOver") vo.commander.performCommand("item chooser") Error 6: An error occurred. I'd really appreciate any help with this! Thanks so much!
Posted
by chibop.
Last updated
.