Mountain Lion

[...] Link. Bugs, fixes, annoyances. Not bad. by jgordon on July 30, 2012  •  Permalink Posted in share Tagged s [...]

[...]  Michael Tsai’s Mountain Lion notes. Good collection of miscellaneous links and information here. I agree with Michael’s comments on the Safari address bar, but I still can’t stand how Google Search URLs aren’t copied to the clipboard (as I noted in my review, search terms are). [...]

In short, this is probably a mandatory upgrade once it hits 10.8.1 or 10.8.2, if you have a Mac that won't run Snowy.

Though the mail changes that you note seem absolutely nuts.

"The worst Lion offenses in iCal and Address Book have been fixed."

Correctly phrased.

"Oddly, calendar events can no longer include AppleScripts."

I find your preface word, "oddly", to be odd. No minor deprecation of AppleScript should be considered odd moving forward.

"...I wish i could get the old Growl notifications back ... I prefer the way Growl let different notifications have different sticky values."

Growl really rocked. The sad thing about when Apple steals good 3rd party ideas, their implementation is usually inferior, and is usually is left to die a slow death over time through actual discontinuation or mere slides into irrelevance. The template almost always seems to be: Watson rocks, so we'll grab it, it won't be as good or powerful, and then it'll go away.

"The Web Sharing checkbox is gone."

I actually use this, and not for testing purposes the way most folks seems to use it. But it seems as if a 3rd party PrefPane has already hit the street to enable Apache for those who prefer to get it done via a GUI.

