The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players. I'm not certain why the browsers are listed, but they're in the same boat for local files (perhaps opening a file:/// url typed in the address field would be broken, but double clicking a local html file or using their Open… features would still work).
User interaction must happen at some point, otherwise the apps have no clue what files to open.
Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1]
Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear...
I listed the editors due of their project handling and "search in folder" features. I listed the browsers, of course, due to their abilities to browse local files, more specifically, be able to open other referenced local files (images, scripts, links); this is very important for web designers. Archives split into volumes (e.g a sequence of .rar, .r01, .r02 etc. files) are still common in some areas, tipically the user only had to open the first file in the sequence and then the archived opened the rest. Not to mention the obvious case of unextracting all files from an archive.
> The editors you list all must open a file in response to some user action, right? They don't just automatically know that I want to edit ~/Documents/blah.txt. Ditto for the unarchivers and video players.
You open a playlist of files or a video file with linked subtitles, then you need to be able to open another file, that can be arbitrary located.
User interaction must happen at some point, otherwise the apps have no clue what files to open.
Xcode (and BBEdit's and TextMate's project features) and Dropbox are interesting cases. Dropbox can presumably ask for permission once for each directory the user wants to sync. It does, after all, already use a NSOpenPanel when the user asks to change the sync location. It remains an open question whether it can permanently persist that user-granted exception indefinitely. [1]
Xcode is special because opening a project will be a user-specific action, but then each referenced file will somehow need to be opened. There is no solution I'm aware of for that use case. If you're a developer in a similar boat, I strongly suggest filing a radar explaining how your app is broken by the lack of such a solution. I bet the BareBones crew is already working their WWDR contacts, making their needs clear...
[1] http://www.cocoabuilder.com/archive/cocoa/308884-sandboxing-...