Why doesn't OSX Finder have a proper tree view? | Hacker News Reader

Why doesn't OSX Finder have a proper tree view?

4 pointsrobomartin20 comments

This is not about Mac vs. PC. In fact, tree views as a means for graphically navigating and exploring the file system have been around a long time and on a number of platforms (Windows, Linux, Irix, Solaris, Amiga, etc.).

Is there a fundamental philosophical reason for Finder not offering a tree view?

Yes, the definitions of "proper" is variable. That's not the point. I find that tree views are far more useful and easier to navigate than what Finder offers. I understand that if all you've known is Finder none of this will make sense. Please refrain from down-voting based on tribalism as you would be down-voting a dedicated iOS developer who's been using Mac and other platforms for a long time.

View on HN

Actually, it is about Mac vs. PC.

A bit of history:

The classic Mac OS Finder never had a tree view. Heck, for a couple System versions, the file system (MFS) didn't support more than one level of folder hierarchy, so it would have been completely pointless. With HFS in System 4 (IIRC), that changed. Still no tree view though, and I don't think it was until System 6 that there was a list view, and not til System 7 were there disclosure triangles so you could drill down. (fun fact - though on OS X, you can adjust a slider to change icon sizes, back in OS ≤9, there was also "Small Icon View", which used 16x16 icons instead of the traditional 32x32, and put the labels to the side, rather than underneath) Despite a few other miscellaneous additions to the Finder over the years (tab view, At Ease (not really the Finder, but it shipped with certain Mac lines)), for System 7 through OS 9, most folks' file systems weren't that deep or complex. Having a tree view would have been mostly unnecessary and very Windows-like, which was something to avoid back then. There was even some outcry in OS 8 when the system got menus where you didn't have to hold down the mouse button to keep them open.

Come at it from the other side, NeXTStep Workspace's primary view was column view. So naturally that was left in the OS X Finder along with icon and list views from classic Mac OS. If tree view has ever been discussed at Apple in the past 15 years (and I wouldn't be surprised if it hasn't), it was almost certainly rejected as a throwback to the old Windows Explorer ca. 1995. Anecdote: in 2008-ish, at WWDC, there was a feedback forum, and while I can't remember what prompted the question, I asked if there were going to be resize handles on all the corners. I actually got boos from the audience and a look of horror from most of the panel, and a straight up "No. We're not doing that, probably ever. No way." as an answer. (Years later, I couldn't help but smirk when Lion had resize handles on all corners and edges.) The point is, if something potentially useful has too many associations with Windows, it was (and still is, to some extent) taboo.

Thanks for the history lesson!

This thinking is, of course, unfortunate. Any UI can benefit from ideas borrowed from others. I remember when I was using Irix (Silicon Graphics) heavily many moons ago. It had some really compelling ideas. I can't remember most of them but I think one I liked was that the focus followed the mouse, you didn't have to click on a window to give it focus.

Yeah, only being able to resize a window from one corner is a pain in the ass.

Also, not having a border around a window makes for a fine mess. Overlap a few terminal windows full of text to see the effect.

The irony today is that the the OSX GUI sits on top of Unix. Which, of course, has supported deep and complex directory structures for a long time.

I can see Apple's point in keeping it simple for the typical non-tech user. No issues with that whatsoever. Judging from those I know, they don't ever create deep directory structures on their own and probably don't need anything beyond what Finder offers.

That said, I firmly believe that advanced users, which includes developers, could benefit from a much more advanced Finder. A tree structure is only one aspect of this. For example, in Windows I can very easily tell Explorer to show system files. You can do that in OSX, but it isn't as simple it becomes system-wide not directory-specific and it pollutes the desktop.

Another thing that I find missing is the ability to see your path in a Finder window, you know, one that you can copy and paste into the terminal window or another Finder window. Another useful feature would be "Open Terminal Here". I've implemented this through an add-on I found and it is fantastic. This should be standard. Directory and file sizes without having to use "Get Info". Preview pane. Create <insert application> file here (i.e: text files). And more.

It'd be nice if Apple offered a way to switch Finder to "Advanced" or "Developer" mode and offer a closer-to-the-metal experience.

> Another thing that I find missing is the ability to see your path in a Finder window, you know, one that you can copy and paste into the terminal window or another Finder window.

You can: View>Show Path Bar. You can click/drag any folder in the path to get a file: URL or file path depending on your drag destination. Alternatively, your current selection can be copied/pasted into Terminal.

> Directory and file sizes without having to use "Get Info".

Use list view, pick Size as a column (should be a default, you may need to rearrange to get it visible next to the names). View>Show View Options; check "Calculate all sizes" for directories.

> Preview pane.

Column view has it directly. Hit space in List view for QuickLook, move the QL panel off to the side, and continue browsing. In Icon view: View>Show View Options; check "Show icon previews"; resize them large enough (≥48x48, IIRC) and movies can even be played inline.

Though this may sound a bit snarky, I mean it as a serious inquiry: have you actually used the Finder for more than 5 minutes since 10.4?

No, DTerm is not built in, but that's okay - no one's stopping you from installing it, or writing a better one†. The Finder doesn't have Dropbox built in either, and that's okay too.

†for instance, one that does the opposite: keeps a Finder window for each tab and window in Terminal on the current working directory.

> Though this may sound a bit snarky, I mean it as a serious inquiry: have you actually used the Finder for more than 5 minutes since 10.4?

Your comment doesn't bother me at all because you are, at the same time, sharing some tips.

> View>Show Path Bar

Yes, I've been using it for a while.

I've had "Show Path Bar" enabled for some time. It doesn't really work --dare I say-- properly. For one thing, the whole drag and drop thing is a pain. If the window you are going to is covered it takes some work to drop what you are dragging. Also, I can't drag and drop a path into another Finder window (well, I couldn't figure it out after a few attempts).

