Re: Setting up searches in Xcode
Re: Setting up searches in Xcode
- Subject: Re: Setting up searches in Xcode
- From: Laurence Harris <email@hidden>
- Date: Fri, 21 Jul 2006 12:18:28 -0400
On Jul 20, 2006, at 9:05 PM, Steve Checkoway wrote:
On Jul 20, 2006, at 5:34 PM, Laurence Harris wrote:
On Jul 20, 2006, at 7:56 PM, Steve Checkoway wrote:
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.
A path is a sequence of nodes in a graph. The file system is a
graph (links make it not a tree). A file path as a string is just a
representation of that sequence of nodes. They are two
representations of the same thing.
Yes, but I specifically referred to "typing a path," which means
using the text string representation.
Have you never #include <sys/types.h> before?
Actually, no, I haven't. I've never needed to.
How about headers in your own folders? #include "foo/bar.h"?
Nope. I don't have multiple header files with the same name.
Or what about <time.h> vs. <sys/time.h>? How do you distinguish those?
I'd have to search my files to see if I have any of these. If I do,
they would be in files for which I was not the principle author. My
background is in Mac software development, not Unix. Prior to Mac OS
X I never had any need for paths in includes because all of the
universal headers had unique names, as did all of my own headers.
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.
Is that somehow less brittle?
For some things, absolutely. It's the reason aliases can follow
things even if you move and rename them or the folders that enclose
them. Aliases contain both paths *and* node IDs, which is why they're
so robust. Anytime you use a path to store a persistent reference to
a file you have a reference that will break if the user moves or
renames anything in that path. Once that starts happening users
become reluctant to move and rename things, and when that happens
they feel they have less control over how their files and
applications are organized. Why should someone who paid $3000 for a
computer feel as if he can't reorganize his files the way he wants
when we have the technology to let him do so and reorganize them as
often as he wants? The Mac is about providing the best possible user
experience, and every time you limit users unnecessarily you fail in
that objective. Paths make sense for source files in a project and in
some other situations, but for most software they just create
unnecessary limitations. Users can even move files while they're in
use by an application. A user may save a file to the desktop because
he's in a hurry, and a few minutes later move it to a more permanent
location. If the application is maintaining a reference to that file,
it should continue to work even after the file is moved or even
renamed. Otherwise you're limiting the user unnecessarily. FSRefs and
aliases let you do this. Paths do not.
Regarding your previous comment comparing paths to opening a folder
in the Finder, understand that these are not the same. In particular,
I can use an alias, an item in a DragThing dock, a icon in Apple's
Dock, a Reveal in Finder contextual menu command in an application
such as CW or Xcode, and even other, third party options to open
folders in the Finder with absolutely no thought as to their paths. I
have folders I access with DragThing and source files whose paths I
couldn't even tell you anymore without giving it real thought, and I
like it that way. I need to access the folder, not be able to type
its path. The latter is just one way to accomplish the former. It's
not my preferred way, and in point of fact, it's not the Mac way. ;-)
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.
If it couldn't find it's own bundle then that was just a stupid
bug. There are two simple apis that I know of (CFBundle and
NSBundle) for getting that information. As you said, those were bugs.
Agreed, but the source of the bug was most likely using a hardcoded
path to find the bundle instead of an NSBundle API since iDVD could
find it if you hadn't move the application. In short, relying on a
path -> bad user experience, which is A Bad Thing™.
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.
It's been a long time since I used OS 9 but it seems like you're
saying that you could take any application that had files it
depended on (configuration files and so forth), put them all in
different folders, anywhere you wanted, renamed them, and the
application still knew exactly where they all were?
You need at least one file whose location is known, and that was
typically your preferences file. You could also assume that
application support files created by the application without user
interaction (no save file dialog) and which users would not normally
access directly were where you expected them to be, assuming you put
them in places like the Application Support folder. But if the user
could reasonably be expected to access something in the Finder, or
the user has control over how it's named and where it's created, it
shouldn't be referenced by path.
How? Where was that information stored?
Two ways. The standard system folders such as the Preferences and
Application Support folders are located using FindFolder and now
FSFindFolder (in Carbon -- I don't know what Cocoa uses). Items whose
paths the user might change are referenced by aliases. Applications
can store aliases and use them just like the Finder does.
Could you then copy those all to another computer in different
locations and have it still work?
That's bit too general of a question for a yes or no answer, but
let's say you keep a list of user projects in your preferences file
so you can display a list of them in your application, and each of
those projects is a file the user saves with a save file dialog. Your
application's ability to find those project files shouldn't go toes
up if the user decides one day that he wants to change the way his
projects are organized on disk. This happens a lot in practical use.
User creates project 1 in folder A. Then project 2. After project 42
he decides he wants to split the contents of A into multiple folders.
That shouldn't break anything. If he copies the whole kit and
kaboodle to another disk it may or may not cause a problem, but if
aliases are used, they contain paths as well as node IDs, so there's
still hope. ;-)
I don't think it's unreasonable for you to know where the system
headers are located as a programmer even if regular uses never need
to know.
Sure.
I also don't think it's unreasonable to want Xcode have that as a
default search set. I just don't buy the claim that since you've
never had to type in a path before that means you should never have
to.
That claim was never for sale. ;-) I only said that I was unaware
of the fact that you could open a window to enter a path and that it
wouldn't have even occurred to me to do that because I've never had
to do it before. My point was that hidden features should never be
*required* to accomplish a task, especially one as basic as selecting
the /usr/include folder from within Xcode. And especially when that
hidden feature isn't even available in all applications (this one
isn't available in Carbon applications).
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