(At least when Microsoft releases OS Services Packs like ML, they don't strip out features...)

@Chucky My first thought was that Calendar dropped support for attaching AppleScripts due to sandboxing, but it’s actually not sandboxed. The good news is that Mountain Lion adds NSUserAppleScriptTask, which lets certain scripts run in sandboxed apps.

"No minor deprecation of AppleScript should be considered odd moving forward."

Component Manager is deprecated, so that's the Open Scripting Architecture effectively up the spout. No indication yet if they intend to preserve the original [legacy] Carbon OSA API, presumably by hard-wiring it directly to the AppleScript interpreter. (The only other OSA language component in use today is Script Debugger's ASDebugger component, and Apple certainly aren't going to care about killing that.) Ditto for the Cocoa APIs (NSAppleScript, OSAKit). I suppose they'll make some arrangement to get everything off CM, since the alternative is to wait until CM disappears and then go "O hai! did not kno u needed that AS, kthxbai."

"The good news is that Mountain Lion adds NSUserAppleScriptTask, which lets certain scripts run in sandboxed apps."

If I understand the docs correctly, it can be used to run [untrusted] user scripts outside the app's sandbox, which should totally avoid the "this app doesn't have permission to talk to that app" problem.

However, it's badly crippled in other respects: in particular, the 'execute' method can be called only once on a script, which means no persistence. Even NSAppleScript could manage that: your script is loaded when the class is instantiated and disposed of when the instance is dealloced, and between those two points you can call 'execute' as many times as you want. Any values kept in the script's properties persisted for the duration (although I'm pretty sure there was no way to save the modified script back to disk at the end; only OSAKit or the Carbon OSA could do that).

Feel free to whang radar bugs at them (for all the good it's likely to do). At the rate they're going, their next new AppleScript API will be a no-op.

...

The docs also say "The class is not intended to execute scripts built into an application; for that, use one of the NSTask classes", which is profoundly confused and/or stupid advice.

Apps should implement any internal AppleScripts on top of AppleScriptObjC. (This includes any apps that are thinking of using Scripting Bridge, since that sucks.) It is a sin that every single Cocoa developer is not by now aware of ASOC and knows how to use it. These ASOC scripts will appear to the ObjC runtime as if they were native ObjC classes (c.f. PyObjC, RubyCocoa, etc.), making them dirt easy to work with. The only exceptions would be if the app has to support 10.5 (ASOC is 10.6+) or it doesn't know exactly which apps it will target at runtime (in which case the app can't state which sandbox exceptions are required).

...

The real problem with the above though is that it reveals Apple's ongoing abject failure to grasp what scripting in general (and doubly so for AppleScript) is all about. They have just sliced the problem in completely the wrong direction, cutting vertically (by language) instead of horizontally and then vertically (by sandbox status, then language). The policy should have been:

- Use API 1 to run [internally-supplied, trusted] scripts within the app's sandbox, with the security policy specified by the app developer; use API 2 to run [externally-supplied, untrusted] scripts outside, with the user responsible for their own security.

- Use API 1A or 2A to run Unix scripts (argv+stdin+stdout+stderr interface); use API 1B or 2B to run AppleScripts (executeHandler: interface).

But no, there's an inbuilt implication that shell scripts _must_ always run within the sandbox, and AppleScripts _must_ always run outside. I imagine this will annoy both parties, and before they even get to all the other ways they're crippled or duff.

There's always XPC Services, of course, but the point of these script execution classes is supposed to be that you don't have to roll your own custom script-runner executable from scratch every time you want to fire one off.

Feel free to radar away on that too (I'm making notes for my own purposes, but have no intention on typing up bug reports myself as I prefer to use other OSes now).

@has Yes, I agree that NSUserAppleScriptTask leaves something to be desired. I doubt it’s really suitable for implementing FastScripts, for example, and it’s not ideal for EagleFiler. But, frankly, I was surprised and pleased that we got the ability to specify the AppleScript handler to call, as well as an Objective-C completion handler, rather than just -executeAndReturnError:.

"But, frankly, I was surprised and pleased that we got the ability to specify the AppleScript handler to call, as well as an Objective-C completion handler, rather than just -executeAndReturnError:."

Apple had no choice: an AEDesc is the only way to pass parameters to an AppleScript.

It's just a shame building AppleEvents via NSAppleEventDescriptor is such a chore for developers: a couple hundred extra lines of code to pack and unpack standard Cocoa classes automatically, and an AEBuild* method to specify all params as a format string would've been trivial for Apple to provide.

This meant -executeAndReturnError: (essentially a shortcut for calling 'run' with no parameters) was, in practice, an absolute pox upon NSAppleScript. It allowed lazy devs to 'parameterise' the script by gluing its source together via string interpolation and passing it to -initWithSource:. i.e. eval() hell, with all the speed, reliability and security holes that causes.

At least now devs will be _forced_ to do parameters the right way, even if they'll get zero help with it. (I won't bother suggesting anyone do a third-party library to add the extra functionality, as it'll be doomed to anonymity just like all the 3rd-party NSAppleScript improvements in the past.)

As for the completion handler, that's no biggie. Cocoa classes have long favoured asynchronous IO, and Apple events are themselves fundamentally asynchronous (it's just that almost no-one knows this as AppleScript uses them in synchronous fashion for simplicity while non-AS users generally prefer to pull teeth than use AEs for anything).

"It allowed lazy devs to 'parameterise' the script [...]"

Correction, that should read "lazy and/or ignorant devs". I think a good proportion genuinely have no clue what they're doing as Apple have never provided adequate documentation either.

@has You say they had no choice, but they might have restricted you to passing a list of strings to the “run” handler, like with osascript. A pox is right. I’ve seen so many code samples that glued strings together, not handling quote characters or Unicode.

"You say they had no choice, but they might have restricted you to passing a list of strings to the “run” handler, like with osascript."

osascript's a CLI tool, so of course it's going to use strings for everything.

If Apple just want to say "FU,AS!" there's simpler, less Machiavellian ways to do that, e.g. legacying the entire stack.

Making NSUserAppleScriptTask take an array of NSStrings would actually be _creating_ work for themselves. The way they've done it is the simplest since the AE can be forwarded as-is directly to the script, no packing/unpacking required.

me: "But no, there's an inbuilt implication that shell scripts _must_ always run within the sandbox [...]"

Correction: there is an NSUserUnixTask provided for running shell scripts outside of the sandbox. So they have at least sliced the problem correctly where internal/external Unix shell scripts are concerned. My dumb.

It's just AppleScript and the original (language-agnostic) OSA vision that's dying the death of a thousand paper cuts, while the rest of the high-level scripting languages (Python, [Mac]Ruby, etc) seem forever relegated to second-class status somewhere in-between.

Ah, thanks for mentioning the truncation issues with Notification Center! Totally missed that. Looks like it cuts off at ~120 chars and there's no way to adjust it, bah! Will probably bring Growl back soon.

@Victoria Thanks. It’s too bad because you did the right thing in supporting Notification Center. Apple should let the user decrease the font size or something.

[...] Daniel Jalkut’s Subscribe to Feed—which adds an RSS button back to Safari 6—in my Mountain Lion notes, but I wanted to give it its own post. It’s a great piece of work and the first solid reason [...]

The psychotic Mountain Lion Data Loss via Save As bug seems worthy of note.

[...] is better in Mountain Lion. See also: Data Loss via “Save As” on [...]

[...] initially tried BusyCal due to the iCal regressions in Mac OS X Lion. With Mountain Lion, I am back to using Calendar, chiefly because I find its month [...]

[...] like Mountain Lion, seems to ignore the Use LCD font smoothing when available system preference and always display [...]