• Explore the magic and the mystery!
  • The Tech Night Owl's Home Page
  • Namecheap.com





  • Hopes and Dreams for the Leopard Finder

    September 20th, 2007

    Just the other day, while recording an interview with Mac author and commentator Kirk McElhearn, we both ruminated about the fate of the Mac OS X Finder in Leopard. I think most of you agree with us that the present Finder is severely broken, and has been from the first.

    No, I’m not talking about the basic interface, because I think that’s pretty much in good shape. I’ve always found the column view a convenient way to check your stuff and drill down into deeply-nested menus. There are times, of course, when I prefer list view to reorder file display and such, but the basic layout gets the job done.

    We could, of course, talk of ways that things might improve, particularly when it comes to the Open and Save dialog boxes, where features that were pioneered years ago in such products as Default Folder and Super Boomerang, such as automatic rebounding to the last opened file, are still missing in action.

    It’s not that such tweaks represent an insurmountable problem for Mac OS X, since Default Folder has remained compatible with each operating system upgrade all these years. However, Apple’s online documentation for Leopard fails to mention any such enhancements, so I’ll assume that, aside from taking on some of the more distinct elements of the Leopard interface, the Open and Save dialogs will remain largely untouched. Sad, but true. But at least the publisher of Default Folder can continue to sell the product without competition from Apple. Our kudos to programmer Jon Gotow for his great work in making Default Folder such an indispensable tool.

    Maybe he deserves a job at Apple, or maybe that’s the farthest thing from his mind.

    As to the Finder itself, the prospect of grafting cover flow from iTunes affects me hardly at all. It’s neat to look at if eye-candy is your thing. But I prefer to see lists of the files I want to open, not pretty pictures that will simply put the brakes on my Finder navigation process. But that’s a viewing scheme that is optional, so you can do what you want, and if you like the effect, then maybe Apple was right to include it. Of course, once I have the chance to really use Leopard, maybe I’ll change my tune, but I doubt it.

    My real concerns for the Finder are far more mundane. I want it to work efficiently, without bogging down. Now that may not seem to be such a demanding request, but when you look at every single version of the Mac OS X Finder, you’re apt to think it’s an impossible accomplishment. Sure, it’s gotten a little better over the years, but when you see it in action in a quad-core Power Mac G5 or Mac Pro — let’s not worry about the eight-core version of the latter — you will be astounded how bad things can be.

    Consider a very simple action, which is to copy the same 10GB folder to two other drives for backup. This is something I do regularly with my stash of audio interview files. And it doesn’t matter if the drives are internal or external, but let’s just say they are real fast mechanisms

    The first symptom you’ll observe is that the Finder has apparently been struck by a severe case of flu, for it becomes extremely sluggish. You try to open an application during this file copying process, and the launch sequence seems to take minutes, rather than seconds.

    If you have the temerity to try to open a Finder window and look over a few things, watch out for the spinning beach ball, because it can get to be mighty frustrating.

    Now consider network access. Apple touts its cross-platform capabilities, but watch what happens when the file share falls off the network for any reason. It doesn’t have to be a crash. Say you’re sharing files with your MacBook and the note-book drifts into sleep mode. The Finder will take its sweet time figuring that out and then some. During that period, you may think the Mac that’s connected to that MacBook has, itself, fallen asleep or perhaps crashed till things clear up, as they do eventually.

    Admittedly, a MacIntel seems to be a better home for Mac OS X, and the slowdown isn’t so severe. In fact, my dual-core MacBook Pro with 2GB of RAM outshines the G5 quad, with 4GB of RAM, in that regard. But the PowerPC is history, so I suppose I shouldn’t fret over that. An Intel-based desktop is on my shopping list, and one of these days, I’ll act.

    But I’m not saying anything here that Apple doesn’t know. Indeed, I have little doubt that Apple wants the Finder to, once again, become the showpiece of the Mac user experience, which means that speedy performance and efficient multithreading should be a given.

    Will it happen in Leopard? I can’t make any predictions, nor do I want to know what’s going on with the beta process, since that’s protected by Apple’s confidentiality agreements. Besides, any experience one has with prerelease software, good or bad, doesn’t always follow completely through to the final release.

    Let’s just say that I’m extremely optimistic that Apple gets it, and, further, that we will see many of our hopes realized when Leopard is released.



    Share
    | Print This Article Print This Article

    27 Responses to “Hopes and Dreams for the Leopard Finder”

    1. John says:

      From what I’ve read, I think that you’ll see great improvements in that regard. However, remember, it’s not the Finder itself that is screwed up in Tiger and previous versions (well, not the only thing, anyway). It’s the technology beneath. The multi-threading and scheduling, networking layer, IO layer. All conspire to make this a problem. If you notice that if you try a Finder replacement, like PathFinder, you won’t get much improvement either.

      Read this page about leopard:

      http://www.apple.com/macosx/leopard/technology/unix.html

      Specifically, read the paragraphs about Autofs, Multi-core optimized and streaming I/O. They all should, at least theoretically, help the performance problem with the Finder.

      I also read somewhere that I can find now, about finer grain kernel locking and I/O related stuff in Leopard that, IF APPLIED to the new Finder, should help greatly.

    2. Andrew says:

      Anything would be an improvement. There are very few things that OS X doesn’t do well, but multiple file copies is securely on that list.

    3. shane blyth says:

      I cant say I like the current finder at all.
      there are a couple of basic things that drive me nuts. Mainly the fact that when i open finder I am always having to resize a column or the windows in general. I use pathfinder mostly because when it opens I don’t have to fiddle at all. Someone told me a little trick so finder remembers it’s column widths and other dimensions. I click and drag to the size I like with the Option key held down. Problem is after you reboot it looses this and I have to do it again. Completely dumb.
      No other file manager needs me to do this all the time. Frankly Windows file manager kicks Finders butt

    4. Karl says:

      I’m in agreement. The network issues. The file copy issues. Windows not remembering settings are all a nightmare for me.

      But one thing that gets under my skin are the windows seem to take up an incredible amount of space. I would like to see the left side bar become detached and anchored on the left side of the screen and be available all the time. But windows would have to recognized that it’s there so they don’t fall behind it.

    5. Tuesday Night Tech Staff says:

      Multiple file copies is a MUST. Remember that old utility called CopyDoubler that used to do this under OS 9? How about a tabbed finder already? I think we talked about all of this on a past Tuesday Night Tech show, but none of these features seem to be featured in Leopard. What gives?!

    6. Blastdoor says:

      I’m in agreement. The network issues. The file copy issues. Windows not remembering settings are all a nightmare for me.

      But one thing that gets under my skin are the windows seem to take up an incredible amount of space. I would like to see the left side bar become detached and anchored on the left side of the screen and be available all the time. But windows would have to recognized that it’s there so they don’t fall behind it.

      That’s a great idea, re: detach the left sidebar and put it on the left side of the screen. there’s zero utility to having that sidebar replicated in every open Finder window. It’s basically the same logic that’s behind the single menu bar at the top of the screen — you can’t use more than one menu bar at a time, so why waste the screen space?

      Great idea!

    7. Kula bácsi says:

      True! The most annoying thing about OS X is the Finder’s pathetic network handling. If there’s a mounted volume with Apple Share or a Samba and the network goes down (e.g. wireless) you get served. The retarded Finder will try to reconnect the volume for 10 minutes (I’ve checked in the system.log), even the shutdown process will stop. Or coming out from sleep at another place after having a wireless connection at the previous one: sometimes 1-2 minutes beachball. I developed a habit to turn Airport off on my MBP before sleep to avoid these things. Pathetic.

    8. True! The most annoying thing about OS X is the Finder’s pathetic network handling. If there’s a mounted volume with Apple Share or a Samba and the network goes down (e.g. wireless) you get served. The retarded Finder will try to reconnect the volume for 10 minutes (I’ve checked in the system.log), even the shutdown process will stop. Or coming out from sleep at another place after having a wireless connection at the previous one: sometimes 1-2 minutes beachball. I developed a habit to turn Airport off on my MBP before sleep to avoid these things. Pathetic.

      Ah, yes, CopyDoubler. That was one of my favorites from the “old times.” I particularly liked its Smart Replace feature, and wonder why Apple hasn’t quite mastered that.

      Peace,
      Gene

    9. Louis Wheeler says:

      I’m no programmer, but I’ve heard that the Finder is still a Carbon application in a Cocoa wrapper. Carbon applications are not modern API’s that can give the power, flexibility and speed that a Cocoa API has. Carbon API’s were designed 10-12 years ago to be a transition from the old Mac operating system and they carry forward many workarounds necessitated by primitive, slow and obsolete hardware. The Carbon API’s were not designed to be multitasking and it can get confused when you try to do too many things at once.

      I know that Carbon API’s have been integrated well into Cocoa over the years, but rather than asking for a changed Finder, you should be asking that Apple remove the last vestiges of Carbon from its OS. I understand that Quicktime is still a Carbon app.

      Perhaps this change to Cocoa will occur, as the Mac migrates to 64 bit software. The move to Intel was good for us by removing the Classic programs which were 20 years old. Apple could not change the Finder until the last of the Mac OS 9 software was removed. Perhaps, it can do so now.

    10. Zaphod says:

      “Carbon applications are not modern API’s that can give the power, flexibility and speed that a Cocoa API has”

      Please stop repeating this nonsense. Cocoa is simply a way to make programming easier and quicker to do. It does not make faster applications, rather the opposite.

    11. javaholic says:

      The Finder is the most contentious software issue between Apple and their developers and users. Many reasons for that disharmony listed in this forum – everything from the UI design to lack of true multi threading – are unfortunately nothing new.

      Personally, I find it appalling that after several years of OSX upgrades they have failed to address a key part of the OS for so long. It really does make you wonder what software development is like within Apple. So while many of us laughed at Microsoft’s inability to deliver some of the promises they made with Vista, I wouldn’t say Apples current Finder is anything to crow about. Unless you count adding a sidebar.

      I’ll reserve judgment on the iTunes – I mean, Leopard Finder, until I’m using it. Until then I’ve been using PathFinder for the past few years and for me it smokes the current OSX Finder. And I’m with Gene – the Open and Save dialogue boxes need a serious overhaul. Hey – maybe that’s another ‘Top Secret’ feature we’ve yet to see?

    12. Louis Wheeler says:

      It’s strange, Zaphod, I’ve heard differently from experts in the field. That the Carbon API’s are fine for many applications, but that they aren’t Critical Path API’s like for a Finder. I’ve heard that Cocoa makes building applications easier. But, what about the quality of the Carbon API’s? Carbon was cobbled together by taking out 70% from the old Mac OS that could not use protected memory, controlled multi tasking and reentrant programing. I understand that Apple has been working on the Carbon API’s over the last ten years, but that Apple only finalized the Cocoa API’s three to four years ago.

      Again, I have no dog in this fight– just trying to understand.

      So, what is it that causes the Finder to screw up so badly? The behavior that Gene Steinberg speaks of is not what I would expect of multi-tasking, multithreading API’s.

    13. Zaphod says:

      If the Finder is lacking in some respects, Carbon isn’t the culprit. The Mac UI APIs are generally not thread-safe: the Cocoa UI classes are not any more thread-safe than the Carbon UI APIs AFAIK. However, that’s not really a big issue—it’s still possible to write a program that does file copies and server connections multithreaded without threadsafe UI APIs. For file copies the Finder does do that already (not so sure about server access—hanging when servers go away is a bugbear).

      If you do a big file copy and find that app launching is slow, I kind of doubt that that is the Finder’s fault—the Finder doesn’t launch apps beyond initiating the launch. The issue would be more to do with contention for disk access between the dynamic linker and the file-copy. Maybe it’s a scheduling issue. Have those complaining about this kind of performance tried doing the same copy with, say, rsync? If the Finder is slower for the same copy, then by all means bitch about the Finder, but it still won’t be Carbon’s fault; it would be a design issue in the file copy engine. Speaking for myself, the performance of the Finder is not a big problem for me (other than the server-gone hanging). It’s things like the old reliable spatial nature that I still miss; and popup folders.

      Anyway, Carbon: It is neither “cobbled together”, nor a stop-gap transitional API. I think this meme about Carbon being crufty is something that has sprung up out of a desire to have something to point fingers at and blame for any old performance or cosmetic issues that have nothing to do with APIs. Carbon is a perfectly nice and really quite clean API, and absolutely beautiful compared to Win32 (while at the same time being conveniently architecturally very similar, which is why I doubt you’ll ever see a Cocoa Photoshop or Filemaker. Carbon is very important for cross-platform applications). Yes it takes more work to do things in Carbon, but by the same token, if you have to roll your own solution for some things, you might well come up with a better-performing design that if you just lazily used the Cocoa building blocks.

      Disclosure: I’m an old-school Mac developer with a substantial codebase that uses Carbon (no, nothing to do with any apps named above). I will never be “transitioning” this codebase to Cocoa (which is not just a different API but a different _language_) because it would gain absolutely nothing, and would likely cost me a little bit of performance and would certainly cost all of my portability. Hence my objection to unfounded calls for the death of Carbon.

    14. Louis Wheeler says:

      As I said, Zaphod, I’m not a programmer. I’m interested in the Mac and I’m a “Big Picture” kind of guy. This means that I listen to people talk in plenty of areas where I have no active concern. I tend to look for trends to see if they are broken.

      The long term trend is for Apple to return to developments that had started in NeXTstep and Openstep. I believe that the NeXT engineers who took over Apple when Steve Jobs returned resented having to abandon Rhapsody and embracing Carbon in Mac OSX. They have integrated Carbon well into the programming envelop, but I see signs that Apple is starting to move away from Carbon.

      Apple seems to consider it “Legacy” programming and it has shown no hesitancy to abandon legacy software or hardware. I don’t imagine that there will be any announcements: just no new developments for Carbon.

      Carbon will be consigned to 32 bit applications and the Mac runs well in 32 and 64 bit. We will wake up one day to find that everything on the Mac will be 64 bit and it will all be in Cocoa. By that time, there will be another migration to leave behind the Carbon API’s, but I don’t see that happening for many years. Almost all of Apple’s hardware base, at its current growth rates, will be 64 bit Intel in five years, so who will care if Carbon is left behind? You? Sure. But, anyone else?

      May I suggest that you read the website of a Cocoa programmer discussing the impact of Objective-C 2.0 and a new version of Xcode which will be supplied in Leopard.

      http://theocacao.com/document.page/496

      Programming in Carbon will be more time consuming and thus costly than with Cocoa because there are fewer features. There will be a gentle pressure on you to abandon it. Carbon has no future at Apple; the future is 64 bit.

      My point is that the Finder is in Carbon and it needed to be so as long as there are many PowerPC Mac’s. There was no point to rework the finder in what Apple considers to be obsolete API’s. But Apple isn’t ready to go to a Cocoa Finder yet. In 10.5 Leopard? Not so I have heard. 10.6 in a few years? Perhaps.

    15. Roberto says:

      Yeah, Apple needs to stop focusing on candy and touchscreens for a while and Just Fix The Bloody Finder!(TM). The stupid thing hangs because it’s looking for a phantom printer or network device, for heaven’s sake. Does it not understand that notebook computers move?

      Also, why is it that browsing a large gallery of images in Microsoft Windows XP is so much faster and less painful than doing the same in Apple OS X? I ran a competition once, where I put my Windows PC (single Pentium 2.66GHz, 2GB RAM) and Mac (dual 1.8GHz G5, 2GB RAM) side by side and then opened a folder (in thumbnail view) with the same contents of about 200 high res photos. The Windows PC was sitting by the roadside whistling and checking its fingernails while the Mac is still huffing and puffing about 2 miles away.

      The current Finder performance always manages to piss me off for some reason.

    16. Yeah, Apple needs to stop focusing on candy and touchscreens for a while and Just Fix The Bloody Finder!(TM). The stupid thing hangs because it’s looking for a phantom printer or network device, for heaven’s sake. Does it not understand that notebook computers move?

      Also, why is it that browsing a large gallery of images in Microsoft Windows XP is so much faster and less painful than doing the same in Apple OS X? I ran a competition once, where I put my Windows PC (single Pentium 2.66GHz, 2GB RAM) and Mac (dual 1.8GHz G5, 2GB RAM) side by side and then opened a folder (in thumbnail view) with the same contents of about 200 high res photos. The Windows PC was sitting by the roadside whistling and checking its fingernails while the Mac is still huffing and puffing about 2 miles away.

      The current Finder performance always manages to piss me off for some reason.

      Are you browsing the images in the Finder or iPhoto?

      Just curious.

      Peace,
      Gene

    17. Zaphod says:

      “so who will care if Carbon is left behind? You? Sure. But, anyone else?”

      Adobe? Filemaker? Quark? Microsoft? Everyone with an interest in cross-platform software. Everyone who relies on software that’s been around for more than about 5 years. Anyone who wants to write software that’s not locked-into the Mac. Evidently you don’t care about any of these, but a lot of people do.

    18. Looks like improvements to Finder is worth the price of upgrade. 🙂

    19. Louis Wheeler says:

      Zaphod, I’m talking about where Apple will be in five to ten years. Apple, ten years ago, was beleaguered; now Dell is. There will be enormous hardware changes coming– paradigm shifts, even. I don’t really know where Apple is going with Objective-C 2.0 since it doesn’t seem to work with Mac OSX 10.4 Tiger. Apple seems to be obsoleting any previous software, so why not with its Finder, too.

      If Adobe, Filemaker, Quark or Microsoft want to be on future Macintoshes they will need to program in Xcode and that will push them toward Objective-C 2.0 and away from Carbon. It will be a gentle push, but it will be evident.

      I don’t have to care about those above people; they need to decide what camp they belong in. The old paradigms, and the marketing strategies therein, are fading. I’m trying to see the new ones. Microsoft’s dominance is at jeopardy, not just from Apple, but embedded Linux. Windows is getting very old, very fast. Apple is likely to steal away Microsoft’s high end consumer market while embedded Linux steals away the bottom enterprise market. Why does a cash register have to run Windows?

      Apple seems to be ignoring cross-platform software developers. BootCamp encourages that. Why be cross platform when you can have concurrent OS’s? Virtualization hardware from Intel is pushing in that direction, too. Is this a bug or a feature? Or does Apple have cards up its sleeve? I can’t tell.

      The tea-leaves I’m reading say that Apple is developing advances in its operating system that will leave Microsoft in the dust. Apple has had a tendency to patiently lay the groundwork for years before the implications are driven home. I’m getting hints of implications that seem to be going over your head. But again, I have no dog in this fight.

    20. Zaphod says:

      Louis: I don’t dispute that Cocoa is the future (not to mention the present) of most Mac development, but as long as the Mac is a minority platform, then cross-platform software does matter to a lot of people (virtualised Windows is an expensive last resort). I’m guessing Photoshop will still be around in 5-10 years, and Adobe have their own framework for x-plat development and they would be crazy to throw that away and double their workload. My only point really is that the irrational, quasi-religious belief that Cocoa is a silver bullet for performance is just plain wrong. Making software easier to write does not make it faster. Usually the opposite is true. Take a look at Pages 3 for an example. Rewriting the Finder in Cocoa won’t make it faster and it won’t make it better. Redesigning/rearchitecting it could make it better, but that’s not connected to the API you use. When a program deviates so far from the application model that Cocoa is designed for (as the Finder does), then it’s all new code anyway.

    Leave Your Comment