I would much, much rather have a plain textbox with the path that I can copy into the clipboard. That is far more useful in my opinion. Or at least a way to get to a plain text path, say, right-click and "Copy path to clipboard".

The closest I've gotten is a right-click->Get Info and then you can copy the "where" plain-text path. To open a new Finder window in this directory you have to use "Go to folder...". Of course, you can also drag from the path bar into the "Go to folder" dialog box to achieve the same.

I am not comparing to Windows, it's just a convenient example. You can find similar examples in various Linux GUIs and other non-Windows OS's throughout time. In Windows Vista, for example, the path is easy to copy and paste as plain text. If you need another Explorer window at this path you simply paste the path into the address bar and hit enter.

There are at least a couple of other uses cases for this. You are working in Photoshop and need to open a file in a directory that Photoshop is not currently pointing to. However, you already have that directory open in a file browser. In Windows you use the "Open..." dialog in Photoshop and simply copy and paste the plain text path into the "Open File" dialog box. Done deal. With the Path Bar in Finder you have a similar mechanism but you have to drag-and-drop, which is, well, a pain in the ass. Why? I have three 24 inch monitors. Dragging and dropping across that much real-estate gets old very, very quickly. It can actually become physically painful. I avoid drag-and-drop like the plague.

> Use list view, pick Size as a column

I've also had this for quite some time. I didn't realize I could ask it to show directory sizes, which is what really bugged me when I was working with thousands of media files. I was exploring various compression schemes and had to constantly use "Get Info". Just didn't think to look in view options. Thanks.

>> Preview pane.

>Column view has it directly. Hit space in List view for QuickLook, move the QL panel off to >the side, and continue browsing. In Icon view: View>Show View Options; check "Show icon >previews"; resize them large enough (≥48x48, IIRC) and movies can even be played inline.

Maybe I want too much: Real-time previews in list view within Finder, not in a separate window. Frankly, I don't enjoy having a million little disconnected windows all over the place. Again, think three 24 inch monitors, center, left, right and ten to twenty open windows. The fact that the menu bar doesn't stick to the application window becomes a really bad problem once you start working this way. Single screen on a small laptop, no issues whatsoever, there's only so much you can do with that surface area.

But, yeah, QuickLook is a tool I've used a few times when I had no choice.

Of course, in general, there's nothing wrong with OSX and its GUI. It's a very capable and beautiful system. No arguments there of any kind. I think you might find that lots of people who've had experience with other systems might find some of the options Apple made either difficult to use or nonsensical. You can say the same about other systems. There is no such thing as perfection. From the perspective of anyone who's only been exposed to MacOS everything makes perfect sense. There are lots of people like that. In a sense, you don't know what you are missing (or what you have gained) unless you spend a non-trivial amount of time exploring and understanding other options.

Back to the tree view...no joy I guess. Looking for a third party app that might implement this and other concepts (tabs in Finder anyone?).

Thanks again for your pointers.

> If the window you are going to is covered it takes some work to drop what you are dragging.

