You know what would be an awesome Xcode UI improvement? A Find feature that isn't completely broken.
Back in Xcode 3.0 (I think), Apple replaced the old single-file Find dialog (i.e. Cmd-F) with one of those newer style inline search bars (like what you see when you do an in-page search in Safari or Firefox).
Great in theory, and completely broken in practicality.
Setup: Create a UIViewController, go to the implementation file, scroll to the bottom, insert your cursor.
- Wrap-around search only works intermittently: Search for initWithNibName. It will tell you at least one match exists, but it won't show it. Hit Cmd-G to try to make it wrap around. It might work, it might not. Who knows?! Weirdly, I found just now that if I switch over to the header file (by pressing Cmd-Option-Up Arrow) and then switch back that wrap-around search magically starts working.
- Case-insensitive search only works intermittently: search for initwithnibname. It will, most likely, tell you that no matches were found.
- Single-file find and replace requires me to take my hands off the keyboard. It is not possible (at least by default) to enable single-file find and replace without moving the mouse cursor to the drop down on the left side of the Find 'strip' and choosing Find & Replace from the menu.
Really, Apple just needs to release their plugin documentation - and some of these problems could actually be fixed by developers who have to fight them every day.
FWIW, If you use the key commands, the first and third issues are avoidable -- though, I have run into all of the issues when using the mouse.
There's a key combo for that opening the find and replace menu; ctrl + cmd + c. Then you can tab through. Hitting enter will "replace and find next", shift + enter will "replace and find previous."
By default, there aren't any explicit key combinations for specifically replacing the selected text / replace all / replace and find {next, previous}. But, you can set them in Xcode's preferences, under the Key Bindings tab (in the Edit -> Find subtree). I hijacked cmd + r (from "run") for "replace and find", shift + cmd + r is used for "replace all".
The find feature in Textmate is the same way. I'm not sure how that became prevalent. It's really difficult to notice if you are new to an application.
Microsoft did a usability study on a similar grouping of APIs by usage in Visual Studio. The end result was it was harder to find what you are looking for than using the alphabetical ordering. The lesson for API designers: group related methods by prefix so they can be predictably found in code-complete popups.
Prefixing methods is ugly. Methods should be named after what they do.
Squeak (not sure about other Smalltalks) has a thing called protocols: a method belongs to a given protocol and the browser shows it to help you explore your classes. Depending on the method name, the browser can suggest a protocol to file it within. A "sort by protocol" could then be useful in this scenario - provided you had some way to tell the IDE where your method should be grouped.
The only thing I disagree with is the visual dropdown for enums (e.g., the modalPresentationStyle). At the end of the day we're still writing code - I feel like instead of English-equivalent descriptors like "Full Screen", "Page Sheet", etc, it needs to labeled with the actual programmatic name. This way the UI is a transparent, helpful supplement to code, not an opaque interface.
This way when I type:
viewController.modalPresentationStyle =
it will pop up the list of possible values, along with visual aids, but I can just keep typing the value I want and tab-complete it. This keeps workflow smooth and prevents me from having to exercise the mouse, and keeps me focused on the code I'm writing rather than creating something that's more of a wizard.
The imageNamed example is a good one: it displays the string you'd use under each icon, and hopefully the search narrows as I begin to type the image name. Quick workflow-easing popups should not require users to interact with them.
You misunderstand what I mean - personally I find it impossible to remember the crazy number of enums that iPhone programming foists upon you, so the popup of options is greatly welcome.
The thing I don't like about that is that instead of displaying the name of the enum, it displays a human-friendly name. I love the menu, but I'd rather not move my mouse to select one of the options, nor move my hands to the arrow keys to navigate it. It'd be great for the popup menu to provide the actual programmatic name (along with the awesome visual aid of what the enum actually means) so I can just start typing the first few characters of what I want, hit TAB, and complete it.
Similarly, if I want to include an image, the popup with the image previews is awesome, but I'd rather not have to move my mouse to scroll through it and pick it out. Odds are I have some notion of what the name begins with.
You could solve this easily by only activating it after a period of inactivity. Stop typing for a second, and the suggestion box pops up.
Xcode has a preference (well, two) that help out with autocorrection. I heard about it at last WWDC, and can definitely see the tip being mentioned again at the next one (that is, if you're going to WWDC and go to the Xcode presentation). I believe the key I changed/added after the presentation is:
that may be related. Basically, it lets me hit enter to autocomplete methods/functions/classes/etc right away and only showing whats actually available to the class.
If those aren't it -- and someone wants -- I'll skim/rewatch the Xcode presentation from last year and look it up.
And built into every Cocoa app: Hit escape while typing and it will show you a list of available completions. In Xcode, this ends up being potential classes and methods available from the framework.
I didn't think that Xcode had an API that would allow this. To my knowledge the only thing the API allows is adding differ end ways to build things. For example, adding fortran support natively. I could be wrong though.
I agree this is the way that the code autocompletion should be though.
An absolute tour-de-force article, which I've skimmed and plan to go back an re-read.
One point though, successive versions of XCode help have got slower and slooowwwwer. The current 'public' release is wretched compared to even a couple years ago.
This is reminiscent of what happened to Visual Studio / Visual C++, in that Visual C++ 4.2 (?) had a fantastic super-speedy help, which basically slowed down to a crawl in later versions, and lost its 'tight' feel.
Even if nothing else in XCode got fixed, speeding up the documentation would be a big step forward.
XCode is an awesome IDE, way better than Eclipse, and nicer than Visual Studio+Visual Assist, which was a surprisingly strong combo.
But, it keeps getting crippled by its need to do fancy UI stuff to impress Steve. Wheee, pretty iChat bubbles for errors! A find using standard Apple conventions! A per-edit file history!
In theory these would be fine, if a bit irrelevant to my daily coding, but inevitably the execution breaks something important that used to work. The find problems are documented elsewhere in this thread, but my personal bug-bear is the file history. You used to be able to cycle back and forth through the files you'd opened in a window, which was an awesome way of building up a working set without having to think. Now if you make an edit, all of your 'forward' history is lost. See the comments here for others bitten by that:
It's not that the XCode team aren't aware of these bugs, all of Apple's internal developers use it and give feedback, but their priorities seem to be driven by demo-ability not usability.
I disagree entirely. There's a lot of things it does poorly - from managing the list of files in the project (why can't I have it just choose a directory?), it's half-baked implementation of Open Quickly, and it's bad find UI.
But all of this wouldn't be an issue if XCode was easily extendable with plugins. And this is where Eclipse and Visual Studio wins out - you can download plugins to do almost anything you need, and to customize it exactly the way you want it. This is the most glaring omission from XCode, and it's really long past due.
I am annoyed by the error bubbles too because they truncate the actual error message - you have to open a whole new window just to see the entire message. In Eclipse, you get a red (X) in the sidebar on which you can click (and a list of problems) so you never have to fight any extraneous windows just to see your error in context.
In my opinion, Eclipse is way better than XCode (not to mention more versatile), and Eclipse's code assist (or whatever they call it) is far superior to XCode's precisely for the reason outlined in this article.
Maybe it's because I'm relatively new to OS X but I find Visual Studio and its single-window interface vastly more efficient and usable than Xcode+IB and it's plethora of open windows.
Have you tried the "All-in-one" layout in Xcode? (Look in the "General" preferences section.) I find it a lot more usable than the default lots-of-windows setting, especially if you have more than one project open.
Back in Xcode 3.0 (I think), Apple replaced the old single-file Find dialog (i.e. Cmd-F) with one of those newer style inline search bars (like what you see when you do an in-page search in Safari or Firefox).
Great in theory, and completely broken in practicality.
Setup: Create a UIViewController, go to the implementation file, scroll to the bottom, insert your cursor.
- Wrap-around search only works intermittently: Search for initWithNibName. It will tell you at least one match exists, but it won't show it. Hit Cmd-G to try to make it wrap around. It might work, it might not. Who knows?! Weirdly, I found just now that if I switch over to the header file (by pressing Cmd-Option-Up Arrow) and then switch back that wrap-around search magically starts working.
- Case-insensitive search only works intermittently: search for initwithnibname. It will, most likely, tell you that no matches were found.
- Single-file find and replace requires me to take my hands off the keyboard. It is not possible (at least by default) to enable single-file find and replace without moving the mouse cursor to the drop down on the left side of the Find 'strip' and choosing Find & Replace from the menu.