[King Bob On The Cob]

Apple's got a job discription looking for a new employee to work on the Finder... (Someone here take the job and actually fix it up a bit!)

[m a d r a]

Code:
...Work on performance and responsiveness of the Finder, making it feel lightweight, fast, snappy and pleasant to use......

woohoo! - let's hear it for "snappiness©"

[Weyland-Yutani]

One engineer? Wow.

It shows that they mean business now that they're doubling the Finder programming team!

cheers

W-Y

[all2ofme]

Hee hee - nicely said

[brink]

The Finder team is seeking an energetic, motivated software engineer to help develop next generation versions of the Finder, the notorious file browser for Mac OS X.

Heh.

[Horsepoo!!!]

Actually...the Finder may be going somewhere...somewhere new.

I'm just disappointed that they're hiring this late? I was secretely hoping that they were concurrently working on a new Finder for the past few years. I guess I was wrong. What we see now is what was being developed.

That's a damn shame.

[moonmonkey]

Title: Finder Software Engineer
Req. ID: 2510614
Location: Santa Clara Valley, California
Country: United States
Req Date: 13-Jan-2006

The Finder team is seeking an energetic, motivated software engineer to help develop next generation versions of the Finder, the notorious file browser for Mac OS X.
You will be responsible for developing new features of an application that is often perceived by our users as the "face of the system". You will be working on user interfaces spanning various browser views, new advanced search features, navigation and data presentation as well as many other parts of the application.

In this position you will be expected to:
- Participate in all of the various stages of feature development from design brainstorms, through feature development, all the way to fixing that last critical elusive bug under a tight release deadline.
- You will be required to produce clear designs, excellent implementation and tight code.
- Deliver tight, well implemented features, fix bugs and develop Finder into the best file browser on the planet.
- Work on performance and responsiveness of the Finder, making it feel lightweight, fast, snappy and pleasant to use.

If you are passionate about working on user Interfaces and usability, love writing tight code, enjoy being a team player, hone your programming skills as a hobby, aren't afraid of working on large code bases and share your code with other engineers, this is a job for you.


BS in CS or equivalent.
Excellent knowledge of C++, software design, engineering techniques and best practices.
Excellent debugging skills.
Good knowlege of Mac OSX and/or Unix.
Experience with developing User Interfaces.
Experience with various phases of the UI design process.

Preferred experience:

5+ years of experience developing software.
Experienced in using STL, Boost.
Shipped shrink-wrapped products.
Knowlege of Core Graphics, HIView and Carbon, Core Foundation.
Experience developing file browser, graphics, productivity or creativity desktop applications a plus.

[Targon]

Why bother Apple should bother wasting time fixing this poobar...They should just buy Pathfinder.

[SirCastor]

Originally Posted by moonmonkey

BS in CS or equivalent.
Excellent knowledge of C++, software design, engineering techniques and best practices.
Excellent debugging skills.
Good knowlege of Mac OSX and/or Unix.
Experience with developing User Interfaces.
Experience with various phases of the UI design process.

C++..? They don't want this person to be devloping with Objective C? What about XCode? What about Cocoa for crying out loud! (I realize that they may simply be saying that because Objective C doesn't have the exposure that C++ does, and that the Finder was ported and is ultimately a Carbon app, but come on...)

[JCS]

I wrote about this yesterday. Although I too entertained notions of a Cocoa Finder (however foolish those notions may be) I think the job posting makes it clear that the Finder is staying Carbon. But the language of the posting itself is a sign of that this time may actually be different. Whether "this time" is 10.5 or 10.6, I don't know.

[Catfish_Man]

Originally Posted by SirCastor

C++..? They don't want this person to be devloping with Objective C? What about XCode? What about Cocoa for crying out loud! (I realize that they may simply be saying that because Objective C doesn't have the exposure that C++ does, and that the Finder was ported and is ultimately a Carbon app, but come on...)

Why would ObjC be useful for a Carbon app? And no, the Finder was not ported, it's an OSX only Carbon app.

