HackerTrans
TopNewTrendsCommentsPastAskShowJobs

hhas

no profile record

comments

hhas
·قبل 4 سنوات·discuss
> Anyone interested in learning AppleScript can search it online or in their documentation, they're not going to distill the full scope and usage for AppleScript for every corner of the operating system where it can be utilized.

…In case anyone was still wondering why AppleScript is already dead.
hhas
·قبل 4 سنوات·discuss
To execute a Python script as a Mail rule action? Horrible.

You need to write an AppleScript which calls `do shell script` to run the Python script, passing data to the Python script via argv or temp file (`do shell script` doesn’t support stdin so you’ve got the added pain of ensuring correct shell quoting and/or file wrangling).

Also, if if you want to pass anything more complex than short simple strings to the Python script then you’ll need to encode that data into XML or JSON which Python can trivially parse out of the box. AS’s own stdlib support is dismal, however, so you’ll need to roll your own code or rummage around online for third-party AS libraries to encode the Mail data in one of those formats.

Be aware too that `do shell script` does not read your `.zprofile` environment settings, so you’ll have to specify the full path to your `python3` interpreter wherever you’ve got that installed.
hhas
·قبل 4 سنوات·discuss
Notes:

1. Apple Mail has had this feature for the last 20 years. If macOS users to whom that feature is of interest are only now realizing it exists, this speaks volumes for Apple’s documentation and marketing.

2. The page says you can use AppleScripts as rule actions. It never tells you how. No sample scripts to use or learn from. No links to the documentation you’ll need to write your own.

Here’s a better third-party introduction from 2005(!) which includes a couple rule action examples:

http://preserve.mactech.com/articles/mactech/Vol.21/21.09/Sc...

TBH, after 6 years rusting in maintenance mode, all its documentation long buried in archive, and the department responsible eliminated entirely, I am surprised Apple would still want to draw any attention to AppleScript at all. They only set up the unwary for disappointment later, once they discover for themselves the platform is already a walking corpse. That is no way to sell product. Alas, post-Jobs Apple cares little for joined-up thinking, or even motivation to do a half-decent job.

Let’s hope the Shortcuts team can eventually make a half-decent success of their product, because AppleScript automation has zero future. That said, if Ventura Mail still can’t use Shortcuts as rule actions then it doesn’t bode look great for them either.
hhas
·قبل 4 سنوات·discuss
Yeah, that page’s .css import is broken (404). The page should look more like this:

http://www.macosxautomation.com/applescript/firsttutorial/02...

That site is Sal Soghoian’s, and my own opinion of the man’s work and his ability to accept criticism is well known. Still, if you can find a way to give him a heads-up his CSS is broken (and probably has been for a decade), crack on. I think even he’ll concede and hopefully thank you for drawing it to his attention.

…

The other thing I’ll say about that particular page is that GUI Scripting is absolutely the worst of the worst, the “Bad Automation” approach to be used only when an app doesn’t provide an “AppleScript” (Apple event IPC) interface of its own.

With GUI Scripting, your script is literally mimicking the interactions of a human user: pushing buttons, reading and typing text in text boxes. This is far from optimal when talking program-to-program.

The whole point of a GUI View layer is to present the data held in the app’s Model layer in a format that is easy for human users to visually read and write with keyboard and mouse.

Conversely, an “AppleScript” View layer presents the same Model data in a format that is easy for other programs to automate. The data is presented as a queryable tree of “objects” (an Apple Event Object Model), with a set of standard commands for manipulating those nodes.

Sal’s tutorial pages I linked to above describe the “Good Automation” which AppleScript is rightly known for.

It’s actually a pretty awesome API and the [few] developers who genuinely “get it” genuinely love it too. Way more REST-ful than what most webapps today call “REST APIs”[1], a powerful, elegant, and very high-level user-queryable abstraction (it’s closest to SQL, *not* OOP). You can find my own (now very old) attempt to explain its conceptual model to programmers at:

https://appscript.sourceforge.io/py-appscript/doc/appscript-...

Not a great explanation, but still way better than Apple’s. Someone else also linked Dr William Cook’s AppleScript paper up-thread, which is a must-read for understanding these principles.

…

Alas, for historical reasons Apple events and AEOM got shackled to AppleScript early on. And while AppleScript speaks Apple events flawlessly, as a general scripting language it is horrible obfuscated crap. But the app-to-app IPC that sits underneath is [when it works right] damned awesome.

--

[1] “REST API” is an oxymoron: REST describes how “REST-ful” apps’ *UI/UX* should universally behave at a high-level. How the interface should look and feel to its users, regardless of whether a given user is a machine or a human; not list low-level procedure calls and arguments. Like HTTP, Apple events suffered terminally weak, unhelpful, incomplete early documentation, and all the misconceptions and dysfunctional implementations subsequently arose from that.

