FastScripts 2.6.1

July 29th, 2011

I released FastScripts 2.6.1 today, which restores support for Mac OS X 10.4 and 10.5, and also includes a few bug fixes and enhancements.

One cool trick in 2.6.1 is the way FastScripts behaves when your scripts include “keystroke” commands to synthesize keyboard presses. In the past, these scripts were tricky to get right in FastScripts, because the synthesized keystroke would be mixed up with the very keys you had used to invoke the script. Now, FastScripts will suspend execution of any such script until you release the keys that were pressed to invoke the script.

FastScripts 2.6.1 Changes

  • Prevent conflicts with synthesized keystroke commands and keyboard shortcuts
  • Fix for situations where FastScripts became the front app after running a script
  • Fix the built in on-screen display windows to grow in height to fit displayed message
  • Restore support for Mac OS X 10.4 and 10.5

Unfortunately, this update is not available on the Mac App Store. Apple has now rejected it twice, citing the behavior of the app when it is used to run one of Apple’s own bundled scripts:

/Library/Scripts/Mail Scripts/Create New Message.scpt

This script is terrible to start with, but starting in OS X Lion, it simply doesn’t work. It fails with cryptic errors, and FastScripts faithfully reports them. Apple is rejecting FastScripts for the behavior of a faulty script that is bundled with OS X Lion.

The review process for App Store submissions is frustrating to start with: every release takes extra time and there is a great deal of uncertainty as to when an update will finally be made available to customers. I have to admit that sometimes the review team identifies serious bugs that I am glad to have fixed before releasing an app. But the benefit of that kind of review seems to be balanced by reviews like this one, where Apple’s own bugs are being cited as the cause for rejection my app.

I am confident that FastScripts 2.6.1 will eventually be approved for the App Store. In the mean time, any customer who owns the App Store edition can download and run the direct-sale version from my site.

 

10 Responses to “FastScripts 2.6.1”

  1. Clark Says:

    Out of curiosity what do you make out of the issues in sandboxing that appear to be incompatible with Apple Events? I know Apple has temporary exceptions but it does seem that Apple’s views on security are conflicting with their past support (and encouragement) of Apple Events. Have you heard anything in this regards to give one confidence Apple still has Apple Events in mind as a real strategy?

  2. Daniel Jalkut Says:

    @Clark: I haven’t heard anything on this front. I hope that Apple will not decide that whole classes of applications are now verboten just because they use techniques such as scripting or AppleEvents.

  3. Matt Davis Says:

    Is there any way to hide the normal Scripts menu, and just use the FastScripts menu as my interface with my various scripts? It seems like such a waste to have two script menus up there, one good and one not so good.

  4. Daniel Jalkut Says:

    @Matt – yeah, you can just hold down cmd-key while clicking and dragging Apple’s script menu icon, and pull it off the menu bar.

  5. Matt Davis Says:

    Sweeet.

  6. Jason Says:

    I don’t understand what has happened with this update. Previously, I could hit a key and the associated app would come to the front. That doesn’t work now and renders the application useless for me.

  7. Daniel Jalkut Says:

    @Jason – I don’t know what’s going on, but can you drop me an email to support@red-sweater.com? It will be easier to track down what happened over email.

  8. Daniel Jalkut Says:

    Update: for any other folks who run into the same issue Jason did, I am working on a fix. Here’s an early beta release if you want to try it out now:

    http://www.red-sweater.com/fastscripts/FastScripts2.6.2b1.zip

  9. Ammon Skidmore Says:

    I’m curious what the new “cryptic errors” are that you are seeing with Create New Message.scpt. That script has always been pretty bad — since at least 10.5 it always fails if the user has no signatures (5633026). Running it in the Script Editor in Lion at least gets to that point for me before failing. Using osascript on it in the Terminal fails because “No user interaction allowed” — not sure if that’s a bug or not given security changes.

    Regarding Clark’s comment, there is currently a bug in Lion where you can’t ask an app to write outside of its sandbox:

    set user_documents to path to documents folder
    tell application “TextEdit”
    make new document
    save document 1 in file (user_documents & “test doc” as text)
    end tell

  10. Daniel Jalkut Says:

    @Ammon – hmm, I have to refresh my memory, but I may have jumped to the conclusion that it got worse in Lion. You might be right it’s always sucked this bad :)

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.