BBEdit 8.7.1 is a maintenance update, but it also includes some nice enhancements that I’ve been enjoying, such as being able to drop files from Disk Browsers into other applications and being able to check spelling when using a codeless language module.
Another great Mac OS X review from John Siracusa, though it’s not as long as the Tiger one. Here are some highlights:
In action, it’s indistinguishable from magic. You write these little text files with script-like bang-pound lines using this weird C-like language and you have essentially free reign to grope all over the kernel.
In the end, Apple made the hard choice instead of the easy one. I think it will pay off, though the short-term consequences could be pretty grim. After all, just look at how long it’s taking to get an Intel-native version of Microsoft Office for the Mac. Should we expect a 64-bit Cocoa version in, say, 2012? And I have no idea what Adobe’s going to do about 64-bit versions of its products. That’s many millions of lines of Carbon code between those two companies alone. We may be in for a rough patch, so buckle up.
Drawing the user interface at different scale factors:
Hey, what do we have here lurking under
/System/Library/PrivateFrameworksin Leopard? Why, it appears to be a new framework:CoreUI.framework. Whatever could that be for? Surprise! Every piece of the user interface in Leopard is being drawn in an entirely new way that incorporates the best of the bitmapped and vector styles.
The new “Show warning before changing an extension” and “Grid spacing” options in the Finder:
It’s hard for me not to use profanity at this point, so thoroughly do these two additions infuriate me. On the one hand, I’ve been wishing, hoping, and sometimes begging for these features for years, and I’m glad to finally see them in Leopard. But on the other hand, actually using these features and experiencing how much more pleasant they make my daily life on the Mac—as I knew they would—only reminds me of how stubbornly Apple refused to add them for the past six years!
Oh, the agony inflicted for want of such simple features! In the case of the icon grid spacing adjustment, this is something that existed in a lesser form (only two settings: tight and wide) in classic Mac OS and was dropped during the transition to Mac OS X, like so many other features, without explanation or justification. Worse, the spacing between icons was expanded to a comical size in Mac OS X 10.0 and never recovered. It always seemed to me to be some sort of punishment for daring to use icon view. Just look at this screenshot from Tiger showing the Applications folder with 48x48 pixel icons, scaled to 50 percent of its original size.
The new “Always open in” checkbox:
This avalanche of mandatory explicit action effectively represents a denial of service attack on the spatial style of file management. It overloads the user with a never-ending stream of mundane tasks, making the formerly transparent process of view style retention so inefficient that it will likely be abandoned entirely.
The Dock:
In the Leopard Dock, my home folder appears as a bunch of stacked folder icons because that’s mostly what it contains: other folders. There’s actually one document peeking out in the middle of the stack as a sliver of white. The icon on the top is the Desktop folder icon. So, out of the box, your home folder, when docked, appears to be the Desktop folder.
Though Apple was kind enough to make it a public framework, Time Machine is arguably the entire reason FSEvents was created. Time Machine can wake up whenever it wants—it doesn’t need to be running constantly—and efficiently find out what’s changed since it last checked (that is, since the last file system event id that it saw). Since FSEvents reports changes at a directory level, Time Machine still has to determine which files in that directory have changed. No problem! It’s got the previous backup of that directory to use as reference. FSEvents and Time Machine are a perfect match for each other.
Well, the actual GM is just as good, probably even better—though I’ve yet to produce a single crash of anything even in the September seed. Of course, I only have a limited set of hardware and software to test on, so I can’t say definitively that 10.5.0 is going to be great for everyone. And yes, the Miracle of September does give me some pause. But I’m cautiously optimistic that 10.5.0 won’t be a repeat of the 10.4.0 experience. That said, a 10.5.1 release is almost certainly not too far away. I just think you won’t be in desperate need of it when it arrives.
Apple has finally submitted to adding what must be quite a hack to get the iCal application icon to show the correct date on its Dock icon, even when the application is not running.
And hey, anyone remember that Apple Type Services bug that prevented my preferred Terminal font (Monaco 9pt forever!) from displaying correctly? You know, the one that lingered for five years after I first reported it?…Fixed.
Rory Prior has a bunch of interesting points about the new Leopard appearance. (Is it still called Aqua?) There’s certainly some weirdness, but overall I think it’s an improvement over Tiger. The Dock-on-the-side is fixed, thankfully. The menu bar is only partially fixed, but we’ve finally seen the end of Brushed Metal.
Already, the BridgeSupport API metadata is used for more than just bridging languages. For example, Xcode offers Objective-C method name completion in standalone Python and Ruby source files—no project necessary—by leveraging the BridgeSupport metadata!
Leopard is chock full of details like this—little things that won’t be promoted on the box cover or mentioned in mainstream media reviews, but which, taken cumulatively, epitomize why Mac OS X keeps getting better with each major release.
I don’t think there’s any one thing in Leopard, even Time Machine or Spaces, that’s a must-have for most users. Of the major features, Quick Look will probably have the most impact. Mostly, though, it’s the huge number of smaller improvements (for both users and developers) that make Leopard a great upgrade.
Matt Neuburg on the new Dock appearance, stacks, and the disappearance of Help Viewer and Classic:
Let’s pause to remember how a folder in the Dock used to work, as we kiss it goodbye forever. In Tiger, the story is like this. You’ve got a folder in the Dock. It looks like a folder. Click it and it opens in the Finder. Command-click it and you view it (in its containing folder) in the Finder. Control-click it and you get a hierarchical menu of its contents, the contents of its folders, and so on. Just about all of that is now gone.
We did actually have reason to believe that this would work during earlier beta stages of Mac OS X 10.5. However, the final Leopard’s menu bar is opaque, and instead of letting the background shine through, it draws a blurred copy of your wallpaper.
The documentation for Perl’s Maketext module mentions an interesting issue:
First off, your code for “I scanned %g directory.” or “I scanned %g directories.” assumes there’s only singular or plural. But, to use linguistic jargon again, Arabic has grammatical number, like English (but unlike Chinese), but it’s a three-term category: singular, dual, and plural. In other words, the way you say “directory” depends on whether there’s one directory, or two of them, or more than two of them. Your test of
($directory == 1)no longer does the job. And it means that where English’s grammatical category of number necessitates only the two permutations of the first sentence based on “directory [singular]” and “directories [plural],” Arabic has three—and, worse, in the second sentence (“Your query matched %g file in %g directory.”), where English has four, Arabic has nine. You sense an unwelcome, exponential trend taking shape.
I’ve run into simpler versions of this problem several times, in different programming languages, and never found a satisfying solution.
TaskPaper, a new GTD-type application from Hog Bay, is so gloriously simple that it seems like it couldn’t possibly do everything that you need. And yet it almost does. With hyperlinks and tabs to show different views of a lightly marked-up plain text file, it gets the main things I want in a task manager right. Unlike OmniFocus, it works well with a small/narrow window and it’s very fast (though that may change as I add more tasks). Not being able to move tasks or projects around easily is a major limitation of 1.0. But overall it looks quite promising.
[Time Machine’s] primary usage scenario—and the one that most demonstrations and documentation focuses on—to allow quick recovery of files and data that have gone missing, etc. Yes, Time Machine can restore a full system, but that’s not its strength. Doing so requires you to actually start up from the Leopard DVD (which you’ll need to have with you) and then take the time to restore the backup in full, which interrupts your workflow, requires a working, entirely separate destination device, and takes a lot of your time—at the exact moment when you can least afford it.
It’s not well documented, so Hongli Lai read the code to figure it out.
I try to encourage people to distinguish between the terms “bundle” and “package,” using “package” to refer to a directory that is intended to be presented to the user as a single object, and “bundle” to refer to a directory that is structured so as to be used with CFBundle/NSBundle APIs. The two concepts are sometimes related, but are independent in general…
It’s a bit confusing, since the “bundle bit” is used to indicate folders that are packages.
And in my mind, the decision to put physical volume buttons on the iPhone and not on the iPod touch is emblematic of the cheapskate attitude marring the device. Apple could throw in all non-phone, non-Bluetooth, non-camera, non-microphone features into the iPod touch and iPhone would still sell like hotcakes—and in fact the iPod touch would sell quite a bit better, too. You know why? The iPhone has a phone. That’s the only differentiator there needs to be.
I just got an email from Uli Kusterer asking me to expand on my comments the other day that Ben Collins-Sussman doesn’t “get” distributed version control…I’ll answer this with specific reference to Git seeing that’s the distributed version control system with which I have the most experience. Although I could rave on about how Git is the best thing since sliced bread for so many reasons, I’ll try to limit myself specifically to its distributed nature.
This isn’t a new thing. It was the same deal with Tiger, and other OS releases before it. Apple has not stated any reason why the final builds are withheld from developers.
I haven’t written about the SDK because Apple’s announcement was so vague. We don’t yet know who will be allowed to write iPhone applications or whether they will be fully native peers of the built-in applications. The sweetness is yet to be determined, but it seems obvious that they’ll be limited in some way. John Gruber writes:
For all we know at this point, though, it could be something more like Dashboard widgets—but I think that’s unlikely.
John C. Welch has a great list of highlights, from the announced features.
Once I recognized the problem, the solution was easy. We built a list of inappropriate words (a list Paul referred to as “my favorite list ever”) and now check the code portion of each key against the list before sending it out. If there’s a match, we generate a new code automatically. This was quickly put in place and new purchasers can be assured that their license code will never tell them to F***-THIS-S***. Problem solved.
As a Mac developer who never touches Linux (I’m not anti-Linux, I just have other things to do), I put on my best polite humility personality and joined the channel, basically saying “Look, I’m not sure where to start, but you’ve got my app icon in your product.” The reaction was almost immediately hostile and confrontational. Whereas a responsible group of developers would appreciate having such a violation brought to their attention, this group seemed more interested in instructing me as the evils of not sharing, and bemoaning the hassle of yet another “patent” issue.
Steven Frank, Alexandra Grot, and many commenters discuss beta testing:
Panic is kind of an old-school company when it comes to beta releases. We don’t ship and have never shipped anything labeled “beta” to the general public, and personally, I think that’s kind of an ugly trend. If it’s shipping, it’s not beta, kinda by definition.
Zennstrom says Ebay “overshot in terms of monetization,” which the Journal translates to mean, “eBay overpaid” and which FSJ translates to mean, “I robbed you big-time, frigtards.”
I have 228 feeds in NetNewsWire. I’m guessing that’s a fairly typical count. It ends up being about 30-60 new news items a day. I noticed I was reading my news in what may be a unique way and thought I’d share…
With software, though, the constraints are invisible and arbitrary. The limitations regarding what is and is not supported are issues of won’t rather than can’t. Right now, today, Apple could choose to support, either officially or tacitly, the development and installation of third-party iPhone software. They have chosen not to.
It takes too long to load a whole Web page just to get to a specialized search box. Fraser Speirs made a quick-loading Wikipedia search page. I've made my own with a few more sites. The searches open in new windows so that you don’t have to reload the search page later.
Back in June, MacJournals wrote a 13,000-word article that explained some of the virtues of ZFS and gleefully debunked the (crazy) rumor that it was to be the default file system in Leopard. Amid solid points about areas where ZFS falls short compared to HFS+ was much sneering at “command-line-addled ‘everything invented by Apple must be evil’ true believers” who want Apple to switch to ZFS. (It was the Attitudinal, after all.) A few days ago, AppleInsider wrote a fairly typical rumors article about ZFS and Leopard. MacJournals responded with snark, which was not appreciated by Drew Thaler, a former Apple filesystems engineer. And now MacJournals has responded to Thaler, saying “You don’t have to hate ZFS to know it’s wrong for you.”
My opinion is pretty well summed up by Thaler’s statement in the comments:
If you’re an OS engineer and you aren’t hard at work solving the problems intrinsic to that TODAY, you’re not doing your job. HFS+ is “not that bad” for today’s needs. It’s going to be woefully inadequate real soon now.
ZFS isn’t ready to be the default Mac OS X filesystem today, but HFS+ is or soon will be a liability, and ZFS is perhaps the best candidate for its eventual replacement. Some features like snapshots and merging multiple drives into a storage pool may not make sense for all consumers, especially on notebooks, but there’s no requirement that they be used. There are still data integrity features that could benefit everyone, as I was reminded this weekend when I had problems with the catalogs of two HFS+ drives. And, personally, I think snapshots and pools will be relevant to consumers sooner than people think.
The problem is that, as MacJournals explains, ZFS (as it currently stands) can’t be a drop-in replacement for HFS+. It supports filenames only half as long. It’s case-sensitive rather than case-insensitive/case-preserving. It has inefficient storage for certain extended attributes. Thaler thinks the filesystem should be case-sensitive and the insensitivity should be layered on top by the application frameworks. This wouldn’t be perfect, but I think it could be “good enough.” (The current situation isn’t perfect, either; relying on the filesystem’s case folding means that some software won’t work properly on UFS or HFSX.) Apple to date hasn’t shown much interest in using extended attributes, so I think MacJournals’ concerns about increased space consumption under ZFS are overblown. Of course, I hope that Apple will start using extended attributes more, and if they do that could become a problem with ZFS.
So what’s the way forward? Apple could stick with the current HFS+ or try to add more features to it. It could use ZFS or its own customized version of ZFS. Or it could use another filesystem entirely. I have no inside information, but my guess is that Apple will eventually ship Macs that boot from some version of ZFS. Perhaps it will make changes to ZFS and try to get them into the official version. I don’t think this is an area where it makes sense to swim against the tide. Users may end up having to make a few concessions, but frankly I think using 128-character filenames instead of 256-character ones is a great tradeoff in return for ZFS’s data integrity features alone. (Use of super-long filenames is limited due to OS X’s PATH_MAX, anyway.)
Update: Jesper covers a point I made above, but should have emphasized more: “‘Everything on’ isn’t the only way to run ZFS.”
Update 2: MacJournals responds to my post, still emphasizing the large storage pools and mirroring, but its main target seems to be “ZFS fans dishonestly asserting all of its ‘magic’ properties without honestly discussing its limitations.” I hadn’t seen much of that, but I try to avoid fanboy circles.
Update 3: Drew Thaler responds. I don’t understand why more people aren’t bothered by the error rates with today’s hard disks. This is one of the reasons that EagleFiler checksums all the files in its library.
Update 4: MacJournals responds to Thaler’s response. In the original article, they said ZFS was “completely unsuitable for a Mac OS X startup disk, now or in the foreseeable future.” Now they say, “We do, however, reject the notion that everyone would be willing to make that compromise with today’s hardware. We believe those who are should have the option,” which is basically what I think. It should be an option, soon, for those whose data and drive(s) are such that ZFS wouldn’t use too much disk space or be too slow. There’s also a strange part where MacJournals seems to suggest that Apple should try to integrate ZFS ideas into HFS+ or else build an entirely new filesystem. “The entire discussion of filesystems is skewed, from the start, towards the default position that Macintosh-related filesystem constructs are somehow bad.” I think it’s, rather, that some of us wanted certain ZFS features yesterday. ZFS already exists, and it could provide real benefits relatively soon. The other approaches would probably take much longer, for relatively little benefit. The primary reason for Apple to re-invent the wheel (unless it already has a secret project to do so that’s near completion) would be if it had the attitude towards Unix and open source that MacJournals ascribes to ZFS fans and Mac technologies (which, for the record, I tend to like).
So Apple’s modern keyboards have a bias against activating Caps Lock at all, and another bias to turn it off as soon as possible. That fits in perfectly with how I (mis)use Caps Lock, but I can’t help thinking it’s ALSO a subtle nudge to those to abuse Caps Lock to TONE IT DOWN A LITTLE.
He’s even made a video.
WebKit now supports CSS @font-face rules. With font face rules you can specify downloadable custom fonts on your Web pages or alias one font to another.
Steve Purcell is hosting a Git mirror of the Rails Subversion repository. Over 7,500 commits and 59,000 objects fit in just over 9 MB. You can make your own using git svn clone http://svn.rubyonrails.org/rails/trunk, but it will take a while.
Apple came out with their online store, and they charged for music. They said “We know you can get music from elsewhere, but we’re going to make the user experience so good that you’ll want to get it from us.” And guess what? They were right, it worked!
The tack they are taking with the ringtones, though, is not “We’ll provide such great ringtones that you’ll want to buy from us” but rather “This is all you’re ever going to be able to use, too bad if you want to use something else.” I think they took a winning formula, and got it entirely backwards.
He’s handling the 1.1.1 update (which broke iToner) in a reasonable manner, except that I think it’s misleading to say that iToner uses the same APIs as iTunes to put files on the phone. Sure, they may be API calls (rather than SPI calls) from the perspective of Mac OS X, but the phone itself has no API. It’s closed. To know which APIs to call, you have to reverse-engineer iTunes. There are better and worse ways to gain unsupported access to the phone, but there is no “right way” to put data on it except manually using iTunes.
The October issue of ATPM is out:
Providing a custom navigational control encourages users to ignore the built-in button bar while they are in your application, decreasing the possibility that they will mistakenly tap the Safari on iPhone back button and strengthening the feeling that they are using a standalone application.
I get that you don’t have the API ready, or don’t want to share it, or whatever you’re reasoning is. I don’t really care anymore. But please stop insulting my intelligence. Stop telling me how I should be happy to run my code in a browser and then turning around and telling me that it’d really be a good idea if the user didn’t notice how they were in a browser.
