Path Finder trial
July 12, 2014 at 12:37 AM by Dr. Drang
I’ve tried out Path Finder a half-dozen times over the years, but I’ve always gone back to the Finder, mainly because Cocoatech never seemed to be able to prevent the Finder from worming its way back onto my screen. I started another Path Finder trial at the beginning of this week, and I’m surprised to say that I’m still using it on both of my machines. This is longer than any attempt. But that doesn’t mean I’m completely sold on it.1
The most frustrating part of Path Finder is the behavior of its bottom drawer—a feature I both love and hate. I have it set to act as a terminal, which is the default behavior, and I’ve set up a keyboard shortcut, ⌃⌥⌘B, to toggle it. It’s nice to have instant access to shell commands in the directory I’m viewing.
Which is the first problem: the terminal access isn’t quite instant. When the bottom drawer appears, focus is not switched from the file browser to the terminal. This is inexplicable. I open the drawer because I want to type a shell command right now, and I have to believe that’s the common use case. By not handling the focus correctly, Cocoatech is creating an inefficiency in a feature that should be all about efficiency.
The aesthetics of the drawer are weird, too. The bottom edge of the file browser casts a deep shadow on the drawer, as if the drawer were far behind the browser—even when the drawer has focus. Worse, the shadow falls on the top two or three lines of the drawer, reducing the contrast between the text and the background. If I wanted to read gray on gray, I’d visit Daring Fireball.
Path Finder also seems to think that what I’m doing in one window is what I want to do from now on. I’m used to certain Finder window characteristics, like the size and the sorting order, being “sticky,” but Path Finder takes that too far. If, for example, I have the drawer open on the current window, every subsequent window I create will start with the drawer open. I don’t understand why anyone would want that.
Today I ran into the worst example of Path Finder’s drawer/terminal behavior. A USB thumb drive was attached to my iMac and a Path Finder window was showing its root directory. I needed to run a couple of shell commands in that directory, so I opened the bottom drawer and typed them in.2 Some time later I closed the window and tried to eject the drive. No dice.
The instance of bash that was still using that directory was the one that had been running in the bottom drawer of the window I’d closed. It should have been killed by Path Finder when I closed the window, but because it wasn’t, I was stuck with an unejectable drive. I opened Activity Monitor and rummaged through the list of processes until I found the instance of bash that was causing the trouble. I had to Force Quit it to be able to eject the thumb drive.
After some experimenting tonight, I’ve learned that in some cases I can eject the thumb drive after opening a Path Finder terminal drawer in it. It depends, bizarrely enough, on whether I close the drawer before closing the window: if I close the window without closing the drawer first, I can eject the drive; but if I close the drawer first, I can’t. This is the kind of bug that should have been wrung out of a program before it gets to version 6.5.
So I’m torn. Path Finder has become quite good at fending off the Finder, but now that I’m able to use it for an extended period, I’m running into annoyances I’d never seen in my earlier, shorter tests. On the other hand, the Finder has plenty of annoyances and limitations that Path Finder doesn’t. I’ll probably give Path Finder another week of continuous use and then return to the Finder. If the Finder seems unusable to me, I’ll know that Path Finder has won me over.
