Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
- Subject: Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
- From: Laurence Harris <email@hidden>
- Date: Thu, 20 Jul 2006 20:34:38 -0400
On Jul 20, 2006, at 7:56 PM, Steve Checkoway wrote:
On Jul 20, 2006, at 4:32 PM, Laurence Harris wrote:
On Jul 20, 2006, at 12:31 PM, Chris Espinosa wrote:
Surely if you know enough about /usr/include to want to search it
explicitly, you know the ways to get to it through the standard
Mac OS X user interface that hides Unixisms from end users?
This is an assumption, or at least an expectation, but there's no
logical basis for believing it is always true. Developers have a
wide variety of backgrounds, work habits, and experiences. I never
use paths. To be honest, it would not even occur to me under
normal circumstances to type a path to specify a file because it's
just something I haven't needed to do in over 15 years of using a
Mac. Were I really a path kind of person, I'd probably be using
Windows. ;-)
That's impossible to believe. Do you keep all of your files in the
root directory of your harddrive? In 15 years of using a mac,
you've never had to double click a folder?
Double-clicking a folder is not typing a path (I did say "type a
path"). It's navigating a tree. A path is a text string. However,
read on and please stop trying to make it sound like I'm an idiot. I
am not.
Have you never #include <sys/types.h> before?
Actually, no, I haven't. I've never needed to.
All of these are using paths in a very explicit manner.
What part of using a file path is windows-ish? Every modern (and
many much less modern) operating systems have had file systems that
were not flat.
The practice of having users type paths to specify files and writing
software that relies on paths to track files. Prior to Mac OS X Apple
strongly discouraged the use of paths as file specifiers, relying
instead on references that incorporated file and directory IDs. It
wasn't until the Unix and Cocoa folks started writing path dependent
code that moving things started causing applications to get confused
and for problems to occur if a path is too long.
I organize my Applications folder into subfolders. I remember the
first time I played with iDVD and tried to run its tutorial. Because
I'd moved iDVD into Applications/Media, iDVD couldn't find its
tutorial which was in its own bundle. Is that your idea of a feature?
I've also seen Software Updater crash because an application wasn't
in the Applications folder. I think they've fixed it now, but I
remember when I used to drag certain applications out of their
subfolders back up into Applications before running Software Updater
just so it wouldn't crash.
We didn't have these kinds of problems prior to Mac OS X. They're an
improvement the Unix and Cocoa folks dumped upon us because they rely
on paths.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden