Our second TidBITS Presents event on 1 August 2012 was once again a success, with over 200 TidBITS members and owners of “Take Control of Upgrading to Mountain Lion” and “Take Control of Using Mountain Lion” joining us live via Google Hangouts On Air. Joe and Matt shared key details from their books and answered numerous questions from the audience for over 2 hours.
Although we limited participation in the live event to TidBITS members and people who had purchased Joe’s and Matt’s ebooks as a way of thanking them for their support, the recorded version is available to everyone via the TidBITS Presents page or YouTube, where over 1300 more people have watched already.
We were doubly disappointed on the iOS front this time, since an update to the Google+ iOS app promised Hangout compatibility, but it turned out that said compatibility didn’t extend to the public Hangouts On Air. And then the trick we figured out for watching the live YouTube stream in Safari on iOS worked during our dry run but simply wasn’t available during the actual presentation. We’ll keep investigating what’s involved with iOS. Nevertheless, you can watch the YouTube version via iOS now, or stream it to your big screen connected to an Apple TV.
Please do leave us comments (at the bottom of this article, in the Google+ post, or on YouTube) about the presentation, in terms of content, presentation style, length, technical experience, and so on. We’re talking about doing more live online events, and we’re curious about what you might like to see from us.
Thanks for watching, and we hope you find the content useful!
Read and post comments about this article | Tweet this article
Apple does an excellent job of trumpeting new features in each release of Mac OS X, and OS X 10.8 Mountain Lion was no exception. But it’s important to distinguish the marketing discussion of new features from release notes about precisely what has changed, and one change might have escaped your notice: the elimination of the Web Sharing options in the Sharing pane of System Preferences. The open-source Apache Web server software is still present, but there’s no built-in way to turn it on and off without resorting to the command line.
Apple does acknowledge this move in a support article, essentially suggesting that if you want to run a Web site, you should get OS X Server, which costs an extra $19.99 in the Mac App Store. From a financial standpoint, OS X Server certainly isn’t a hardship, but that doesn’t mean that we should be happy about the removal of Web Sharing.
I won’t comment on whether OS X Server is appropriate for your Web serving needs at the high end, other than to note that we gave up on it several years ago for the TidBITS and Take Control Web sites. We needed more control over the configuration of Apache and other Web components than Apple provided, and flipping back and forth between Apple’s interface and the standard command line and configuration file methods of controlling things was troublesome.
Even for a small site, OS X Server isn’t necessarily appropriate, since it comes with a lot of baggage that’s overkill if all you want to do is start Web server software to test code that can’t be loaded from a static page (PHP, AJAX, Perl, etc.), to develop Web-based software for mobile devices, or even to use utilities that rely on Mac OS X’s built-in Web serving capabilities.
More bothersome is that by removing the Web Sharing options, Apple created an awkward situation for people who were running Web Sharing under 10.7 Lion. According to Chuck Shotton, who wrote the first Web server for the Mac — MacHTTP, which later became WebSTAR — Web Sharing settings under Lion are preserved when you upgrade to Mountain Lion, which means that you could end up with an active Web server that you cannot control in the same way you have under previous versions of Mac OS X. If you’re sufficiently technical, Brett Terpstra and Neil Gee have both posted instructions for addressing this and related Apache issues at the command line.
A simpler solution for anyone who wants to maintain access to the Apache Web server in Mountain Lion is Tyler Hall’s Web Sharing preference pane, which you double-click to install in System Preferences and then use to enable and disable Apache, just as you were accustomed to in pre-Mountain Lion versions of Mac OS X. Hall was able to create the simple Web Sharing preference pane due to his work on the $39.95 VirtualHostX, a utility that takes much of the complexity out of running multiple Web sites on a Mac; kudos to him for making it available for free.
It’s distressing to see Apple simplifying Mac OS X in ways like this, not so much because it’s difficult to bring the functionality back, but because features like Web Sharing have been a mainstay of Mac OS X for so long. Having them deprecated in this fashion is more evidence of how Apple’s vision for the future of the platform is evolving away from where it has been for so long. We can only hope that — if we are indeed slowly being reverted back to the days before so many capabilities were built into the operating system — Apple won’t prevent independent developers from stepping into the breach to maintain and extend such functionality.
Read and post comments about this article | Tweet this article
Almost exactly a year ago, I pointed out that Mac OS X 10.7 Lion had the habit of causing some applications to quit while you were using them (“Lion Is a Quitter,” 5 August 2011) — a habit which, as I explained at the time, goes by the name of Automatic Termination. It was with bated breath that I waited to learn whether Lion’s recently released successor, 10.8 Mountain Lion, would prove to have kicked this vile habit. It hasn’t.
I’ve posted a screencast that demonstrates the persistence in Mountain Lion of Lion’s quit-prone behavior. It’s a simple-minded screencast, but it shows plainly that Mountain Lion is still a quitter. You’ll see me first flip through the Command-Tab switcher to reveal what applications are running — just LaunchBar, ScreenFlow, and the Finder. Then, using LaunchBar, I launch TextEdit; and I open a new document. I then close TextEdit’s document, and switch to the Finder by clicking on the desktop. Note that I have not told TextEdit to quit! All I’ve done is to bring the Finder to the front. Instantly, however, TextEdit quits. If you look sharp, you can see it vanish from the right end of the Dock; a subsequent search for it in the Command-Tab switcher also proves fruitless. (Actually, if you look really sharp, you’ll see that ScreenFlow has also vanished much earlier from the Dock, and is later missing from the Command-Tab switcher as well. Fortunately, the ScreenFlow subprocess that records the screen does not quit!)
Optimistic attempts by various Apple apologists to justify this astonishing behavior have not, in my view, met with any success. The best that can be said for it is that, given the existence of additional Lion and Mountain Lion features such as Auto Save and Resume (which, together, allow an application’s state to be restored the next time it is launched), the distinction between whether an application is running or not is of diminished importance. That might be the case, if an automatically terminated application’s icon remained in the Dock and the Command-Tab switcher, so that you could conveniently relaunch it; and some have suggested that the icon’s failure in this regard was just a minor bug which Apple would fix in due course. But the fact is that throughout all versions of Lion, and now in Mountain Lion, Apple has not altered this aspect of Automatic Termination’s behavior; an automatically terminated application’s icon is still removed from the Dock and the Command-Tab switcher, just as it would be if the user had quit the application deliberately or the application had crashed. And so the user, who did not quit the application deliberately, is puzzled and annoyed, and in order to continue using this application must now search for it and relaunch it all over again.
(The behavior of Automatic Termination can actually be even worse than I describe here. In Lion, I have seen Xcode terminate itself automatically immediately after being launched — between the time when you double-click its icon in the Finder and the time when you have a chance to tell it what project to open. This can happen even though Xcode, during the brief time it was running, was always frontmost. Unfortunately, I haven’t been able to capture a screencast of that phenomenon; but I assure you that it can happen.)
Fortunately, the intrepid discoverers of command-line incantations have not been idle. It turns out that there’s a way to turn off automatic termination! I don’t know what wizard first unearthed it or when, though I have not found many Internet references to it older than April 2012. It goes like this:
defaults write -g NSDisableAutomaticTermination -bool yes
(You’ll probably have to restart the computer to make the incantation take effect.) For those who tremble to approach a Terminal window, there’s even more good news. You’ll remember that I discussed TinkerTool a while back as one of many ways of throwing hidden system switches through a user interface (“Lion Frustrations? Don’t Forget TinkerTool,” 29 October 2011). Well, the recently released TinkerTool 4.9 incorporates a checkbox that accesses this same setting. It’s on the Applications pane, near the bottom, and reads: “Application control: Don’t allow OS X to automatically quit inactive applications.”
While you’re enjoying TinkerTool (or whatever utility you like to use for getting at these hidden settings), be sure to check out other options that may make Mountain Lion more pleasant. Another new TinkerTool checkbox that I’m particularly fond of is in the General pane: “Disable rubber band effect.” The rubber band effect is the way a scrollable interface in Lion or Mountain Lion will “bounce” rather than just stopping when you reach the limit of its scrollability. Also in the General pane, I like to uncheck “Animate opening windows”; in general, Mountain Lion’s many built-in animations distract me and force me to wait for their completion, so whatever speeds them up or removes them altogether is a good thing. I’m not saying everyone needs to feel the same way I do about these matters; I’m just pointing out that you have such options if you want to try them out.
Read and post comments about this article | Tweet this article
Perfect speech recognition is one of the Holy Grails of computing — shouldn’t our computers be able to transcribe exactly what we say, complete with proper spelling and punctuation, as has been the case in science fiction for many years? In fact, speech recognition software is nothing new in computing. Windows users have long taken advantage of the excellent Dragon Naturally Speaking from Nuance. On the Mac, this software has gotten good enough only in the past couple of years, since MacSpeech licensed the Naturally Speaking engine and was subsequently acquired by Nuance, after which the MacSpeech app was renamed to Dragon Dictate.
But it’s important to understand what speech recognition software can and can’t do — we aren’t yet at the point where you can speak normally and have your words magically converted into text. I’ve been dictating into dictaphones and using speech recognition software for more than 15 years, and while dictating isn’t any faster than typing for me, I often find it more relaxing. For those who can’t type quickly, dictation might be faster, and it’s an essential technology for those with certain physical impairments or injuries.
With the release of the iPhone 4S and the third-generation iPad, Apple brought simple voice dictation to millions of iOS users, and with the launch of OS X 10.8 Mountain Lion, Mac users can now join the voice dictation party without buying Dragon Dictate. Whether you can be satisfied with Apple’s built-in voice dictation or whether you need the full capabilities of Dragon Dictate depends on how you plan to use the software.
(It’s worth noting that there’s a difference between voice dictation, where what you say is converted into text, just as though you’d typed it, and voice control, where you speak commands and the computer or iOS device reacts to them. On the iPhone 4S, that’s the difference between voice dictation and talking to Siri, and on the Mac under Mountain Lion, it’s the difference between the new voice dictation feature in the Dictation & Speech pane of System Preferences and the long-standing Speakable Items feature, which is now located in the Accessibility preference pane.)
The main thing to realize about speech recognition is that computers don’t understand what we say. They may be able to figure out what words leave our mouths, but they don’t understand any of the meaning or context. For this reason, dictation requires that you employ special techniques to convey what you mean.
Plus, speech recognition software works best in a quiet environment, since extraneous noise can render transcriptions that read like the work of Surrealistic poets. Luckily, technology, in the form of a noise-canceling microphone, can filter out background noise and provide a purer stream of audio to your Mac. This can enable you to dictate even in a lively office.
Starting to Speak -- If you’ve never used dictation software before, you’ll find that the basics of how Apple has implemented it in iOS and Mountain Lion are extremely easy.
In iOS, to dictate text, bring up the onscreen keyboard by tapping anywhere you can type. Tap the microphone button to the left of the Space bar and speak, tapping it again when you’re done. You can also tap and hold on the microphone button, then lift your finger when you’re done speaking. The transcribed text appears at the insertion point.
In Mountain Lion, position the insertion point where you want your transcribed text to appear, press the Fn (Function) key twice to start dictation, and then start speaking. (If you don’t have an insertion point, Mountain Lion just beeps at you when you press Fn twice.) As with iOS, press the Fn key again to alert Mountain Lion that you’re done speaking, or, if you keep the Fn key down on the second invocation press, you can just let up on it when you’re done. Or, you can click the Done button in the dictation balloon that appears, but that seems like an awkward action if your hand was on the keyboard. Finally, you can just press Return to tell your Mac to process what you said. (You can change the key you press twice in the Dictation & Speech pane of System Preferences.)
Top Ten Techniques -- A number of techniques can help you dictate more efficiently and more successfully. These are especially important with Apple’s dictation features in iOS and Mountain Lion, which don’t learn from what you dictate, unlike software like Dragon Dictate. For the best results, follow these rules:
Speak slowly, evenly, and clearly. Pretend you’re a newscaster reading the news.
Think about what you are going to say before you say it. The more you hesitate while speaking, the harder it is for the software to figure out what you mean.
Dictate in short sentences or phrases, but try and dictate complete sentences and clauses. This is particularly necessary with Apple’s dictation features, which aren’t designed to process long sentences and can listen for only 30 to 40 seconds. That’s because, after you tap or click the Done button or run out of time, the audio you dictate is sent to a remote server, processed, and then returned to you as text. In contrast, Dragon Dictate does all its processing on your Mac, so if you pause briefly, it can process your text, type it, and wait for you to continue.
If you plan to dictate a lot, or if you’re in a noisy environment, use a standalone microphone. Built-in microphones are sufficient for basic use on both iOS devices and the Mac, but since they lack noise cancellation, they may not work well if there’s background noise. With the iPhone 4S and third-generation iPad, though, you can significantly improve recognition by holding the device so its internal mic is close to your mouth.
Speak all punctuation: say the words “comma,” “period,” “dollar sign,” “percent sign,” “degree sign,” and so on. Say “new line” to simulate pressing Return once and “new paragraph” to simulate pressing it twice, inserting a blank line.
Say the word “apostrophe” for a possessive. For example, “I am going to Ahab apostrophe s cabin period” transcribes as “I am going to Ahab’s cabin.”
To spell words or abbreviations, say the letters slowly and individually. Apple’s dictation features tend to assume you want all capitals, and it can be helpful to speak all the letters at the same cadence to avoid spurious spaces. If you’re using Dragon Dictate, the program has a spelling mode you can activate to tell the program to listen specifically for letters.
In iOS, you can capitalize words by saying “cap” before the words you want capitalized. For example, you would say “I’m going to buy some clothes at cap the cap gap” to get “The Gap” at the end of that sentence. Oddly, since it would seem likely that the remote servers are running similar, if not identical recognition code, this technique does not work in Mountain Lion. We hope Apple will tweak the back end to enable arbitrary capitalization in this fashion.
Unlike in Dragon Dictate, the iOS and Mountain Lion dictation features do not allow you to correct any mistakes via voice. Therefore, if a sentence is wrong, you must edit it from the keyboard, or just delete it and start over.
Drink regularly. A dry mouth and throat will make your voice sound different, and will make it harder for the software to transcribe what you say correctly.
As a bonus tip, if you’re dictating email and feel the need to convey some emotion, you can say “smiley” to get
:-), “winky” to get
;-), and “frowny” to get
:-(. You can also add “face” to any of them to get the same results. Interestingly, if you’re in, say, the address field in Safari 6 or the search field in a Finder window, these shortcuts don’t translate, and you’ll just get the words you say.
Is Dictation for You? -- Don’t expect miracles from Apple’s dictation features in iOS and Mountain Lion. With practice, you will find that they can be useful for short texts, such as instant messages, short email messages, tweets, and so on. But if you want to dictate longer texts, you need to use dedicated speech recognition software such as Dragon Dictate, which learns from your speech patterns and enables you to edit the mistakes it makes. Nuance also offers software with specialized vocabularies built in — MacSpeech Dictate Legal and MacSpeech Dictate Medical — that makes it much easier for lawyers and doctors to dictate.
Speech recognition can seem miraculous. When it works well, you can go from typing 40 or 50 words a minute to dictating twice that or more in the same time. This takes a fair amount of effort, both for you to learn optimal dictation techniques and — if you’re using Dragon Dictate — for you to train the software to recognize your unique way of speaking. But if you’re interested in making the leap to a world where you dictate most of your text, give Apple’s dictation features in iOS and Mountain Lion a try, and if you find them saving you time, check out Dragon Dictate.
Read and post comments about this article | Tweet this article
AppleScript has been around for nearly 20 years, and although in that time it has doubtless succeeded in inviting many non-programmers to try their hands at writing scripts to automate applications, it has its oddities. One of its notable peculiarities is that, unlike most scripting languages, an AppleScript script file isn’t just text. In order to be saved, either as a script file or as a standalone application, an AppleScript script must be compiled first. (An AppleScript script that can’t be compiled — because of a syntax error, for example — can be exported as text, but it can’t be saved as a script file.) OS X 10.8 Mountain Lion keeps the same script file format as its predecessors, and yet at the same time changes the rules completely: scripts and applications can be saved in an uncompiled state. It is a small change, and simultaneously a huge one.
Before looking at the details, it is worth asking why Mountain Lion makes this change. Or — perhaps more pertinently — why does it make this change now? The answer lies within Mac OS X, with a feature actually introduced in 10.7 Lion: Auto Save. Although this wasn’t true in Lion, the Mountain Lion version of AppleScript Editor now supports Auto Save and Versions.
When you think about autosaving, and the idea of saves being triggered by anything other than the user, it is clear that the old model, where you cannot save a script as a script file without first compiling it, simply won’t work. Apple had a few options in dealing with this conundrum: proceed with an autosave only when the document is compiled, come up with a new script storage format, or try to come up with a method that’s backwards-compatible with existing files. Apple’s engineers chose the third option.
AppleScript Editor can save scripts in four formats:
Let’s look at the .app format first. It is a standard Cocoa application: a folder that looks like a file and contains a series of subfolders and files in a particular arrangement. AppleScript applications save the compiled script in a file called main.scpt, inside
Contents/Resources/Scripts/. When the user launches the application, this file is loaded, its handlers are called, and its contents are saved back to the same file when finished.
Clearly, if the main.scpt file is not compiled code, the application cannot run. To work around this problem, Apple has resorted to a bit of digital sleight of hand: when it is time to save changes while working in AppleScript Editor, if the script can be compiled, it is saved in the main.scpt file as it always has been. If a syntax error or other problem prevents compilation, a single compiled statement is saved in main.scpt instead. This statement is:
error "This script contains uncompiled changes and cannot be run."
If you try to run such a .app-based script, the compiled script containing that error will execute, the error will be generated, and the message will appear in a dialog. So at least the application runs and provides appropriate feedback to the developer.
But what happened to the script’s real code? Because it cannot be compiled, AppleScript Editor instead saves it in another file, in .rtf format. This file is called main.rtf, and it lives in the same folder as main.scpt. It is saved only when the document cannot be compiled. So when AppleScript Editor in Mountain Lion opens a .app file for editing, it first looks to see if there is a main.rtf file. If that file exists, AppleScript Editor loads main.rtf’s contents as the source code, and if not, it decompiles main.scpt as usual.
This all just works — as long as people running scripts understand the meaning of the error message when they see it, and as long as anyone who wants to edit an uncompiled script is also running AppleScript Editor under Mountain Lion, or another script editor that knows about the change. But if you are running any version of Mac OS X before Mountain Lion, or using
osadecompile at the command line, things become a bit more complicated. You might be quite surprised to see a single error statement where you expect to see swathes of code. And if you were to copy a previous version of the source into AppleScript Editor, you might even end up with a .app script file containing what looks like two
versions of code, depending on which script editor and version of Mac OS X it was later opened in.
Fortunately, as long as you know about the problem, you can work around it. For example, you can open a .app package in the Finder by Control-clicking it and choosing Show Package Contents, drilling down to find main.rtf, opening it in a text editor, and copying and pasting the code into AppleScript Editor.
Script packages — .scptd files — use the same process, and the solution is the same: if there’s a problem, look for the main.rtf file to find the real code.
Importantly, if you do open the main.rtf file in a script package directly and copy the source back into a pre-Mountain Lion version of AppleScript Editor, it’s key that you also remove the main.rtf file. Otherwise, you will end up with a file that shows different code when opened in AppleScript Editor in Mountain Lion, which could be catastrophic down the track.
Ordinary script files, with the extension .scpt, are not packages; they are single files, so Apple had to work around the problem a bit differently. In this case, the .scpt file will end up with the same compiled error statement if the script cannot be compiled, and the actual source will be saved in its resource fork, as an RTF resource. (Veteran scripters will remember how AppleScript’s original script file format relied on a resource fork. It was phased out in favor of what was called the data-fork-only format, which to this day is still described in the Finder as “Compiled OSA Script (data-fork),” even though such files can include a resource fork.)
Again, this RTF resource is created only if the script could not be compiled at save time, and AppleScript Editor in Mountain Lion looks for it first when opening .scpt files. Similarly, older versions of AppleScript Editor and other editors will not know to look for this resource, and so will show the single error statement. This time, however, the solution is not as simple as looking for a file in a package — reading resources from resource forks (which are actually separate invisible files in Mac OS X) is more complex. Fortunately, we will come to a simple solution shortly.
Along with older versions of script editors, the other thing to beware of are utilities that strip off resource forks, or foreign-format file servers that do not handle resource forks correctly. For an uncompiled script file, removing the resource fork is as good as throwing the file in the Trash and emptying it.
So what should a scripter do to minimize problems in light of this change? If you are using AppleScript Editor in Mountain Lion, you first need to keep the problem in mind. If you just want to experiment with existing scripts that you worry about modifying, consider working on a copy of the code, saving back to the original only when you’re certain it’s working.
You could also consider splitting storage and deployment completely by saving your source in .applescript files, which can be executed in AppleScript Editor but nowhere else. This approach has long been discouraged, if not heavily, but the objections are largely theoretical. It’s also common practice if you use AppleScriptObjC in Xcode. And it has another advantage: it works well with source-control systems.
The other step is probably to make sure you deploy execute-only versions of your scripts. In Mountain Lion, AppleScript Editor now has an Export command, which is the only way to save a file as execute-only. It also attempts to compile the script first.
Of course if you are doing much scripting, you are better off abandoning AppleScript Editor for a serious tool like Late Night Software’s $199 Script Debugger. Script Debugger 5.0 doesn’t currently support autosaving — and some would argue this is no great loss — but a version that will recognize and open uncompiled files correctly should appear shortly.
Users of my AppleScriptObjC Explorer should also make sure they are running the latest version, which also handles the hidden source correctly.
For those running earlier versions of Mac OS X or using other script editors, and who might receive files from Mountain Lion users, I’ve written a free utility, Read My Scripts, for extracting the code from uncompiled script files. It’s a simple drag-and-drop application that saves a new version of the script with the correct source, commented out, and removes the main.rtf file or RTF resource. It should work on systems going back to 10.5 Leopard.
[Shane Stanley is a long-time AppleScript user, consultant, and trainer. He is also the author of “AppleScriptObjC Explored” and the developer of the AppleScript-related utilities AppleScriptObjC Explorer, ASObjC Runner, and Read My Scripts.]
Read and post comments about this article | Tweet this article
MacBook Pro Retina SMC Update 1.0 -- Apple has issued a System Management Controller (SMC) update for the MacBook Pro with Retina Display, which fixes several sleep and wake issues for users running Mac OS X 10.7.4 Lion. Additionally, like the SMC updates recently issued for MacBook Air models (see “MacBook Air SMC Updates 1.5 and 1.6,” 27 July 2012), this one enables Power Nap support when running 10.8 Mountain Lion. (Free, 530 KB)
Read/post comments about MacBook Pro Retina SMC Update 1.0.
Coda 2.0.2 -- Panic has released version 2.0.2 of its Coda Web site development tool with a list of fixes and improvements that’s Dostoyevskian in its length. Among the highlights, the update “significantly” improves the speed and behavior of its syntax highlighter, adds a Jump to Style contextual menu item in Preview, makes it easier to search open folders using Find in File, and ensures that Coda’s spell checker works more reliably. Additionally, the version available from the Mac App Store can now unlock the Direct version via a new Unlock Coda menu item (though the Mac App Store hasn’t yet caught up to version 2.0.2 as of this writing). For a complete rundown of the over 100 changes in Coda 2.0.2, be sure to peruse the release notes. ($99 new, $75 upgrade from 1.0, free update, 48.8 MB)
Read/post comments about Coda 2.0.2.
Audio Hijack Pro 2.10.5 -- Rogue Amoeba has released Audio Hijack Pro 2.10.5, which can now capture audio from Safari, QuickTime Player, FaceTime, and Messages on OS X 10.8 Mountain Lion without requiring the Instant On component (which itself was updated to version 6.0.1). Additionally, the update fixes a crash related to a custom install of the libFLAC library, ensures the Factory Reset functionality works properly under Mountain Lion, and adds compatibility with Gatekeeper. ($32 new with a 15-percent discount for TidBITS members, free update, 5.5 MB, release notes)
Read/post comments about Audio Hijack Pro 2.10.5.
Airfoil 4.7.2 -- Like the recently released Audio Hijack Pro 2.10.5, Rogue Amoeba’s Airfoil 4.7.2 has been updated to capture audio from Safari, QuickTime Player, FaceTime, and Messages on OS X 10.8 Mountain Lion without use of the Instant On component. The update also fixes an issue where volume control wasn’t working for some third-party AirPlay hardware, corrects the Enter Full Screen menu item in the Airfoil Video Player to work properly on 10.7 Lion, and provides several fixes for the MacBook Pro with Retina Display (such as ensuring Netflix’s full-screen mode works and correcting the Welcome window size). Additionally, the release prevents applications from appearing twice in the Source list, and it is now compatible with Gatekeeper. ($25 new with a 15-percent discount for TidBITS members, free update, 9.6 MB, release notes)
Read/post comments about Airfoil 4.7.2.
TinkerTool 4.9 -- Marcel Bresink has released TinkerTool 4.9, updating his under-the-hood customization system utility to support OS X 10.8 Mountain Lion. The new release also adds a setting to disable the rubber band effect that occurs when scrolling beyond the end of a view in both Mountain Lion and 10.7 Lion, adds a setting to prevent unused applications from quitting automatically under Mountain Lion and Lion (covered more in depth by Matt Neuburg’s “Mountain Lion is (Still) a Quitter,” 2 August 2012), and enables TinkerTool’s icon to be replaced using the Finder. (Free, 1.8 MB, release notes)
Read/post comments about TinkerTool 4.9.
PDFpen and PDFpenPro 5.8.5 -- Smile has updated both PDFpen and PDFpenPro to version 5.8.5 to add compatibility with OS X 10.8 Mountain Lion. Additionally, both releases fix an issue with scanning when running 10.7 Lion, as well as an issue where resampling at a lower resolution produced a larger saved file. Both updates are rounded out by other unnamed minor fixes and improvements. ($59.95/$99.95 new with a 20-percent discount for TidBITS members, free update, 40.7/41 MB)
Read/post comments about PDFpen and PDFpenPro 5.8.5.
Voila 3.2 and Boom 1.5 -- Global Delight has released minor updates to its Voila screen capture app and Boom volume booster app to add compatibility with OS X 10.8 Mountain Lion. Voila 3.2 adds an option to launch at login under Mountain Lion and includes several bug fixes related to various screen capture types and file sharing. Similarly, Boom 1.5 adds the launch at login option, and it also offers support for Notification Center to display file-boosting notifications. According to a Global Delight blog post, both apps have yet to be “retina-fied,” but that task is on the company’s to-do list. Also, while both Voila and Boom are available from the Mac App Store, neither have been updated to these current versions as of this writing, but should be available soon. ($24.99 for Voila and $5.99 and Boom, free updates, 5.1/8.3 MB)
Read/post comments about Voila 3.2 and Boom 1.5.
Thievery figures strongly in our ExtraBITS this week, as David Pogue’s iPhone was stolen and then recovered, and as someone convinced Apple customer service to reveal Gizmodo writer Mat Honan’s iCloud account credentials. Also this week, we share articles about the likely revenues surrounding the popular Sparrow email client, a TUAW interview about ebooks with Michael Cohen, and the appearance of Hulu Plus on the Apple TV.
David Pogue’s iPhone Stolen and Recovered -- New York Times columnist David Pogue’s iPhone went missing while he was taking the Amtrak train home from a television shoot in Philadelphia. After it started reporting its location via Find My iPhone and he tweeted about its loss, the story went viral, with Gizmodo posting frequent updates and street photos of the house where the iPhone was located. By the end of the day, local police had recovered the phone, but anyone hoping for a tense hostage situation or shootout with the thieves was disappointed — the iPhone was found lying in the grass in the back yard. It’s worth assuming this approach is unlikely to work for those who don’t write for a major metropolitan newspaper or have 1.4 million Twitter followers.
Gizmodo Writer’s iCloud Account Hacked -- Mat Honan of Gizmodo admits he had a seven-character password he had used for years, but that weakness isn’t what led to a villain gaining access to his iCloud account, remote wiping his iOS devices and MacBook, and hijacking his Twitter account. Rather, Honan says the hacker used social engineering to talk Apple customer service into giving up information. That’s a disturbing report, and we will update you as more information becomes available.
The Sparrow in the Coal Mine -- iOS app developer David Barnard of App Cubby has an interesting look at the likely sales numbers behind the Sparrow email client that suggest that too-low prices in the App Store mean that it’s now extremely difficult to earn the necessary amounts of money to fund ongoing development. The better approach? Sell your company (see “Sparrow Bought by Google,” 21 July 2012).
TUAW Interviews Michael Cohen about iBooks Author -- Erica Sadun of TUAW interviews our own Michael E. Cohen about his lengthy history in the world of ebooks and his opinions about iBooks Author, based on his recently released title about the program, “Take Control of iBooks Author.” Michael has fabulous stories, and several make it into this interview.
Hulu Plus Comes to Apple TV -- The Apple TV’s selection of video content just improved, thanks to the addition of the Hulu Plus subscription service. For $7.99 per month, you can now stream “current and classic TV programming on demand from hundreds of content partners.” Apple TV competitors like Roku and smart TVs have supported Hulu for some time, so Apple TV is late to the game, perhaps due to Apple not wanting competition for iTunes Store sales, or because of Hulu not wanting to give Apple a cut of its subscription fees. Apparently, Apple and Hulu have now come to some mutually beneficial understanding.