Fielding’s thesis should’ve been the web’s equivalent to Apple’s Human Interface Guidelines, but was published a decade too late to have any influence, and lacking good and bad working examples of real-world design for non-academic readers to follow/avoid. Likewise, Apple didn’t publish its Scripting Interface Guidelines (https://developer.apple.com/library/archive/technotes/tn2002...) until over a decade after AppleScript’s release.
hhas
·قبل 4 سنوات·discuss
No. Cross-platform Siri [Shortcuts] plus App Extensions and App Intents will. That’s where Apple sees the future of end-user automation now: providing 1% of the power to 1000× (it hopes) more customers.

Will Apple’s new strategy actually work? Eh, maybe. It is not a great plan, but Apple has more than enough resources to brute-force it to “[Barely] Good Enough” status so at least its backers can declare great success.

And, to be fair, if Siri plus App Itents can enable even 10 million iOS users to tell their phones to perform trivial tasks for them, that will be a huge, genuine achievement on Apple’s part. While transitioning from AppleScript to Shortcuts takes away the Lego Techniks for anyone to build new functions (only professional Swift developers will have power to do that), the Duplo blocks it provides in return are easier to use.

…

That said, a more cunning plan could provide 100% of the capabilities to 1000× of the users, and probably more. ’Cos what AppleScript sits on is a huge trove of [mostly] standardized query handling applications, and Siri itself is a query builder.

Anyone suffering terminal insomnia and compulsive sado-masochism is welcome to read the alternative (independent, community-driven) plan I proposed in these 2 posts:

https://forum.latenightsw.com/t/petition-apple-for-applescri...

https://forum.latenightsw.com/t/petition-apple-for-applescri...

(Be warned: most of that thread is just me showing my ass to the world’s last entrenched handful of reactionary AppleScripters who do not want to imagine a future without AppleScript, because that future is not all about them any more, so they don’t. Ah well, I suck. My offer stands to anyone mad enough.)
hhas
·قبل 4 سنوات·discuss
If you really want to script macOS apps using JavaScript, try nodeautomation:

https://www.npmjs.com/package/nodeautomation

JXA is buggy and crippled, with abysmal documentation and zero community or official support.

nodeautomation is provided without warranty or [unpaid] support, but at least it works right and I will keep maintaining it for as long as I use it myself (maybe 3-5 years, as it’s part of my AppleScript-to-UXP migration toolkit for Adobe CC scripters).

If you can run[1] the ASDictionary and ASTranslate support apps they answer 95% of “How do I…?” questions for you.

That all said, you really are best sticking to AppleScript. The language sucks and its community moribund, but at least there are people there who understand how to use it with the various “AppleScriptable” apps who can help you when you get stuck.

--

[1] Both apps are written in Python3 and py2app, and I haven’t bothered to codesign those releases (it’s a chore) so M1/M2 Macs will probably refuse to run them. (If anyone really cares, they can jump up and down on me to do so or, even better, codesign them for me so I can just post those builds.)
hhas
·قبل 4 سنوات·discuss
AppleScript’s dialects trick was clever, but many app developers didn’t have budget to localize their GUIs, never mind their scripting interfaces as well. Nowadays, with automated translation tools fast improving, localizable scripting languages should be, if not the norm, then at least the next-generation ground breakers.

Anyway, once OS X came along, a programmer dialect for AS would’ve been unnecessary as Mac OS X included the massively popular Perl, Python, Ruby languages as standard. Apple’s priority then should’ve been to put AppleScript-quality app scripting support[1] into those languages too, but as I noted upthread the Mac Automation team utterly wrecked that.

…

Here’s a working, testable example of your query:

    tell application "TextEdit"
      tell document 1
        get first character of every word whose font is "Helvetica-Bold"  
      end tell
    end tell
And here’s your filtering example, done right, in Node.js[2]:

    #!/usr/bin/env node

    const {app, its} = require('nodeautomation');

    const textedit = app('TextEdit');

    let doc = textedit.documents[0];

    let ref = doc.words.where(its.font.eq('Helvetica-Bold')).characters.first;

    console.log(ref.get());

    // => [ 'b', 'b', 'k' ]
…

Cook’s paper is a terrific read, btw: a true lightbulb moment. ’90s Apple management were ranking idiots for driving Cook and Harris off. Here a video of them discussing their work and its goals back in happier days:

https://www.youtube.com/watch?v=1MaHJ_mzrTU

Both authors tragically passed in recent years too, still young. It is a shame that their amazing if imperfect work is probably not far behind now. They deserved far better.

--

[1] https://appscript.sourceforge.io

[2] https://www.npmjs.com/package/nodeautomation
hhas
·قبل 4 سنوات·discuss
> On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that.

This was true in classic Mac OS. ObjectSupportLib provided some building blocks but there was no OS framework for implementing a “scripting” (Apple event IPC) View layer, comparable to what the OS provided for building a GUI View.

Mac OS X 10.2 finally introduced the Cocoa Scripting framework—which wasn’t… great: Object-Relational mappers are Hard to do right when manipulating ordered Arrays (which OO-based apps love to use) instead of unordered Sets (as in traditional RDBMSes)—but was just about Good Enough.

Alas, while CS made it a lot easier for Cocoa app developers to add “AppleScript” support to their apps, the fact the whole platform was shackled to the AppleScript language by default killed its ability to grow market. 10 million geeks on Mac OS X, and maybe only 50 thousand who could stand to touch AppleScript at all.

But, as I noted up thread, when Apple tried to create geek-friendly alternatives to AppleScript, Scripting Bridge and JXA (which should have been pure catnip to y’all because Apple event IPC itself is awesome) they screwed the pooch so badly they didn’t only ruin those products but wrecked all the third-party alternatives as well.

…

> In theory, you could tell any text editor or text processor such things as > > “tell every sentence whose third word is "foo" to set last word to first character” > > and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands.

Yup, queries are awesome. And there were in fact some apps that implemented robust query support at this level very, very well—e.g. Tex-Edit Plus, Adobe Illustrator—but those tended to be apps written pre-OS X by developers who worked very hard to nail it. (Adobe Illustrator’s scripting support was written by Mark Alldritt, better known for his [Script Debugger](https://latenightsw.com/) editor.)

In fact, you can run a query much like the above (replacing `sentence` with `paragraph`) in Apple’s own TextEdit, which uses Cocoa Scripting’s Text Suite to implement its text object model. The query itself works, but the `set` command silently fails. Commands like `move` and `duplicate` are even less reliable, often disappearing text entirely!

The CocoaScripting framework needed a really good mathematician to engineer it, but got a random NeXT dev instead; and with AppleScript’s original creators long gone from Apple they just bodged it as best they could.

…

> That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write.

Nope. No harder than using third-party Python libraries in a Python script is. Each library has its own API, with commands and objects specific to its particular task. The real problem was twofold:

1. Each app’s own API documentation was almost always massively inadequate. There was no way for a human user to tell which object queries could be used in which commands, except by actually trying it and seeing if it worked. Horribly opaque and unpredictable. I doubt most app devs even realized how inadequate their docs were, because most devs didn’t use AppleScript themselves.

2. AppleScript then compounded the confusion by layering the IPC stuff in mountains of syntactic sugar, enough to rot the teeth out a sperm whale, ostensibly to make AppleScript “simpler” but instead just making it impenetrable. The road to Hell is paved with good intentions… and AppleScript’s with the arbitrary injection of keywords. Pedagogical nightmare.

…

There is a postcript to all this, which is that Apple really are fools to throw away all these decades of work despite its flaws. Because they have Siri now, which is a query builder, and that, combined with what is probably the most powerful and flexible general-purpose user-level query handling architecture ever built outside of google-dot-com, ought to be THE killer USP across all of their platforms ny now.

Alas, best tech in t’world can’t fix Stupid. PEBKAC.
hhas
·قبل 4 سنوات·discuss
> AppleScript is an amazing facility and undervalued strength of macOS.

True and false. Apple event IPC is pure awesome. The AppleScript language is a dumpster fire. AppleScript remains because Apple’s own alternatives, JavaScript for Automation (aka JXA, which you mention) and Scripting Bridge framework, are even worse.

Sadly, the whole AE/OSA/AS platform is the walking dead now. Following two decades of ignorance and mismanagement, and in the wake of JXA’s 2014 failure, Apple finally fired the PM responsible and disbanded the Mac Automation department back in 2016. Whether they actively pull its plug or just let it fade away in its own time, Mac Automation as we know it is, as far as Apple’s concerned, a failed product for a non-existent market. iOS is the only market of significance to Apple now. This sucks, but so it goes.

Apple is now moving to App Extensions and App Intents for user-level IPC, which has maybe 1% the power of AEs but is cross-platform and far easier for App developers to implement; and for front-end they have cross-platform Siri with Shortcuts providing just enough customizability to make it useful (Apple hopes) to the other 99% of users for whom Swift, AppleScript, and all those other text programming languages are “too hard” for non-programmers to use.

(They’re wrong in this: text is easy; it’s languages designed by and for programmers that are hard by design, Shortcuts—ironically—included. A modern version of Papert’s Logo would smash the problem. But Apple’s own thinking is not exactly… advanced.)

…

For those who wish to see what could have been:

https://appscript.sourceforge.io -- appscript (Python 3 works; the others are bitrotted)

https://hhas.bitbucket.io -- SwiftAutomation (probably still works)

https://www.npmjs.com/package/nodeautomation -- nodeautomation (works)

https://sourceforge.net/projects/appscript/files/ -- ASDictionary and ASTranslate tools for translating AS commands to their Python/JS/Swift equivalents

All 100% capable alternatives to AppleScript for app automation, and the programmers who used them loved them. But given how thoroughly Apple wrecked the whole platform I killed support after 2012.

Now even stalwarts like Python and Ruby are gone from macOS, and the enormous JavaScript market is 100% owned by V8’s Node.js, which says what Apple priorities are regarding scripting and scripters now. Not that I can blame Apple, but Mac Automation’s failure was always a people problem, not a tech problem, not that they know (or care) the difference.