• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Xcode's Find in Project
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >What are your top desired improvements in Xcode ? (From: Rob Barris <email@hidden>)
 >Re: What are your top desired improvements in Xcode ? (From: "Oscar Stiffelman" <email@hidden>)
 >Re: What are your top desired improvements in Xcode ? (From: Laurence Harris <email@hidden>)
 >Re: What are your top desired improvements in Xcode ? (From: "Theodore H. Smith" <email@hidden>)
 >Re: What are your top desired improvements in Xcode ? (From: "Shawn Erickson" <email@hidden>)
 >Re: What are your top desired improvements in Xcode ? (From: "Theodore H. Smith" <email@hidden>)
 >Re: What are your top desired improvements in Xcode ? (From: Laurence Harris <email@hidden>)
 >Codewarrior RIP - was Re: What are your top desired improvements in Xcode ? (From: John Daniel <email@hidden>)
 >Re: Codewarrior RIP - was Re: What are your top desired improvements in Xcode ? (From: Laurence Harris <email@hidden>)
 >Xcode's Find in Project (From: John Daniel <email@hidden>)
 >Re: Xcode's Find in Project (From: Laurence Harris <email@hidden>)
 >Re: Xcode's Find in Project (From: John Daniel <email@hidden>)
 >Re: Xcode's Find in Project (From: Laurence Harris <email@hidden>)
 >Re: Xcode's Find in Project (From: John Daniel <email@hidden>)

  • Prev by Date: Re: Loading a private framework from a plug-in (Spotlight)
  • Next by Date: Re: source code libraries
  • Previous by thread: Re: Xcode's Find in Project
  • Next by thread: Re: What are your top desired improvements in Xcode ?
  • Index(es):
    • Date
    • Thread