Linked by Thom Holwerda on Wed 15th Nov 2017 23:59 UTC
BeOS & Derivatives

Haiku's GUI is in principle entirely scriptable. You can change a window's position and size and manipulate pretty much every widget in it. The tool to do this is hey. It sends BMessages to an application, thus emulating what happens if the user clicks on a menu, checkbox, or other widgets.

Thread beginning with comment 651007
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by DefineDecision
by hhas on Thu 16th Nov 2017 22:32 UTC in reply to "Comment by DefineDecision"
hhas
Member since:
2006-11-28

That being said, the examples seem a bit.... clunky. I think AppleScript could have been shining the beacon w.r.t. GUI app automation


The key to “AppleScript” automation is that it isn’t about mimicking users’ GUI interactions. An Apple event API is a complete, dedicated View/Controller layer that sits alongside the app’s GUI View/Controller, exposing an interface to the app’s data and behaviors specifically tailored for remote programmatic control.

(Incidentally, one of Apple event IPC’s most distinctive features is that it’s not based on the now-common Object-Oriented interaction model you see in the likes of DOM, but rather on RPC plus simple first-class relational queries, more akin to SQL+RDBs; a potential killer USP if today’s Apple had the wits to combine it with their query-building Siri UI… which they don’t as they’ve long since slipped from Thrilling Market Innovator to Just Another Corporate Bureaucracy.)

GUI Scripting, on the other hand, is an unforgivable atrocity that should be shot the moment it attempts to raise its head. Its only value is in writing GUI test scripts; any ingenious idea to use it for other purposes is Already Failed.


However, the AppleScript language was weird, so it never got a lot love from programmers. Automator was a late addition to help encourage AS development, but didn't help in the end


Automator was never about extending AS; it was a Cocoa API through and through. ObjC-based Action plugins could use AEs to communicate with other processes, but the APIs for that were even more crap than AS. And for most App developers the cost of implementing Automator Actions far outweighed any ROI, so it never scaled well.


JS was added later on, but by then, Apple had gutted the division.


Nope, not only did Apple expand the Automation team in order to develop JavaScript for Automation (from 2 developers to 3), they even took the JavaScriptCore project that the JSCore/WebKit folks had announced at WWDC13 as an AS alternative and handed it to the Automation team instead. The fundamental failure was PEBKAC: specifically, Sal Soghoian, head of the Automation team, was a fucking terrible Project Manager (a talented Automation evangelist promoted way beyond his level of competence; see: Peter Principle) who in his last decade at Apple effectively ran Mac Automation into the ground.

Result, the Automation team shipped JXA half-baked and half-broken in 10.10, then not only did they not try to fix it but didn’t even bother to document, promote, or support it. Unsurprisingly, JXA completely failed to capture any market, despite having millions of sitting JS users right there for the taking, with an incredibly powerful, widespread Automation infrastructure that should by all rights be Utterly Irresistable Industrial-Strength Catnip For Geeks™. That incredible failure is what got Sal’s ass belatedly sacked and his team disbanded.

If you’re curious, this is what an Apple event bridge for JavaScript should look like:

https://bitbucket.org/hhas/nodeautomation

Documentation’s a bit shit, as it’s decade-old recycled mess that I’ve never bothered to rewrite. But at this point I only really write these things for shits and giggles, and to prove other people wrong. (If you’re really curious, here’s the “OSA-packaged JSCore” reference implementation I sent Sal before 10.10 shipped: https://sourceforge.net/projects/appscript/files/ – bit messy/buggy as it was done in a huge rush, but still better’n the crap they shipped, and even has a nifty automagical AS-to-JS translation tool for turning AS commands into their equivalent JS syntax which alone would’ve gone a long way to making it a popular success.)

But anyway, I digress…TL;DR, Apple event IPC = Awesome Automation infrastructure, designed right and still the benchmark by which all others should be judged, screwed by being shackled to a shit language-cum-brand name and squandered by a vast not-nearly-as-bright-as-you-think corporation that after 20 years is quietly preparing to throw it away for good. (If FOSS/Linux had an ounce of sense, they’d steal all its concepts and philosophy and bat it out the park with nominal effort…eh but who are we kidding.[sad])

Reply Parent Score: 6

RE[2]: Comment by DefineDecision
by zima on Fri 17th Nov 2017 14:17 in reply to "RE: Comment by DefineDecision"
zima Member since:
2005-07-06

So... it seems like you might be the local MacOS automation expert? ;) I have a related question...

Some time ago I got a Connectix QuickCam, the 1st webcam, connected to ~classic Macs through the ADB port. And... what else to do with it than to put it on the web! ;) Some caveats though...

I do not have the drivers/software, I must yet to hunt it down on the web. And, having little experience with classic MacOS, I do not know how OS-version specific it is - would the driver be "universal" across 68k and PPC, or across OS 7.x, 8.x, 9.x ...or not?

Also, I do not yet have a required Macintosh. It would have to be a machine with ADB and Ethernet ports, so probably some PPC Mac running MacOS 8.x or 9.x...

The way I want to use it, is to take a photo every minute, give it a name in the YYYYMMDDHHMM format, then upload it to a server for the world to see ...is learning AppleScript my only option on such setup? ;) (what resources would you recommend?)

Reply Parent Score: 3