Re: Setting up searches in Xcode
Re: Setting up searches in Xcode
- Subject: Re: Setting up searches in Xcode
- From: Steve Checkoway <email@hidden>
- Date: Fri, 21 Jul 2006 12:53:43 -0700
On Jul 21, 2006, at 9:18 AM, Laurence Harris wrote:
On Jul 20, 2006, at 9:05 PM, Steve Checkoway wrote:
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.
I see that now. I was replying to the part about not being a paths guy.
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.
If you're using OS X you have them. I don't know if they existed in
pre OS X because I don't know if POSIX was supported.
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.
Keep in mind you can move/delete/rename a file that an application
has opened without any adverse affects (unless it decides to close
the file and then reopen it for some reason). Maybe I've just
conformed to the Mac OS X way of doing things in the past 4 (?) years
but I find that I can move my files where I wish. In the age of
bundles, support files need not be scattered around and as long as
someone doesn't hard code the path to the bundle, every thing works
correctly.
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 understand you now. However, in point of fact, it _is_ the Mac way
now. For good or bad (and I generally think this is good), this is
the direction it's moved.
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™.
No, the problem is not relying on the path, the problem was a bug in
the code.
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.
So you still need to know where to find the files or aliases to the
files. It seems like the same problem in that you need to explicitly
introduce a layer of indirection. Once you've done that the rest of
the files can be moved around as you please. As I pointed out above,
in the age of bundles, the need for this ability is lessened.
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.
I used FSFindFolder in Cocoa when I wanted that functionality even
though I "knew" what the path to ~/Library/Preferences would be.
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).
I understand now and I agree. There should be a checkbox for "Show
Hidden Files and Folders" or something similar. You can always use /
Developer/Tools/SetFile to change the visibility of folders.
I think we've reached the point that each understands the other and
while we have differing views on some things (Mac being UNIX now), we
agree that Xcode should have made searching headers a default option
or not have to use the "hidden feature" to do it ourselves. That
said, you should file a radar about it if you'd like that to change.
I think that about covers everything for this thread (let me know if
I'm wrong).
Have a nice weekend all.
--
Steve Checkoway
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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