cmnd-tab and cmnd-` work during drag and drop in all but the most poorly written applications. And most of those poorly written apps are broken in Lion anyway.

> With the Path Bar in Finder you have a similar mechanism but you have to drag-and-drop, which is, well, a pain in the ass.

Oh, I agree, but that's a problem with NSOpenPanel, not the Finder. Subtle distinction, but it's there.

> The closest I've gotten is a right-click->Get Info and then you can copy the "where" plain-text path.

Copy (cmnd-c) the folder or file puts the whole path on the clipboard (along with a file: URL and file promise - which gets used is determined by where the paste takes place).

In my memory, MFS did not have directories at all. The illusion of directories was implemented in the API's on top of the file system. Also, I do not remember a limit of one level. The need for more than one level simply did not arise, given that the storage medium held 400kB, and a thoroughly minimized OS maybe 100kB (20kB or so more if you wanted a printer driver), and an app 50kB (all sizes from memory, so they can easily be by a factor of two)

Back to the original question: the Finder has a tree view, but it is different than what Windows offers; it includes the files in the tree view.

Next question probably will be why Windows doesn't properly sort directory items by name, but insists on sorting by 'is a directory' first :-)

Yes, this exactly: MFS was a flat file system, and folders were just a UI convention implemented by the Finder. Folders could be arbitrarily nested, but only one file could have a certain name per disk. Given that a disk contained at most 400K this was not much of a practical limitation.

Only 2% of the people I meet in the last 10 years, weren't organised enough, to save the files in the proper folders. So why we need a complicated directory structure ?

For the 2%

No, seriously, what's under the pretty GUI is Unix. Developers and advanced users make use of the available Unix features, including deep directory structures.

You can see this consumer focus on tools like Xcode. I recently completed work on an iOS game with about 1600 media files. If you left it up to Xcode it wants to place all 1600 files at the root level of the app code directory. In order to create and maintain a usable tree of folders you have to go out of your way and jump through some hoops.

In what way is the hierarchical list display in the OS X finder not a "tree view"?

Are you referring to the column view? That's not a tree, it's a bunch of columns. If you have to reach a directory that is, say, 10 levels down, you end-up with a mess of columns that you have no need for.

Here's random example: http://www.chapo.co.il/content/articles/snmp-fig5.gif

Would you please explain why you define your .gif image as "not a tree"? You have hierarchically nested directories (folders) with a clear indication of which parent a nested group is connected with, which to me exactly fits my definition of a "tree" (hierarchically nested elements, each element having a single parent node).

Also, could you post a link to an image showing what you define as a "proper tree view"?

The link I provided is for an example of a tree view. Isn't it obvious?

> The link I provided is for an example of a tree view. Isn't it obvious?

Actually, from your text, no, it is not obvious that your link is an example of a tree view.

You ask a starting question about "column view" You then include two sentences describing why "column view" not not a tree and that a deep directory listing makes a mess of things.

Then, with zero clues to suggest you are making a full context change, you say "Here's random example: ...". Leading one to believe that the "random example" is a random example of a "column view", which is what the entire rest of this one post was referencing. If the entire statement relates to "column view", one naturally is led to the conclusion that a "random example" would be a random example of a column view.

I never use the column view. My Finder windows contain a hierarchical view of the contents of a directory; in Mac parlance this is a "list view," but I don't see any significant way it differs from what you are calling a "tree view".

http://www.redecho.org/2012/06/screenshot.png

Something like this? http://i.imgur.com/WUDny.jpg

Not quite, that's just a tree including all the files. When you've got quite a lot of folders and also file within it becomes really tedious using the finder's views.

It's almost as if Apple has made decisions that deliberately hamper anyone that needs to get complex tasks done quickly. Not click-by-click slowness of the Mac UI. The Windows UI is a helluva lot faster to navigate, even more so with reliable keyboard shortcuts.

When I'm on Windows, I frequently miss the instant side-by-side folder comparisons and the ability to select files in multiple folders simultaneously.

Like everything else, it's a tradeoff.

Plus, once you learn the traditional Mac shortcuts (right-left arrows to expand and contract, Command+down to narrow the view to one folder, Command-up to go back, type to select) it's pretty fast.

Of course, for really complex tasks, a decent shell beats any GUI.

There's a way to set up finder so that everything is sorted by kind. This means that all the folders will but up near the top together which would help you most likely. I think the problem is the way that files and folders are treated in Unix systems versus the way that they are treated in Windows, but I could be wrong, it's been a while since we talked about windows in any of my classes.

A "tree view including all the files" is a subcategory of "tree view". I'm not sure what it would mean to not include all the files, but apparently you are expecting some Windows-specific behavior here, and thinking that it is part of the fundamental nature of a "tree view".

Reply on news.ycombinator.com