[goofticket]

Maybe the former engineer is now part of the Pixar group at Disney...

[Leia's Left Bun]

Like I said before they need to totally trash EVERYTHING about the finder. It doesn't work with todays tasks, is extremely dated and Apple should just start new from and interface point of view.

[SirCastor]

Originally Posted by Catfish_Man

Why would ObjC be useful for a Carbon app? And no, the Finder was not ported, it's an OSX only Carbon app.

If it wasn't ported, why was it written in Carbon? You're telling me they wrote it from scratch in Carbon? I don't think so. If it's not built using code from OS 9's Finder, it's built using code from NeXTstep.

The reason I brought up Objective C is because it's high time they moved the finder out of Carbon. But as is mentioned in about a gajillion posts around here, the finder needs to be replaced all-together.

[CharlesS]

Originally Posted by SirCastor

C++..? They don't want this person to be devloping with Objective C? What about XCode? What about Cocoa for crying out loud! (I realize that they may simply be saying that because Objective C doesn't have the exposure that C++ does, and that the Finder was ported and is ultimately a Carbon app, but come on...)

Um, maybe because they don't want to have to completely rewrite the whole damn thing?

Originally Posted by SirCastor

If it wasn't ported, why was it written in Carbon? You're telling me they wrote it from scratch in Carbon? I don't think so. If it's not built using code from OS 9's Finder, it's built using code from NeXTstep.

No, it was a new Carbon app, and was not ported from OS 9. If you have ever used the OS 9 Finder, it will be obvious to you that the OS X Finder is not the same app. In fact, the Finder in 10.0 was written in PowerPlant, which I'm pretty sure the OS 9 Finder wasn't. Many people on here like to make proclamations about how they know so well exactly why this was done, but the only people who know for sure are the Apple engineers who wrote it. In any event, the OS X Finder is definitely not a port of the OS 9 one, although I'm sure they probably found ways to paste in some of the old code here and there to save some time.

Also, the Finder doesn't need to be written from scratch. If Apple were to do so, they'd have to waste a lot of time reimplementing things that already work fine before they'd be able to make any actual improvements, and they'd almost certainly end up with a Finder you'd like less than the current one. I don't get what people keep complaining about - the current Finder is not that bad. It has some threading issues when accessing remote network shares. You do not need a complete rewrite to fix that. Other than that one issue, the Finder is a pretty good app. The only other thing that bugs me about the Finder is that I can't use Ctrl-A and Ctrl-E to skip to the beginning and end of a line when editing a filename. That could be fixed by moving the Finder to Cocoa, but it would be way more efficient just to fix the $@#%ing Carbon text widget so that I'd be able to use those shortcuts in all Carbon apps, including iTunes, which would make the whole system much nicer to use. IMO.

[OreoCookie]

Apple has two test-beds for new technologies: for improvements in Carbon, there is the Finder, for Cocoa, there is Mail. Ever wonder why Mail was the first with a new interface?

[Simon]

Originally Posted by CharlesS

The only other thing that bugs me about the Finder is that I can't use Ctrl-A and Ctrl-E to skip to the beginning and end of a line when editing a filename. That could be fixed by moving the Finder to Cocoa, but it would be way more efficient just to fix the $@#%ing Carbon text widget so that I'd be able to use those shortcuts in all Carbon apps, including iTunes, which would make the whole system much nicer to use. IMO.

I couldn't agree more. They certainly need to fix some Carbon issues (ctrl-a, ctrl-e and ctrl-k are also my favorite examples), not rewrite working code just for the sake of rewriting it.

[Simon]

Re the new Finder, here's what MacOSXRumors has to say about Leopard's Finder.

http://www.macosxrumors.com/articles...-on-spotlight/

...Meanwhile, anonymous sources revealed to MacosXrumors the first major feature of Leopard and it looks like it has to do with the Finder. According to the sources, Apple will entirely re-design the Finder in its next major Mac OS X update. The new version of the Finder, code-named “Chardonnay” (like the wine), will be totally based on the Spotlight meta-search technology which was introduced earlier this year with Tiger...

