Re: Xcode's Find in Project
Re: Xcode's Find in Project
- Subject: Re: Xcode's Find in Project
- From: Laurence Harris <email@hidden>
- Date: Tue, 20 Feb 2007 00:53:08 -0500
On Feb 19, 2007, at 7:40 PM, John Daniel wrote:
On Feb 19, 2007, at 12:50 PM, Laurence Harris wrote:
I seem to remember having to type Apple-S, Apple-W 27 times in a
row.
Actually, we say Command-S and Command-W. Windows users say Apple-
S and Apple-W. ;-)
That said, no, you didn't have to use those commands 27 times.
Command-Option-S would save all of them at once, and Command-
Option-W would close all of them.
Yes! I remember now! I even used that sequence a couple of times -
but no more than that. It used to be a source of pride for Mac
users that they didn't have to remember all those 3-key combinations.
I'm pretty sure that anyone who would be daunted by an extra modifier
would have real issues with Xcode's Find in Project window. ;-)
I think your complaints are more nits than serious shortcomings.
Don't you think it's a bit pretentious to pass this kind of
judgement on someone else's work style?
I haven't judged anyone's work style.
In a sense you have. By calling my complaints "nits" you've basically
said they don't seriously affect my work. That requires a judgement
on your part regarding how I work and how these issues would impact
upon it.
Someone started a thread about "Xcode improvements" that has now
filled up my Xcode folder with about 75 messages. Many of those
messages are about how awful FileMerge is. Well, I really like it.
A couple of those 75 messages have made me like it even more. If,
on the unlikely chance that anyone at Apple is paying attention, I
don't want them to think that the Xcode users are unanimous in
thinking that FileMerge is junk. Some do. Some don't. Like
scientists studying Global Warming, their opinions are divided.
In the case of global warming, if one group is right, there's no
problem. If the other is correct, we're headed for a disaster. I'm
not advocating doing anything to FileMerge that makes it less useful
to you. I'm only saying it should be improved to the point where it's
more useful to others such as myself. It's very rare that I'll say
something shouldn't be improved because *I* don't need that
improvement myself. If you're happy with FileMerge, that's fine. But
really, if others are not, what value do you see in defending it in
its current form? The only thing that could possibly accomplish is to
send the message that it doesn't need improvement. Why do you want to
discourage the chance of improvements that could benefit other people?
I respect that it works well for you, and I'm sure for others too.
You in turn should understand and respect that it doesn't work
well for a lot of other people instead of telling people who don't
work the way you do that they're nitpicking. I see this as a big
part of the problem. The people with a Unix background love all
these Unixy tools and think anyone who doesn't is just a whiner or
doesn't deserve to be called a serious programmer instead of
recognizing and respecting that different people just work and
think differently.
I'm all for different ways of working. But I think this mailing
list would be much more useful as an exchange of ideas about how to
make Xcode work better. For example, you have expressed a
disinterest in using scripts to make FileMerge handle line endings
better. Because of that, I didn't bother hacking up a little script
to normalize line endings and feed the results into FileMerge.
True, that is a "Unixy" way of doing things.
My point was that we shouldn't need scripts to make something so
basic work. And my concern is that the more we're willing to do those
kinds of contortions to get the functionality we need the more we
tell Apple that we don't care if we don't have elegant, smart tools.
I'm not just interested in getting FileMerge to a point where it's
easy for *me* to use, I want it to be easy for virtually *everyone*
one to use. You, me, the college kid who's using it and doesn't know
a thing about writing Unixy scripts for it or how to get help from
this mailing list. You're obviously very bright and knowledgeable,
with a lot of programming experience and even you picked up some
ideas from this thread. What do you think it would be like using
FileMerge without all that experience or this list to help you? I
know you could figure it out, but do you want to spend your time
figuring out how to use tools or writing code you can sell? I can't
charge any more for my product just because I had to spend 3x hours
learning how to use the tools instead of the x hours it would have
taken me if they were more intuitive and easier to learn.
But at some point, you have to play the hand that fate deals you.
Fate isn't dealing this hand. Apple is, and there are always new
hands to be dealt. ;-)
All in all, I think the transition to Unix-based MacOS X has worked
out for every Mac user - including developers. With any
advancement, there is a price to be paid.
Where were you five and six years ago when developers were struggling
to develop for early versions of Mac OS X, a task which was orders of
magnitude more challenging that what's required today thanks to new
and improved documentation, more same code, fewer bugs in the OS, and
greatly enhanced functionality in the OS, most of which came from
filing the kinds of bug reports and enhancement requests you've
clearly stated you don't want to spend time filing. You just came to
this party, so in my book you haven't earned the right to tell those
of us who have been developing Mac software for over 10 years and Mac
OS X software for over five how great the transition has been.
That doesn't make either group inferior or less deserving of tools
that work well for them. That's why options are good.
Unfortunately, with the demise of CW a major option was taken off
the table.
CW was never an "option". 20 years ago people like Symantec and
even Borland sold Mac development tools. They didn't last long. CW
was the only real Mac development platform for 10 years. There were
very few MPW users. I'm a self-declared Unix geek and even I didn't
like MPW. Then Apple transitioned to MacOS X and CW was caught
between owners with an Albatross called Powerplant.
There was more to it than that. Mostly it got lost in the shuffle of
a company whose management changed and the new folks just didn't
really care about CW.
CW is gone - along with Macsbug and 27 restarts a day, whether you
need them or not.
I could get more done in Mac OS 9 restarting a 15 times a day (which
I didn't have to do) than I could in Mac OS X 10.1 because the latter
was so dog slow. At least I could go do something else for the two
minutes it took Mac OS 9 to reboot. In Mac OS X all I could do was
wait, wait and wait some more for this window to scroll or that
dialog to open. When I did a number of tests back then I found that
actions took 2-7 times as long in Mac OS X than they did in Mac OS 9.
I had one window that took a full three times as long to open in 10.2
as it did in 10.3, and 10.2 was faster than 10.1. Thirty minutes of
rebooting out of eight hours vs. eight hours to do fiver or six hours
worth of work. I would have gladly rebooted Mac OS X a few times a
day if it would have sped the darned thing up. LOL
All is not rosy for me either. I think it is just awful that
Hypercard died instead of Applescript.
I do miss HyperCard. :-(
Apple is going to continue to make improvements in their products.
They don't have infinite resources, so only the squeaky wheels are
going to get greased.
I'm not suggesting that the engineers aren't investing enough effort.
I believe Apple has failed to hire sufficient engineering to address
the issues. For example, Interface Builder, an essential tool for
which there is *no* alternative, had a laundry list of glaring bugs
and limitations in 10.3, and not one was fixed during the entire
lifetime of 10.3. In fact, there was a long period of time when there
was no one even working on IB. That's inexcusable to me.
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