Safari Remembers

The new Safari 3 is out for both Leopard and Tiger (it's included in Mac OS X v.10.4.11). It's pretty nice, I have to say. It now works with Blogger's HTML editor dealio, which is excellent (though slightly buggy at present). The find function now kicks some serious — and, more importantly, some Firefox — ass. Safari now handles tabs intelligently, letting you not only rearrange them in a window, but also letting you tear them off or drop them into existing windows. All extremely slick. Oh, and it's really pretty and fast as Hell. Seriously, it's smokin'.

But perhaps my favorite improvement to Safari 3 is that window placement is now remembered properly. You see, Safari of yore (of Tiger, actually) would remember the placement of the last window opened, rather than the placement of what I'd call the "base" window, or the first window opened. So, after using Safari, if you'd opened any windows other than your first window — even if you then closed them — the next time you opened Safari you'd get a blank window where the last open one had been. Or sometimes in seemingly random spots. I complained about this a long time ago, and it never got fixed to my liking. It was part of the reason I ended up switching to Firefox — I'm rather anal about my window placement and I like my browser pinned to the upper right hand corner, but in Safari it was always moving. Argh!

Well, Safari 3 fixes this. Sort of. Actually, I'm running Safari 3 in both Tiger and Leopard. The behavior remains unchanged in Tiger, but in Leopard, all is as I like it. So perhaps this is a fix in Leopard and not so much a Safari fix.

Either way, it's just one more reason I like Leopard and can't wait to be done with Tiger.

Can't. Frickin'. Wait.

That said, will I switch back to Safari once I've successfully transitioned to Leopard? Only time will tell. But somehow, I doubt it.

Remote Management Commands in Leopard

A while ago I wrote about the networksetup command, which provides a command-line interface to network preferences, as well as the systemsetup command, which provides command-line control over additional system-level preferences. In the past those commands were stored in the labyrinthian:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support

Yes, inside the ARDAgent. Perfect.

Finally Apple has put those commands in a location the shell recognizes as a command path. In Leopard they reside in the far more sensible:

/usr/sbin

Now all you have to do to call them is... Well... Call them.

Really now. Was that so hard?

I Don't Care Anymore

I've heard that the WACOM company's name is supposed to be pronounced "wack-em." But I don't care. I'm saying "way-com." 'Cause let's face it, you just sound stupid saying, "Hey, can I try your wack-em?" Or, "Your wack-em is huge. Much bigger than my wack-em." Or, "Wow, I just love my new, giant wack-em."

Oh yeah, and I say, "OS Ecks" as well.

Deal with it.

What Everyone's Bitching About

There's been no shortage of commentary on Leopard's 3D Dock, mostly because it's just ugly as Hell. But that's fixable.

There's been almost as much bitching about two other new visual changes in Leopard. The first is the menubar, which is now translucent. I'm ambivalent about this one. On the one hand, I understand that, from a usability standpoint, it's a bad idea. It's now slightly harder to read a primary interface element under certain conditions, those conditions being, in particular, the use of busy Desktop pictures and/or patterns. The default Desktop picture for Leopard, in fact, is an image of outer space whose star field can directly compete for visual attention with text in the menubar. My argument to this, however, is that busy, distracting, high-contrast Desktop pictures are a far greater hindrance to usability than slightly-harder-to-read menubar text, and if you're really bothered by the menubar changes, you should probably switch to a nice, solid or muted Desktop background and remove all distractions from your life once and for all. That's what I do and, so, while the I understand that translucent menubar is not the best idea for usability's sake, it really just doesn't bother me in the least. Actually, I kind of like the muted, lower-contrast lack of in-your-face-ness of the new menubar.

The other big gripe has been about pulldown menu transparency. No. Seriously. David Pogue of the New York frickin' Times for Pete's sake:

The most serious misstep in Leopard is its new see-through menus. When the menu commands — Save As, Page Preview, whatever — are superimposed on the text of whatever document is behind them, they’re much harder to read. Often, Apple’s snazzy graphics are justifiable because they make the Mac more fun to use. In this case, though, nothing is gained, and much is lost.

This one I don't get. Pulldown menus have been transparent in Mac OS X for a long time. (Oh, wait. I mean forever!) The difference between how Tiger deals with them and how Leopard does is extremely subtle.

Tiger Pulldown Transparency: Pinstripes! Ew!
(click image for larger view)

And Leopard does away with the pinstripes, which to my mind is a huge usability gain. At worst we break even here.

Leopard Pulldown Transparency: A "Serious Misstep." Really?
(click image for larger view)

I wonder sometimes if people are forgetting that pulldowns in Tiger were transparent. You'd think, by the level of general annoyance with this change, that they had. Honestly, people. It's really not that bad. I'm totally on board with the Dock thing (though a lot of people don't mind that even). But when it comes to the new transparencies, they just don't bother me much at all. I hardly even notice.

UPDATE:
Oddly, Firefox's group bookmark pulldowns exhibit the old-style, non-blurred menu transparency, minus the pinstripes of course. I can't find another application that does this. Weird.

Firefox's Group Bookmark Pulldown: Old Skool
(click image for larger view)

Spaces Switchery

Leopard's Spaces application is pretty cool. I have to admit, I'm using it more than I expected to. Sure, it has some issues compared to older *NIX-based implementations that have been around forever. But I've never used a virtual desktop implementation until now, and all in all I like it.

I have had one little annoyance, however, and it deals with the fact that, as John Gruber puts it:

...Spaces seems designed for app partitioning, not task partitioning.

Indeed. Let's take an example: I have my browser bound to and open in Space One. I also have a Finder window open in Space Four, and the Finder is not bound to any particular Space. Currently, I am viewing my browser, and then I command-tab to the Finder. The behavior is to switch me to the Space with the open Finder window, Space Four. Cool so far. But what if I have a second Finder window open in Space One in addition to the one in Space Four. Ideally I'd like a way to switch, via the command-tab Application Switcher, either to the Finder window in Space One (the one with my browser window) or the one in Space Four (the one with the lone Finder window). Fortunately, such a thing is possible through the magic of click-and-hold.

So, if I'm in Space One and the browser is in front, and I want to switch to the Finder window in Space Four, I click command-tab, then hold the command button for a second. This takes me to the Finder in Space Four. But, if I'm in the browser in Space One and I want to switch to the Finder window in the current Space, I command-tab very rapidly and I switch to the Space One Finder window. Not bad.

Now what happens if we add a Finder window to Space Two? Well, things start to get a bit weird. A rapid command-click will still take you to the Finder window in your current Space. A click-and-hold command-tab will alternately take you to one of the other Finder windows in the other Spaces. That is, the first slow command-tab will take you to the Finder window in Space Two. Switch back to Space One and slow-command-tab again and you go to Space Four again.

Confusing? You bet it is. But at least there appears to be some thought going on as to how to manage applications with windows in multiple Spaces. Hopefully this gets refined a bit as time goes on. For now, I'll take it.