[chris v]

I don't understand why they'd hire someone from outside to spearhead this. Why wouldn't they promote from within someone who has some experience with the problem at hand? When they say "team" they give no indication of the size, either. The responsibilities make it sound pretty much like a one-man team. Why on earth would they turn the entire Finder over to a new hire?

[Millennium]

Originally Posted by SirCastor

If it wasn't ported, why was it written in Carbon? You're telling me they wrote it from scratch in Carbon?

Yes. It was written in Carbon, using a GUI framework from Metrowerks called PowerPlant. This framework was used in many popular commercial applications of the time, including Photoshop, but its OSX port was woefully incomplete at the time that OSX was first released.

Why did Apple do this? Nobody knows. What is known is that commercial software developers such as Adobe rejected Cocoa from the beginning, because it could not be used with their existing source code. Many of them even threatened to abandon the platform if Apple did not provide them with an API that could be used with their existing code.

Carbon was Apple's solution to this problem: a procedural, low-level OS9-like API for companies to use to upgrade their existing code. Initially, it was said that the API would be a temporary measure only. Nowadays that has changed, and it is morphing into the low-level API on top of which Cocoa is being rebuilt, but back in The Day it was a rushed hack-job, and everyone knew it.

The common theory is that the OSX 10.0 Finder was written in Carbon as a proof of concept: Apple's way of "proving" that Carbon was mature enough to write commercial apps. Most people agree nowadays that it was a miserable failure in this regard. Personally, I've always believed that they should have used AppleWorks as their proof-of-concept and kept the older Cocoa-based Finder from the older Rhapsody developer previews, not because of any inherent superiority but because rewriting the Finder wasted a lot of effort which could have been spent improving AppleWorks while the older codebase from Rhapsody received incremental improvements. Instead, OSX 10.0 gave us an unstable, underperforming, bug-ridden mess.

Things are better now, for the most part. The Cocoa-for-Cocoa's-sake zealots still whine, but most of the problems from the original 10.0 Finder have been dealt with.

I don't think so. If it's not built using code from OS 9's Finder, it's built using code from NeXTstep.

No, it's not. No, this doesn't make sense. However, it is the reality of the situation.

The reason I brought up Objective C is because it's high time they moved the finder out of Carbon.

I vehemently disagree on this. Cocoa is not inherently superior to Carbon in any way, and indeed, the situation has become such that major Carbon apps are needed to ensure that new technology can be accessed reliably from both APIs.

[SirCastor]

If for no other reason than to write the finder in Cocoa, they ought to do it as an example. Every developer thing I've ever been remotely privy, Apple is saying "Use Cocoa!" I won't say that there's not still the cocoa-over-carbon part of me arguing, but it still seems confusing.

How often do you see anyone up on stage saying "We want you to use Carbon folks!"? I dunno, I probably don't know enough about the situation to speak on it.

Thanks to those who answered the questions.

[kick52]

lets just hope this guy doesnt change "the smiling face finder guy" to some kind of cartoon character...


also, i hope it looks exactly the same (or better) with a lot more features....

[Horsepoo!!!]

Well I've just lost a frickin' 3 page essay on why the Finder sucks thanks to vBulletin and the MacNN servers so I'll cut right to the chase...forgive me if you don't understand why the Finder needs to be rewritten from scratch or even scrapped altogether. The answer would have been clear if vBulletin hadn't suddenly pretended like I wasn't logged on (hitting Back didn't bring me back to my post so I lost everything and couldn't get it back).

1. Interface sucks.
2. Concept sucks.
3. Redundancy (Spotlight window vs Spotlight within the Finder)

Those were 3 things I had expanded on but I'll skip to what I really want to see happen:

Finder needs to go. Replaced with a "Project Manager" of some sort.

