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: Dietmar Planitzer <email@hidden>
- Date: Thu, 20 Jul 2006 22:43:43 +0200
On Jul 20, 2006, at 6: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?
I don't quite see how the fact that a person knows about /usr/include
implies that he knows how an obscure feature of the standard open
panel in MacOS X works.
Anyway, some interesting history in this context:
(1) In OpenStep, Rhapsody DR1, DR2 and (I think) MacOS X Server 1
there was a user preference setting in the Workspace Manager (aka
Finder) called "Expert Mode". This mode was by default turned off. If
the user turned it on then the WM and the open and save panels in all
applications did show the traditional Unix directories including
hidden files and directories. This is the simple reason why the
NSOpenPanel/NSSavePanel have no API for this kind of feature - it was
under direct user control.
Then somewhere along the way to MacOS X version 10 someone made the
decision that this option should be removed from the UI.
(2) Up to and including MacOS X version 10.1, or was it 10.2, the
Cocoa open and save panels did have a clearly visible text input
field in the upper 1/4 of the panel. So it was easy for the user and
clear for the user how and where a path to a directory/file or how
and where the name of a file in the current directory could be entered.
Then someone made the decision that this clearly visible text field
should be hidden and only be made accesible via the keyboard.
However, there is no graphical way to access the text field. In fact
there is not even a graphical indicator giving the user an indication
that such a thing exists.
(3) In OpenStep, Rhapsody DR1, DR2 and MacOS X Server 1 there was a
framework called "System.framework". Actually, this framework still
exists but is only a sad mirror image of what it once was. At least
back then the framework contained, just like any other framework, a
folder called "Headers" which in turn contained all the system
headers (the one you can now find in /usr/include). Searching the BSD/
Mach/system headers was as easy as searching the Carbon headers is
today. You simply added the System.framework to your project and then
you used the project-wide find panel in Project Builder to search
them. Obviously, navigating to the headers via the WM/Finder was easy
too.
Then somewhere along the way to MacOS X version 10 someone made the
decision that the System.framework should no longer contain or point,
via a symlink, to the system headers. Interestingly enough, while the
framework still contains a symlink to a Resource folder it no longer
contains a symlink to /usr/include...
Each of the changes (1), (2) and (3) is in my opinion clearly a user-
ability regression which has made access to things like /usr/include
unnecessarily hard and more obscure.
Regarding the question what I would like to see improved in Xcode:
(1) No new features.
(2) No new features.
(3) Fix bugs which have been with us for 2, 3 and more years.
(4) Fix the performance problems which have been with us for 2, 3 and
more years.
(5) Fix all those many obvious usability bugs which make working with
All-In-One window mode an everyday pain and frustration. Especially
this bug: <rdar://3755087>. This is the most annoying bug that I've
ever had to deal with in any software I've ever worked with. No,
actually, strike that. The by far most annoying bug is that every-
time that I right-click on a target, that Xcode feels that somehow
it's necessary to open the detail pane. Now this is by far the most
annoying bug because it triggers another bug: if the detail pane is
closed and you open the info window of a target via the context menu
then the detail pane is opened (needlessly I might add) _and_ the
info window is opened _behind_ the Xcode main window. And why is the
detail pane opened although I never ever told Xcode to open it ?????
Or this <rdar://3755066>. Or this: <rdar://4062564>. Etc, etc, etc.
(6) Give us a plug-in API. A plug-in API with a bad design and a half
broken implementation is more useful than a plug-in API with a
perfect design and an even greater implementation but no existence.
(7) Replace the static linker with a static linker that is at least
1000x faster and supports link-time optimizations.
(8) Replace gcc with a compiler that is actually fast and doesn't
consume memory like nuts.
(9) Fix the build system so that it doesn't rely so much on CLI
tools. There is no reason to use CLI tools when you can do the same
by calling the equivalent system calls directly. Which avoids the
creation of new processes, is less CPU cycle and memory consuming and
consequently more efficient.
(10) Please and pretty please: change the error pane in Xcode so that
error messages are _wrapped_ not clipped.
(11) Please and double pretty please: there is no reason why link
errors shouldn't be shown in the detail error pane.
(12) Please and one-hundred times please: teach gcc that an error
message is supposed to be helpful. Today gcc has a tendency of
producing error messages (in the case of C++) which often remind me
of little riddles or exercises in applied cryptography.
Yes I do know about Radar and the effectiveness of filing bugs and
enhancement requests there - this is why I've stopped doing that in
the case of certain technologies and that's also the reason why I
post here.
Regards,
Dietmar Planitzer
_______________________________________________
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