On Oct 18, 2007, at 4:33 PM, Steve Checkoway wrote: On Oct 18, 2007, at 2:32 PM, Laurence Harris wrote:
That's fine, and yes, different people work differently. IMO it's better to have a command a significant number of people would use and the rest could ignore than make a lot of people write a script to do it. It's like having a Close All command in an application to close all windows. A lot of people might never use it, but a lot would, and the latter group shouldn't to write a script to do it.
Just because David Dunham and I wouldn't use this feature doesn't mean that only a few people would. Just because R. L. Grigg, Jim Wrenholt, and you would, doesn't mean that a significant number of people would.
Where are you getting this figure of "a significant number"? I searched the list archives and found one instance of someone else posting about this and when he found out about the breakpoints window, that was enough <http://lists.apple.com/archives/xcode-users/2004/Jul/msg00060.html>.
If it's really that important to your workflow, file a bug report. I'm not really sure what more can happen on list.
For the record:
• Seeded developers already know that there is a top-level menu item to enable/disable all breakpoints in Xcode 3.0. We find this more generally useful than the one-shot "delete all breakpoints" as it provides teh desired functionality (let me run flat-out without stopping) in a nondestructive manner.
• The semantics of "delete all breakpoints" are nontrivial because breakpoints are stored on a per-project basis (in the user file, no less) but the breakpoints window, while tied to the active project, shows breakpoints from all executables invoked by the frontmost project. This is a project model issue that needs to be dealt with in a future version.
• User customization is the correct way to implement top-level menu items that may be crucial to you but (when taken en masse) contribute to menu clutter and a confusing user experience for others. In Xcode 3.0 the ability to create user scripts quickly and easily has been greatly enhanced (for example, you can drag and drop a compiled AppleScript directly into the User Scripts editor dialog, rather than fuss with #!osascript lines), so this is a more viable solution to users who have idiomatic workflow needs.
Chris |