The killer feature for me is being able to create global keybinds or custom Spotlight commands that can be linked control flow blocks to different drag-n-drop blocks of editable shell script / Applescript / Python / whatever. The keybinds themselves and everything else are drag-and-drop blocks, too. The edge over other keybinding software IMO is that you can define variables and do otherwise complex control flow within a workflow without being limited to "define a list of things to run". For example I could have a 'compile this' keybind that detects language, compiles, and displays stdout of whatever code I'm highlighting.
For Android I'm currently using Tasker, which is a "list of things to run" so it suffers from sometimes having to define multiple tasks for one command. But it's better than the drag-n-drop alternative (Automate), which doesn't allow arbitrary shell commands last I checked.
I wrote production-quality Apple event bridges for half-a-dozen major languages (Apple even considered bundling a couple of them in Leopard). It’s an amazing ecosystem once unlocked with languages that aren’t a bad joke. Thousands of productivity apps with not one but two very high-level User Interfaces: one graphical, one programmatic.
Alas, even the best software in the world won’t fix PEBKAC, and the Mac Automation Product Manager was one of these:
https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
A few thousand hours of solving their problems only for them to promptly un-solve them again, I finally gave up in disgust.
http://appscript.sourceforge.net/status.html
As say upthread, there are better ways to spend your life than trying to fix stuff that others are determined to keep broken. At least I had a laugh when Apple finally sacked that jackass, even if he did take Mac Automation down with him.
For better or worse, the future of macOS Automation now lies in the hands of the Siri squad and their conversational shortcuts. Let’s hope they do better.
https://twitter.com/stroughtonsmith/status/11359563313603461...
#InterestingTimes
Khoi Vinh wrote about shortcuts on his blog[1]. He uses one to automatically archive screenshots to a particular Evernote notebook.
[1]:https://www.subtraction.com/2019/12/04/shortcuts-and-screens...
If you search for shortcuts for logging weight, there are a bunch that log it to the Apple Health App, which is probably a better solution. I only have an iPad though and for some reason Apple won't let you run the Health App on an iPad.
I’ve only done one simple shortcut that lets me say “Get Directions” to Siri and it asks for an address and it launches Google Maps instead of Apple Maps.
Federico Viticci is considered the king of shortcuts in the Mac community.
Apple Events are quite powerful and let you add a lot of functionality.
Personally, I like to write and test Applescripts in the Script Editor, and then throw them into Automator when I'm finished so I can save them as "Services", which means they'll appear in the right click menu of whatever app(s) I choose. But that's entirely optional.
https://en.wikipedia.org/wiki/UserLand_Software#Frontier
>UserLand's first product release of April 1989 was UserLand IPC, a developer tool for interprocess communication that was intended to evolve into a cross-platform RPC tool. In January 1992 UserLand released version 1.0 of Frontier, a scripting environment for the Macintosh which included an object database and a scripting language named UserTalk. At the time of its original release, Frontier was the only system-level scripting environment for the Macintosh, but Apple was working on its own scripting language, AppleScript, and started bundling it with the MacOS 7 system software. As a consequence, most Macintosh scripting work came to be done in the less powerful, but free, scripting language provided by Apple.
Both AppleScript and Frontier supported Apple's "Open Scripting Architecture" (kind of like OLE Automation via Apple Events).
https://developer.apple.com/library/archive/documentation/La...
https://en.wikipedia.org/wiki/AppleScript#Open_Scripting_Arc...
Now Automator lets you use "JavaScript for Automation" instead of AppleScript.
>Under OS X Yosemite and later versions of macOS, the JavaScript for Automation (JXA) component remains the only serious OSA language alternative to AppleScript, though the Macintosh versions of Perl, Python, Ruby, and Tcl all support native means of working with Apple events without being OSA components.
https://hackernoon.com/javascript-for-automation-in-macos-3b...
https://apple-dev.groups.io/g/jxa/wiki/JXA-Resources
https://github.com/JXA-Cookbook/JXA-Cookbook/wiki
As an example task similar to what the article discusses, whose source code is actually readable, here's a script to change the font of all text in all master slides in Keynote. (Probably the world's first JXA script written in Literate CoffeeScript).
https://github.com/JXA-Cookbook/JXA-Cookbook/wiki/Examples#k...
I wrote more about Frontier and other automation tools:
https://news.ycombinator.com/item?id=20425970
>The thing that's missing from "Google Docs" is a decent collaborative outliner called "Google Trees", that does to "NLS" and "Frontier" what "Google Sheets" did to "VisiCalc" and "Excel".
“As an example task similar to what the article discusses, whose source code is actually readable, here's a script to change the font of all text in all master slides in Keynote.”
That’s a good example of how not to use Apple events, which are notoriously high latency. Here’s the simpler, efficient canonical solution:
Application('Keynote').documents[0].masterSlides.textItems.objectText.font = TARGET_FONT
..
As to Userland, yeah, Frontier was first and, crucially, knew how to speak Apple events right. But Dave got huffy that Apple didn’t take it and flounced for the nascent Web dev market where they promptly got eaten by PHP.
A pity: ol’ Dave could’ve taken a lesson from Napoleon (“never interrupt your enemy when he is making a mistake”). Mac Automation should be pure geek catnip, but AppleScript is so hideously programmer-unfriendly and unscalable, programmers’ instant loathing of it is the major reason Mac Automation has failed to thrive. Userland could’ve stayed where it was and easily won a robust audience of professional users and developers begging for a non-atrocious alternative. Ah, hindsight’s a wonderful thing.