Re: Searching the headers in Xcode (Re: [ANN] Xcode + Leopard at WWDC this year)
Re: Searching the headers in Xcode (Re: [ANN] Xcode + Leopard at WWDC this year)
- Subject: Re: Searching the headers in Xcode (Re: [ANN] Xcode + Leopard at WWDC this year)
- From: Laurence Harris <email@hidden>
- Date: Fri, 21 Jul 2006 10:52:45 -0400
On Jul 20, 2006, at 8:34 PM, Steve Checkoway wrote:
On Jul 20, 2006, at 5:15 PM, Laurence Harris wrote:
On Jul 20, 2006, at 4:56 PM, Steve Checkoway wrote:
If by geek you mean it took 10 seconds of looking at it, then yes.
If looking at it for 10 seconds was all it took I'd have had it
set up long ago. ;-) The fact that such a basic option requires
an auxiliary window and multiple steps including the use of regexp
supports the notion that the design of Xcode has the geek user in
mind. Sure, I expect an application like Xcode to have power
features and offer lots of control, but I also expect a Mac
application to provide simple, intuitive access to commonly used
features.
Keep in mind you're programming here. Some technical ability (such
as the use of multiple windows in an application) is required.
IMO, this is exactly the kind of thinking that is responsible for
Xcode (and other developer tools I've seen) often having non-
intuitive, awkward -- and dare I say -- geeky interfaces. It's the
notion that programmers don't need, appreciate, or even want software
that's easy to use. That we in revel in the fact that we can use such
tools while mere mortals would never be able to grok them. I remember
years ago encountering people who genuinely believed that PCs were
better than Macs because they were harder to use. I didn't buy that
reasoning then and I don't buy it now. Maybe I've missed something,
but I noticed anyone saying Xcode's Find window is the greatest thing
since sliced bread. The comments I've seen suggest that most people
have some issues with it and some even hate it. How is it that Apple,
the leader in providing the best computer user experience, turns out
something like that?
For a long time I couldn't understand why so many people would
ask questions on the carbon-dev list for which I could find
answers in less than 30 seconds by searching the headers in CW.
Now I understand. ;-)
I don't. This couldn't have been easier to set up.
Nonsense. It could have been a checkbox in the main window that
didn't require five or six steps in a separate window.
If you're searching the Carbon headers, all you need to do is have
the framework included and tell it to look in the Frameworks. They
don't contain source so you're going to be search the headers.
Still not like having a checkbox. Still requires accessing a second
window, which I do not like for multiple reasons. Furthermore,
there's a "Source files only" radio button in the Options window. Why
not a "Header files only" radio button as well?
In any case, no matter how easy you find it to set up criteria
like this, by requiring the use of the Options window you can't
specify multiple criteria. For example, if you set up a find set
for the system headers and another for your own headers, you can't
use them together to search all headers.
That's true, you cannot. Being able to specify multiple constraints
would be nice but then you'd end up with something like the Rules
in Mail and even there you only get two options (if all apply or if
any apply). I agree with what you said before about needing 2^n
sets for n different options (I'm paraphrasing); however, consider
how many of those you actually use? If you search your headers and
the system headers together often, make a search criteria for it.
If you search them separately often, make those. Chances are (uh
oh, another assumption) you don't need to create new search
criteria often. I just don't see a need to use all 2^n possible
combinations of search criteria.
True, but how many sets can you add to that popup before using it
requires more thinking and effort than clicking a checkbox? Or, from
another angle, if some common options were implemented as checkboxes,
for example, I'd need fewer items in that menu and that would make it
simpler to use. I already have seven items in that menu and I've just
started using Xcode seriously. I can easily see adding at least four
or five more, for example, to search subsets of source files related
to specific features in my application, and given that defining
searches in Xcode relies on this mechanism as heavily as it does, I
won't be surprised if I come up with several more. So I anticipate at
least a dozen and possibly twice that. If I could reduce that number
I'd see it as a good thing. Part of my problem with this design is
that I just like to see the settings I'm using. When those settings
are in a separate window and all I see is the name of a set, I can't
see the actual settings.
Maybe I'll get used to it and find it less cumbersome after a time,
but it seems others have used it for while and are still not enamored
with it. So at this point I'm still rooting for incorporating the
Options window into the main window and giving the search results
their own windows.
And finally, I think the Options button should be next to the sets
popup since it's what you use to edit that popup, and the Find button
should be where the Options button is now because the lower right
corner is the standard location for the action button in a window
like this.
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