File browsing should be integrated *into* the apps. Just like iTunes, iPhoto, Mail, Address Book, Safari all manage their files. 3rd party-developers should ideally write their own (for more flexibility) but Apple should provide an API to modify a *revised* Open/Save dialog that focuses on metadata instead of hierarchical browsing. The Open/Save dialog should automatically filter out files that aren't recognized by the app and only present the files that really matter (ie Keynote presentation and PowerPoint files within Keynote, Pages, Word, text, rich text, etc. files within Pages). The user can then find files by browsing metadata or searching for it (file name or a particular metadata).

The browsing and managing of specific files should be left to the app. The browsing and managing of project (or groups of files) should be done within the Project Manager-type app. This app could retain spatial navigation since it's an important concept when it comes to grouping things. But otherwise, single and specific files should be managed within an app via a custom interface or via a familiar Open/Save dialog that focuses on metadata.

Of course...the Finder could still exist for legacy purposes for finding files that have little to no useful metadata. But in no way should it remain the de facto standard for finding files and managing them.

[CharlesS]

Originally Posted by Millennium

I vehemently disagree on this. Cocoa is not inherently superior to Carbon in any way

Well, that's not true.

1. Cocoa is, of course, massively superior to Carbon in the area of rapid application development, although this would probably not make up for the even more massive problem of rewriting an entire complex app such as the Finder.

2. Carbon has issues with its text widgets, which don't behave the same way as Cocoa ones, leading to UI inconsistency. Certain shortcuts only work in Cocoa apps, the line endings are in different places in Cocoa and Carbon text fields, causing different behavior when you select a bunch of text, etc. The irritating thing is, this could easily be fixed; I have no idea why they still haven't done it after 5 major revisions!

3. Cocoa apps inherit a lot of really nice technologies, such as the system-wide spell checker and the Command-Ctrl-D dictionary look-up, which aren't that important to an app like the Finder but are absolutely great in an app like a web browser or a text editor.

4. Cocoa apps automatically get Services support, while Carbon apps don't unless they are explicitly written for it, and most aren't. This isn't an issue for the Finder since its Services support is already written.

5. Cocoa apps automatically get support for full GUI scripting, which is a great boon for people with special needs and also helps for other cool apps like macro programs, which are much more powerful when they can control an app's entire interface through AppleScript. This isn't an issue for the Finder since the Finder's support for GUI scripting is already written in.

Those are the big ones. There are probably a few others I've forgotten. As you can see, there are a number of ways in which Cocoa is superior to Carbon. It's just that none of them are relevant to the Finder specifically (except for #2, which drives me nuts and causes me to use Cocoa apps over Carbon apps whenever possible. Why don't they ever fix this?!).

[Catfish_Man]

Originally Posted by CharlesS

Well, that's not true.
<snipped>
Those are the big ones. There are probably a few others I've forgotten.

6) WebKit had some fairly serious issues with Carbon until very recently, iirc

Going the other direction, though:

1) WTF is up with Cocoa's path handling? Does Apple like having apps break when the user moves files around? Why can't we use their nice private wrapper around FSRef and Aliases?

2) As far as I know there are no Cocoa equivalents to CF[Mutable]Bag, FSGetCatalogInfo(), or many of the LaunchServices functions.

[saddino]

Originally Posted by CharlesS

3. Cocoa apps inherit a lot of really nice technologies, such as the system-wide spell checker and the Command-Ctrl-D dictionary look-up, which aren't that important to an app like the Finder but are absolutely great in an app like a web browser or a text editor.

FYI, Command-Ctrl-D dictionary lookup does work in Carbon apps that use HITextView or MLTE to render text.

[CharlesS]

Originally Posted by Catfish_Man

1) WTF is up with Cocoa's path handling? Does Apple like having apps break when the user moves files around? Why can't we use their nice private wrapper around FSRef and Aliases?

True, and this is one of the annoying things about Cocoa. I think it's a legacy issue - NeXT used paths, and they apparently don't want to revamp the whole API.

With that said, it's not very hard to write your own Cocoa FSRef wrapper, and I have done so in both of my main apps. In fact, I think there are several pre-made wrappers out there that you can use (BDAlias being one). With that said, it is kind of annoying to have to resolve the FSRef to a path every time you are going to use one of the filesystem APIs, which only accept paths as input.

2) As far as I know there are no Cocoa equivalents to CF[Mutable]Bag, FSGetCatalogInfo(), or many of the LaunchServices functions.

This is true, but it's easy enough (although slightly annoying) to call those functions from a Cocoa app.

Originally Posted by saddino

FYI, Command-Ctrl-D dictionary lookup does work in Carbon apps that use HITextView or MLTE to render text.

Really? I didn't know about that. Hmm, I'll have to try that out.

[Thinine]

Originally Posted by Catfish_Man

As far as I know there are no Cocoa equivalents to CF[Mutable]Bag, FSGetCatalogInfo(), or many of the LaunchServices functions.

You can use CoreFoundation in Cocoa apps pretty easily, and Carbon with a little more work. But I definitely think Apple should focus on developing Cocoa to the point where it's not necessary to use CoreFoundation or Carbon in Cocoa apps for either features or performance. All this duplication of effort in developing both Carbon and Cocoa to try and have the same features is a ridiculous waste of time.

[qnxde]

Yeah Dictionary works in iTunes from what i can see...

[CharlesS]

Originally Posted by qnxde

Yeah Dictionary works in iTunes from what i can see...

Where exactly in iTunes did you try it? It doesn't work for me when I try it in the ID3 tag text fields...

[cla]

Originally Posted by Targon

Why bother Apple should bother wasting time fixing this poobar...They should just buy Pathfinder.

Let's hope they don't... :>
Same stuff, just scarier.

[OreoCookie]

Pathfinder has some useful additions, but I still find it a bit cluttered, to be honest. But stuff like `smart sorting' (for the lack of a better word) (group apps, folders, etc. together). Also, the way you can go back and forth or use the drop-down menus on the top.

[Macanoid]

If PathFinder looks too cluttered, this might be for you: FileRun

[Leia's Left Bun]

Originally Posted by Macanoid

If PathFinder looks too cluttered, this might be for you: FileRun

That is supposed to be LESS cluttered?!!

[Horsepoo!!!]

Originally Posted by Leia's Left Bun

That is supposed to be LESS cluttered?!!

I agree...FileRun is garbage. I've never seen so much text within a single window. It's almost like the developers decided to tightened the kerning to fit more text into the interface.

Here's a lesson to developers...more text and more info inside a fixed area does make your interface powerful.

"File Management for Pros"?

Lemme fix that quote...

"For POS File Management."

[11011001]

Originally Posted by Horsepoo!!!

I agree...FileRun is garbage. I've never seen so much text within a single window. It's almost like the developers decided to tightened the kerning to fit more text into the interface.

Here's a lesson to developers...more text and more info inside a fixed area does make your interface powerful.

"File Management for Pros"?

Lemme fix that quote...

"For POS File Management."

Somewhere a developer just started to cry.

[Macanoid]

I think the comments on FileRun are just crap, sorry! It's not out yet so it's hard to say if it will be useful at all or not. The screenshot may look cluttered but, like PathFinder, a lot of the options can be switched off. I still stink it looks exciting. At least someone's trying to come up with something that may deal with some of the Finder's shortcomings!

[mactropolis]

Fully agree with Macanoid. I anticipate trying FileRun when its released next month. Looks like an interesting concept for file management.

[OreoCookie]

I haven't used FileRun, but it doesn't seem to be much better in terms of clutter than Pathfinder (if it is appropriately customized).

Some other features I like about Pathfinder: being able to open pdfs right away. That saves a few seconds each time I sift through my collection of pdfs, and I have a few hundred of them already (scientific articles). The stack is extremely useful for picking things you want to copy/move. The way you can group things in a view is also very nice (have different ways to group things also in column view, group folders and applications first, etc.).

[cmeisenzahl]

I think the calls for a complete overhaul of the Finder to be a bit premature, based on nothing more than a job posting anyway. ;-)