Good afternoon. So today you have two sessions on increasing your productivity with Xcode. And many speakers on stage today are going to be telling you how you can increase your workflow in the edit, build, debug cycle with workspaces, documentation, scripting, et cetera. Each of them are going to refer time and again to a certain core set of elements within Xcode.

So I thought it would be a good idea to review those elements now, tell you what they're all about, what their purpose is, and talk about a few tips and tricks that you can use to make better use of them. Now, of course, Xcode wouldn't be a very good developer tool if it didn't have an editor. Xcode has a great editor. It's faster now than it's ever been before.

And you can take better advantage of it by turning on various visual elements. For example, I like to turn on the gutter and the split control. You can turn on the gutter via the View menu and turn on the split control via General Preferences. And the split control will allow you to split the editor any number of times and close different splits, et cetera, if you like to view different parts of your file at the same time.

And the gutter will show various line-level attributes-- of course, the line number that it's for-- as well as errors and warnings, breakpoints, all that kind of good stuff. Now, the separate editor window in Xcode in the upper right-hand corner, by default, has a toolbar item called the editing mode.

Now, I know a lot of you out there like to use a separate editor window for every single file you open up. That's a CodeWare style, and I can appreciate that, too. I like that mode a lot also. But sometimes that becomes too much. You hit periods where you want all the files to just be in fewer windows.

And so you can toggle the editing mode button on. And when you do that, all files that you double-click on are going to open in that same editor window, and you'll use the nav bar in the editor to navigate between them. And of course, you can just toggle that off again, and everything goes back to the way it was, and everything opens up in a separate editor window.

Xcode's separate editor window, like all of Xcode's windows, has a status bar. And the status bar and the seeds that you have for 1.5 and 2.0 today focus mainly on build information. And you'll find out a little bit later where other types of status information go. We have a really good solution for that as well. Now, when you build, you're going to see a lot of different places that will tell you what's happened in your build.

In the right-hand side of status bars is a dedicated area with build buttons that will tell you whether a build succeeded, failed, or was canceled by you, as well as possibly buttons for any errors or warnings that have been encountered when the build was performed. Now, you can click on those, and it will take you to the build pane, and we'll see that in a minute too.

Now, if you have any errors or warnings in the file that you're editing, you're going to see some other things that are really handy. In the gutter, you're going to see little items. You're going to see little icons on the lines that refer to errors and warnings for that particular line in your source file. And they'll have a badge for an error or a warning. If you click on those, the status bar will show you the actual build message for that.

And if you hover over them with your mouse, you'll get a tooltip. I use the hover mode a lot when a build is ongoing, and you're getting a lot of compilation messages going through, and maybe it hasn't stopped because it's just hit some warnings, but you see that pop up so you can hover your mouse over and say, oh, I see this warning is about that. Now, you'll also see in the latest release of Xcode little hash marks in your vertical scroll bar.

And we've actually had radars reported that there's a drawing glitch in the scroll bar, but what that actually is is it's indicating lines that have errors or warnings. This is like the file merge app that we have on our system, so that you can just scroll the thumb down to those hash marks and get immediately to your errors and warnings, and if you're porting any code or anything, you have a header macro defined incorrectly in a header, you'll know that right away because all of a sudden you'll just see red throughout your scroll bar, and you know something is really amuck there.

Now, another very important element of Xcode is the groups and files view. Now, all developer tools seem to have a view like this. It's a hierarchical view with your files and your folders and your groups, and Xcode has that as well. But last year, we took a step further, and you've heard a lot about smart groups this week. And last year, we built smart groups into Xcode's groups and files view.

Smart groups for Xcode are auto-generated content based on particular topics. So, for example, we have an errors and warnings smart group, and this smart group is populated with all the files that Xcode is aware of that have errors and warnings against them. We also have a couple of other important smart groups. For example, we have a target smart group that contains all your targets and one for executables that contains all your targets. It contains all your executables. Those will be important for you to find which targets you want to inspect and change settings on, etc.

Now, new in the seed is the ability to decide which smart groups you want to show. And you'll see later on that in the newest seeds, the groups and files view is present in many different windows. And they'll have different subsets of all the smart groups available. So, if you bring up a context menu on the project structure in the groups and files view, you'll be able to select which smart groups you want to show in the groups and files view.

And of course, I should mention that there's another type of smart group, which is a custom one that you can create. It's just based on regular expressions right now, filtering on the file name of the files in your project. But it's very handy if you want to have a folder that contains all your resources, all your nibs, all your images, your source files, your header files.

It's easy for you to create those. And again, the groups and files view is a very useful tool. The groups and files view supports type select, so you can navigate through the groups and files. Now, another view that we introduced with Xcode last year is the detail view.

It works hand in hand with the groups and files view, and as its name suggests, it provides more detail about the files you have selected in your groups and files view. Now, each smart group has a different type of detail view. One of the really important detail views -- I get this question a lot -- is it has to do with setting your headers to be public or private.

You do that by clicking on a target in your groups and files view. The target detail view will appear, and you'll see a column that's called roles. And if you select a header file in that and then select that roles pop-up, it will allow you to choose whether you want the header to be exported as public or private.

The detail view also supports filtering. So there's a search field in the Windows toolbar, and you can filter on the detail view. You can bring up a context menu on the header of the detail view and display different columns. Of course, you can sort the columns. And new in the seeds, the detail view supports all the file operations that the groups and files view does. It also supports type select.

So you can sort a column, then you can filter it down, and then you can type select to the end. When you get to where you want to be, you can hit the return key, and that would, for example, in the default layout, it would load the file in the embedded editor. Option return will load it in a separate window. That's just how the groups and files view works as well.

Now, eventually in a software development tool like Xcode, you hope to build. So we have the build results pane. Now, normally, if you're like me, after you're familiar with all the steps that your product uses to build, you probably don't need to see them all laid out as you're building. All you need to do is know that an error warning has happened or the build failed for some of the reason.

And the elements that I spoke of earlier will give you enough information to find out. But if you do want to know the build steps that were taken and the order in which they happened, the order in which errors or warnings were admitted, go to the build results pane.

And it has controls to filter that information to collapse away the build steps or hide or show the warnings. And finally, if you're wondering, well, you know, I set this build flag, and I'm not getting results that reflect that flag. Let me check the raw build log and the build results.

So let's say you're looking at the build pane, which is the middle pane. You have your outline view on the top, raw build log, and then an attached editor. Let me check the raw build log to see the exact flags that were passed to the compiler to compile a certain file. So that's really handy. And of course, as I mentioned, in the latest seeds, wherever you find a build pane, you will find an attached editor so that you can go through your errors and warnings in line and fix them.

Now, if you need to search across a project or across frameworks, across a subset of files, you can use the batch find mechanism in Xcode. And there are powerful options that you can use to adjust your query and adjust your search and replace. And you can bring that up, and you can do things like specify find sets.

Let's say you work on a large project, but what you're responsible for is really a smaller set. Or maybe sometimes you want to find tags that are only in XML files. And other times, in other types of files. You can create different find sets and use those at your discretion when you're searching.

Now, possibly one of the most important views in Xcode is the inspector, and that's becoming more and more important. You go to the inspector to view or edit any fine-grained project-level settings. For example, if I wanted to change code set settings, I would inspect the project, which is at the very top node in the Groups and Files view. If I wanted to add an argument to the executable when it's launched, I would inspect an executable.

Now, new in the SEEDS is the ability to do multiple selection, and this is a great time-saver. Because let's say you wanted 10 different files to be compiled with a particular build flag. You just select those 10 files in the Groups and Files view or the Detail view, and you bring up an inspector, and you go to the build setting, and you apply it there, and it's applied for them all across the board. And that's just really great.

Big time-saver. In addition, an inspector has a search field at the bottom. If you have all of the files that you want to compile, you can do that by selecting the files in the group and the files in the group. And that's really great. Steve Lewallen, Dave Ewing, Matt Morse Now, possibly one of the most important views in Xcode is the ability to do multiple selection. So if you have all of the options showing in an inspector for build settings or something, it can be quite a few.

So you can whittle that down. You don't really even need to know all the settings. You can take some guesses and explore the options and just type in the search field, and it will narrow down. If you know what you're looking for, you can actually now click in the table of the inspector and, again, use Type Select just like you can in the Detail view and the Groups and Files view. And it will bring you down right to that option.

Now, you initiate many activities in Xcode. You ask it to build, you ask it to debug, run an executable, do a batch find, et cetera. When you do that, you're going to see something called the Tasks button get enabled. And in the lower right-hand corner, it's going to be badged with the type of task it's doing. It might have a build hammer if you're building, a little spyglass if you're doing a batch find, et cetera.

And if you just want to stop the last task that you initiated for that project, you can just click that button like it was a regular toolbar item and the task will stop. If you're running more than one task and you want to pick and choose which one you want to stop, then click and hold on the task button, the task list will pop down, and you can choose which task you want to stop.

Now, as I said earlier, we have a step ahead now in Xcode as far as status goes. And that's because we have an activity viewer now that spans all projects that you have open. It shows all tasks that are running. That includes also tasks that Xcode is performing on your behalf, but that perhaps you didn't directly initiate yourselves. For example, the project may be re-indexing or it may be performing an SCM operation. You'll see all of those in line. You'll see the Xcode and the Xcode. You'll see their progress.

And you'll also see different status messages. If it's building, you'll see which file it's building or which target it's building. If it's doing a batch find, you'll see how many batch find, you know, hits it's actually received so far, et cetera. And you can stop tasks directly from this activity viewer. And when you close a project, you'll just see that project disappear from the activity viewer. You reopen it, it reappears.

Again, that's project wide if you want to see all your tasks for all projects. Now, Xcode has a lot of preferences. And I want-- I don't dare try to go into all of them here. I'm sure I don't even know a quarter of them myself. But there's a small set that's very powerful as far as your workflow goes.

So let's look at these now. One of them is ability to save and restore your window states. You're working a project, you know, it's time to go home for dinner. You close it. You go home. After dinner, you know, you reopen your project. And you want all the windows to be right where you left them.

Everything in the right order, et cetera. If you select these general save and restore state settings for your workspace, that's going to happen for you. And new in the seats that you have from 1.5 and 2.0 is the ability to save and restore separate editor window state as well.

So that's a big time saver. Now, another thing that you can do if you use the embedded editor a lot-- I use that a lot-- you can select the auto open option. And if you do that, then if there's-- if there's an embedded editor in the window that you're selecting something else in, it's going to automatically pop open for you.

You don't have to drag it open or double click it open yourself. So I like to set that setting. In addition, we saw in the talk about the editor, the split controls that you can turn on. Now, you can turn these on globally for all open projects, for your groups and files view, as well as your separate editor window.

and New in the Seeds is the ability to split these items more than one time and to close whichever one you want to close. And finally, we've added a couple more workspaces to Xcode, and there's a control to select that workspace, and we'll go over that in just a few minutes.

Now, also new in the seeds that you have in 1.5 and 2.0 is the ability to set defaults. Now, out of the box, we have certain sets of window positioning and sizing for all the different windows in Xcode. But we're all different here, and we all like it a different way.

So you can position your windows the way you want them, and then go up to the Window menu, pick the defaults menu item, and say to Xcode, all of my windows, I want you to use this for any other projects I open new. In addition, once you've done that once, you'll see another button on that dialog that says restore to user defaults.

That's the setting you just set. So you can go back to previously opened projects and restore to that setting. Let's say you move things around, and you're like, OK, I want to get back to my best setting. You can do that. You can also restore to factory settings.

Also, for your separate editor windows, you can choose what size, status bar visibility, et cetera, for the separate editor windows by doing the same thing. You have a separate editor window open, and you just go up to Window, Defaults, and make that your default for the separate editor windows.

Now, as I mentioned, we have two new workspaces in Xcode 2.0. We still have the default workspace that we came up with and introduced in 1.0, plus many workflow refinements and a few pixel refinements, but pretty much the same thing in 1.5. But in 2.0, we have two additional ones.

Now, we all work differently, and we also work in different situations. We may prefer to work one way, but because we find ourselves having to deal with 10 projects at some point, or a very small screen, or we're lucky enough to have a 30-inch screen, you may want to use Xcode differently.

You now have these three workspaces in Xcode 2.0 to choose from. In addition, All of these have exactly the same functionality. If you learn, for example, the keystrokes in one, you could close your eyes, switch workspaces, close your eyes, and do the same keystrokes. The same exact thing would happen. It would just happen appropriately for whichever workspace you have. So, as I said, Xcode 1.2++ is the default workspace. And this was always focused on providing a separate window for each task you were performing.

You were building, you were looking at the run log, you were editing, you were debugging, you were editing the project, the targets, executables, etc. And in its project window, it had a groups of files view on the left, a detail view on the right, and an embedded editor.

Now, one of the new workspaces is the all-in-one workspace. And this is designed to reduce window clutter. Again, if you're in that situation where you have 10 projects open, if you were using the default workspace, you would have quite a few windows open. That would be very difficult to manage. You also may simply prefer to have the all-in-one form factor. Most tools out there have all-in-one. Project Builder had all-in-one. So definitely there's an audience for that, and you have that option now.

Now, the all-in-one workspace separates groups of core views, those core elements we went over earlier, into pages. Pages are based on tasks. So you have a project editing page. You have a building and running page, and you have a debugging page. There's a page control in the upper left-hand corner of the toolbar to navigate between them. But if I'm on, say, the project editing page, and I want to see the build pane, I do the same thing I always did. Shift-Command-B, and the build pane will come forward, just like the build pane will come forward in the default workspace.

And lastly, each page in the all-in-one workspace has a custom toolbar, and you can refine it further. So the debug page has all the debug buttons, obviously, as you'd expect, for example. And lastly, we have the condensed workspace, and this really caters to those coming from Codeware, for example. It's basically the same as the default workspace, but the project window is broken into two pieces.

You have the main project window with three tabs: your files tab, your targets and executables tabs, and a tab with other smart groups. And then you have a detail window with your detail view and another groups and files view. And earlier, when I mentioned that you could hide and show different smart groups in your groups and files view, that's really handy in the condensed workspace, because you have those three tabs, so you can arrange things the way you'd like them. And now I just want to take you on a little drive around the three workspaces, show you a few things, and then I'll sum up and I'll hand it over to the next speaker.

So when you open a project, it's going to look basically like this when you first get Xcode 1.5 or 2.0. In the lower right, I have the activity window that I was speaking of earlier. And if I would do something like build, it would show build status, et cetera.

Now, I have my groups of files view on the left, the detail view on the right, and an embedded editor in the lower right-hand corner. I can view different files there. We have a classic splitter now, and you can double-click on those like you can in Mail to collapse them to the left or downward.

and you can re-expand them. And we've changed a bit, for those who are already used to this UI, the behavior of the editing toolbar button. Because previously it behaved like our splitters behave now. And we found that most of the people who were using that, they were thinking to themselves, I want to focus on the editor.

So now when you click on the editor toolbar item, it will fully expand the editor or bring it back to its previous state. Very subtle difference, but for those who use it, I'm sure you'll find it's a worthy addition to the UI. Now let's say, for example, that you did have it fully expanded and you wanted to use a new feature, a new keystroke, and workflow behavior that's a favorite of mine in 1.5 and 2.0. You wanted to go directly to the detail view and start searching.

Instead of dragging the splitter down, then clicking the search field and all those things, now you can-- by default, you just do Command-Option-F. It will expose the detail view, however it was hidden, put your cursor in the search field, and you're ready to go. So that is a bit about the default workspace. And now I want to go and take a look at some of the others.

Let me close this workspace. To switch workspaces, you need to close any open projects. And I'll go to Preferences, and I'll select the All-in-One workspace. And then I'll just reopen my project. And this is the all-in-one workspace. It looks very similar, especially at a distance. But you'll notice a couple of different things. First of all, there's the page control in the upper left-hand corner. And the detail view is being replaced with a tab that has the detail view, project find, and as well, an SEM pane. Then you have the embedded editor, of course.

Now, all of the tab views in 1.5 and 2.0 now for the project window-- are drag and drop aware. So if I wanted to drag an item from one page to another, I can just drag it over those pages and it will automatically switch to wherever I'm dragging. You'll see how that's used even more benefit in the condensed workspace. So let's take a quick look at that now. Let's close our project again. Go right to the condensed project workspace.

Select that. Open our project back up. Here we see it by default opens in the far right corner. It has the three tab views. And as I said, it's basically the same as the default workspace. But let's say, for example, that I wanted to add a file in my project tree to a particular build phase of a particular target.

I'm in the Files tab right now, so I can select a file. And I would go over the Targets tab. Then I would go under Targets and go under a particular target that I had opened. And then I would go under Build Phase and I would just drop it into that build phase.

So it's very, very easy to use. And of course, as I said before, let's say, for example, that under Files I also wanted to have a different smart group showing. I don't know. Let's say I wanted to have my bookmark showing. So I could show that smart group as well. you can do that anywhere you find a Groups and Files view.

And let me just open up one more project here. As you can see, this is a freshly opened project, so it's indexing, and I'm building and running. So you see the status of the two different projects, and you can collapse them, etc. So with that, let me go back to the slides.

And if you could, I'd like you to remember three things. Actually, a fourth thing that I thought of earlier today, and it's not on the slide. But the first three things are when you get, especially Xcode 2.0 on your Tiger CD, take a look at the different workspaces. Because each one fits our personalities a little differently, and it can really boost your productivity if you pick the right one.

And next, don't forget those workflow preferences that we talked about. They're on the General Preferences pane, and they'll really add to your workflow. And third, you might want to define your own window defaults that fit your needs a little better. And then fourth, that fourth thing that's not on here, it's again the question I get asked the most, which is how do I export my headers public or private? Remember, you click on a target, you see the target detail view, and you use the role column in the target detail view to change your headers to be public or private. So with that, I'm going to turn it over to Dave Ewing, who's going to talk about CodeSense and source code managing. Thanks, Dave. Thanks, Steve.

Well, Steve's been talking to you a lot about getting around Xcode. I'm going to talk about how you get around in your code in Xcode. So Xcode has a number of technologies in it, and together we like to call that code sense. So it's basically symbolic assistance for your project. We parse and index your source code, and then with that information, we can help you move around and give you assistance in your project. So we have a number of features within Xcode for this.

We have a project symbol smart group. You saw smart groups a little bit. I'll show you a little bit more of that in a few minutes. We have a standard class browser. There's a number of navigation techniques you can use inside of an editor. And finally, we'll talk some about code completion.

So first, the project symbols smart group. As I said, it's a smart group. It's sitting in the bottom of the Groups and Files tree over there. When you click on that, you show all the items that are defined in your project, all the symbols in your project. And like any other smart group, you can filter the details. So you can filter by the name of the symbol, the type of the symbol, or the source file in which the symbol is defined.

And of course, we have a class browser. On the left-hand side is showing a hierarchy of classes, and above the editor pane, there's a list of the methods and fields for the selected class. In the class list, you can either show that hierarchically or just show a straight flat list of all the classes in the project.

And of course, you can show just the project classes or the project classes in any framework classes that you've imported in your project. And for classes that are defined like in Cocoa, where we have documentation on the system, you have quick access to that documentation right in the class browser.

Okay, in the text editor of Xcode, there's a navigation bar at the top of every editor pane that gives you access to functions within that file. You can actually switch back and forth between files if you're editing multiple files in the same pane, too. There's a counterparts button that takes you between a source file and a header file that match by name, of course.

There's also a pop-up list of imported files or included files. And there's two other pop-up lists for breakpoints in the current file or bookmarks that are in the current file. And then two of the best ways to get around in your code are command double-click, which when you command double-click on a word in your file, will do a lookup in our index and take you directly to the definition of what you clicked on. Or, if there's multiple definitions, it will give you a pop-up list and allow you to choose which one you want to go to. And finally, there's also Option Double Click, which will do a documentation search for that symbol.

So code completion. We have all this information about your project, and when you're editing your code, sometimes it would be really nice if we just helped you enter the text that you're trying to type. Well, that's what code completion does for you. It's context sensitive, so it knows what method you're in. It knows what's available to you at that point.

You can set a number of preferences for how it works. You can have it set up to automatically suggest what it thinks you want to type in, or you can have it brought up only on demand by hitting a command key. Actually, option escape is the default key for that. When it inserts text, if it's a method or function call, it can insert argument placeholders for the arguments to that method.

And when you bring up a list, you can actually have the list narrowed down to only those items that match what you've typed so far. I find that very convenient myself. A number of implementations of code completion on other systems actually always give you this big, huge list.

While it takes you to the one that matches closest, there's still a huge number of things there, and it's sometimes hard to find your way around. So in the seeds that you guys have, the 1.5 and 2.0 seeds, you'll find that code completion's a bit faster. It's a bit smarter. It has a better idea of where it really is and gives you a better list of suggestions. And of course, we now have some support for Java. With that, I'm going to give you a demo of CodeSense here.

Let's go ahead and switch over to my user. And again, we have a parent sample. The first thing I want to show you is the Project Symbol Smart Group. And that's down at the bottom. So we click on that and we can see that we have quite a few symbols in this project. Clicking on them takes you directly to the code. And you can search. Let's search by the symbol name and just type about. So let's see.

So one thing you'll notice for you C++ developers that have used Xcode in the past, it's actually showing the constructors and destructors for the C++ code, which is a nice change for you. Okay, next I'd like to bring up the class browser here under the project menu. I'm going to go ahead and option click on these to show the full hierarchy. This is also another nice thing that's changed in this version. Of course, C++ support, we didn't always get it right here. Here you'll see the actual full hierarchy of the classes in this example. So that's a nice change for you all.

So we can click around and it takes you right to the declarations of the symbols. If we click on methods up here, it takes you to those declarations. One thing that's important to know is if you option click on these items, it takes you to the definition of those symbols. So that's something that's kind of hidden and people have a hard time finding it first.

Finally, I mentioned before that you can

All right, so I also wanna show you how to configure some of the options here. There's quite a few options. So I'll bring that panel up. So the options here in this list are just four different option sets that we provide for you.

You can add new option sets, and you can actually change the option sets that are here. So one thing that might confuse you, so don't do this, is click on the flat list here, and it's still named hierarchy all lists. Now that'll confuse you because it won't do what you expect. If you want to show a new group of options, let's go ahead and add a new one. And we'll just call it My New Option Set.

And let's go ahead and turn on showing of inherited members, and I'm also going to show method and data, so the methods and fields for this class. Up here in the top methods list, you'll see that some of these, I'm not sure how well that shows up, but that's shown in gray there. That means those members are inherited from a superclass. And down at the bottom of the list, you'll see that fields show up, and in fact, the fields for superclasses also show up there.

Okay, well let's go ahead and look just at a editor window and show some of the features in the editor window itself. So at the top of the window here, this is called the navigation bar across the top of the editor. This is available in any editor wherever you are inside Xcode. The first two buttons on the left here are the left and right buttons for your history.

If you've edited more than one file in the same view, you can click those buttons to move back and forth. The next button is a pop-up that shows you all the files that you've edited in that view. Here when you're in a separate editor, you'll normally only have one file there.

The next thing is what we call the function pop-up, and it lists all the functions, methods. Actually, it can show all sorts of things: macro definitions, declarations, pragma marks, warnings, you know, pound warnings, those sorts of things. Next over here on the right, there's a bookmarks menu. So you can set a bookmark. Let's see. Find, add to bookmarks. And it just goes ahead and adds it there. So you now have a quick bookmarks list. It can also have a breakpoint. So if we go and set some breakpoints in here, we now have a pop-up that shows the breakpoints.

This next button is called the Counterparts button. Now the Counterparts button normally switches you between your header file and your source file. I'll go ahead and do that. And it takes you right to the header file. So that's pretty nice. That's convenient. But you know, sometimes you want to focus in on something in particular. So I'm here in the header file, and if I put my cursor on the declaration for the run modal method, if I option click on this button, it'll go right to that definition for that. And the same goes the other direction, of course.

If we option click, we'll go right back. Oh, actually that one we didn't go right back to. Well, anyhow, we also have an imports pop-up menu, and you can go to any of the imported files for a file. When you're inside of a header file, it not only shows you your current file and the files it imports, it also shows all the files that import it, which looks like pretty much every file in this project. Since that's the prefix file, that makes a lot of sense.

Okay, the last thing I want to show you here is something that's somewhat hidden. If you look into your key bindings preferences in Xcode, you may have run into this. But it turns out that you can get access to all the menus in the file navigator right from the keyboard. And by default, we bind Control-2 to go to the function pop-up menu, and then you can just use the keys to move around there. So you don't ever have to use the mouse to move between methods there.

Control-3, I think, is bound to the... imports pop-up. And four and five are bound to the bookmarks and breakpoints pop-ups too. Okay, last but not least here, I want to give you a quick show of code completion here. If we go ahead and enter in some new text.

Let's see. So, here I've typed in quit A, and it's underlined what's there. The underline indicates that it knows that there's more, that there's an ambiguous completion, so there's more than one item that it can complete to. The two letters app show that it knows that everything that starts with quit A also has quit app in it. You can hit option escape to complete that. At this point, you can also hit it again bring up the list of all the possible completions.

So let's go ahead and select the lower item there and hit tab to continue it. So we inserted an argument placeholder here. This shows you that this method takes one argument, which is a window ref type. No surprise since it's on the line above too. Now there's a couple of ways you can go to the arguments. The common way is control slash will actually take you to the next argument placeholder. So if you've inserted a method with multiple arguments, type something in, then just hit control slash. It'll go to the next argument and let you type that one to fill that in.

Another thing you can do, you can also double click on the angle brackets and it'll select all that text for you. So let's go ahead and insert the rest of it. Get Window Ref. And this has a number of items here. Well, let's keep typing. And insert it.

So there you go, code completion. I want to show you a little bit about the code completion prefs. There's a number of options you can configure for code completion. You can set them in the preferences for all of your projects, or you can set them on a per project basis by selecting the first item in the groups and file list, the top item, the project icon, and doing get info on that.

Or you can double click on that icon actually to bring up the same panel. But here I have it set to automatically suggest a matching item. So that's the part that does the underline. If you have this next option set, it'll always bring up a list. Rather than doing the underline, it'll bring up a list there. This is similar to how it works in Visual Studio, a number of other applications you may have experienced code completion in.

And finally, at the bottom, you can either insert just the simple name of what you've been typing, or for methods, it'll actually insert the placeholders. Over here on the right, you can see the code completion prefs. Over here on the right is some configuration of the function pop-up. So I actually like to hide most of the stuff. This isn't how my machine would normally be set up.

But often when you're in a header file, you end up having these huge, huge lists, and I just don't find that quite so useful. Okay, last thing I'm going to show you, I'm going to mention here. We've sped up indexing quite a bit. I mean, in the Java case, indexing the system JDK class files is about ten times faster than it used to be.

But sometimes that's just not fast enough. And it does seem silly that we always index the system header files every time you open a project, a new project, that is. So there's something called index templates, and I'm going to just bring up a finder window here. Inside, The developer extras Xcode index templates directory. You'll find a readme file. Now, this readme file basically just tells you what they are and tells you how to run the one command that it takes to set them up.

So index templates make it so that there's files sitting on the machine with precooked indexes of all the system header files, so you don't ever have to index those again. If you rebuild your index, those are still there. Okay, with that, I want to pass it off to... Oh, good point. Hey, I'm getting too anxious.

I do want to go back to the slides. I have a little bit more to talk about. Just having too much fun. Source code management. Okay, so we've talked about moving around in Xcode. We've talked about moving around in your code in Xcode. Well, there's also a lot of history to your code. Hopefully, you're using a source code management system. And we provide... Full integration of source code management within Xcode. So all the capabilities that you need on your daily basis are here.

We have columns in the files, or the groups and files list. We have a smart group that shows you all of the status for any files that are different from the repository. We have another window, a source code management window, that shows you that same information, but if you want to have it in a separate window, you can put it there.

And we have inspectors, so when you inspect individual files in your project, you can look at all the revision history from within that window. It's also easy to do comparisons between revisions, do a quick diff. At Apple, we like to put diffs in our bug reports when we fix a bug, so that's a convenient way to do that.

So as I said, we support your daily workflow within Xcode. You can add and remove files from the repository. You can update to the last version that's in the repository if somebody's made a change and you want to get that version, or you can commit your revisions. We can compare and diff versions. And we can also view annotations. So an annotation is a view of the source file with every line containing the revision number and the user who made those changes. A lot of times people call that viewing the blame version of the source code.

And right now we support the three most requested SEM systems, CVS, which is something we use extensively throughout Apple, Perforce, which was requested highly from all of you folks, and Subversion, which is a new open source revision control system that's really gaining a lot of popularity. Okay, now I've got one more little demo for you.

So the first thing I want to do, we have a project here. This is just a parent sample. And the first thing I want to do is bring up the project info for this project. Let's go ahead and switch over to the general preference pane. At the bottom, you'll notice that there's an enable SCM checkbox. You can turn that on to enable source code management for that file, for that project. And you can switch between the different versions. Make sure you pick the right version, of course.

And the last thing, especially if you're set up to use Subversion, Subversion can actually be installed in a number of places on your system. So I used Fink to install it, and Fink likes to put everything inside of slash SW. So my version of Subversion is living in SW bin SVN.

So, right now you don't see any source code management, but I want to see some, so I'm going to control click on the title of that view, and you'll see that we have, we've modified the project since last time it was checked out. That's no surprise, I've been doing stuff up here on the screen.

We have about windows. You can see the icon there is gray. That means that it's changed. If I go ahead and save that, you'll see that the status updates right away. So, the M means that it's modified relative to the repository, so there's some local change here. If you have a file that's not checked in yet, and you've said that you want to add it, it'll show an A there. If you've made local changes and there's changes in the repository, it'll show C for conflict. And it'll show a U if you need to update it, I believe.

Okay, so we also have an SEM smart group. Let's go ahead down there and take a quick look at that. You can see that it shows those files in there. I never did check in my PBX user file. Sometimes, we generally do that at Apple. We like to do that. I didn't do it here. So the PBX user file, for those of you who don't know, is a file that's in the contains your user-specific settings for a project. It sits inside the project bundle.

So we can also bring up the SEM window. Now this looks a lot like the same view, same stuff that's in the SEM smart group. But one thing that it has here is it actually has all of the commands that have been run when you're using the SEM system. So you can look there to see what's actually going on underneath the hood if you need to.

Okay, so I have this local version, of course, on here. I don't really want to have that. I've got this extra code. So I'm going to go ahead and just delete that or discard my changes. So we'll go ahead and do that. It'll ask me if I really want to do that. And of course, I'll say yes. And it's now, if we go up here, you can see, oh.

Let's go to the SEM group, SEM window. And actually, it's not up to date. So subversion. Our support is preliminary. So this is a preview release. The subversion support is not at the same level as the CVS version. But it's coming along very nicely. People are starting to use it, actually. So it's going to be very nice when we're done with 1.5 and 2.0. So with that... will bring up Matt. This is Matt Morse from our Tech Pubs group. Thanks. Thanks, Dave.

Hello, everybody. I'd like to talk to you a bit about documentation access in Xcode. And first I'd like to see a show of hands. How many people have used the documentation window in Xcode? Oh, great. I mean, most people have. And I'm sure most others have at least seen it demonstrated. So I'm not going to go through a point-by-point analysis of the features. What I'd like to do is really twofold. I want to show you -- tell you first a little bit about our plans for documentation integration.

And second, what I'd like to do is show you some of the techniques I think are most effective in getting answers fast to those questions you have when you're coding. So where are we with documentation access and where do we hope to be in the Tiger timeframe? Since Xcode 1.0 came out, it's had a documentation window, and that's allowed browsing, searching, API searching, and full text searching of the local content.

It, however, wasn't giving you access to an even larger pool of documentation, which is the documentation that lives at developer.apple.com, the ADC reference library. So where we're headed now is to make sure that whenever you're using Xcode, you'll have access not only to the resources you're used to, but the more expanded resources of the ADC reference library. And those include technical notes, technical QAs that are written by the ADC staff, sample code, and other documents as well.

So we want to make sure that when you're using Xcode, you always have access to those additional features. Another thing that we want to make sure you have access to is the latest documentation. Thanks to developments in our production techniques at Apple, we're able to update the documentation on a much more frequent basis than we have in the past. This is on the order of days or weeks at most.

So the latest documentation is also on the web, and we want to make sure you're looking at the latest when you're in Xcode. So that's the direction we're headed. What I'd like to do now is show you through a series of scenarios what I think are some of the best features of documentation access, those features that will get you your answers most quickly.

And just to set the stage a little bit, why is it important? Well, I think that we have good strategies for getting to your answers. Given the amount of documentation that we put on the local disk, it's very important. The normal installation has over 500 documents, from single pages all the way up to publishable books.

And in addition to that, it has reference for over 40,000 individual APIs, not counting the Sun documentation that, if you install a Java doc, you'll have another perhaps 40,000 APIs documented as well. So the terrain is vast, and it's really important to know how to get to those answers fast. So I'd like to show you a few scenarios.

OK. The first scenario is very simple. You're new to Xcode, you started up, what do you do now? Some programmers will dive ahead and just see how far they get with their intuition. Others will perhaps want some help. And the Help menu is the way to do that. Xcode help brings up the documentation window and focuses on the Help documentation. Now, first a note about the window itself.

As you notice, it's laid out a lot like the project window with a groups column that shows the documentation groups, a search field at the top, and a search And an area for the results, the detail view, and below that, the content view. And the content now shows Xcode help. So you might start there and read through some of the help documentation. But what if you want instead to look at demo, I mean tutorial information? Way to do that would be to run a search.

So we're going to search for Xcode tutorial. Here's the first take home point for this demo. The searches are scoped by the selected documentation set. So right now we're all set to run an Xcode tutorial search of the Xcode code help documentation. That may be a little too specific, so you might want to choose a more general area like tools, but I really suggest that if you have no idea how the documentation is laid out or organized, just select the top item, the library. That's all your installed documentation. And execute your search.

It goes out, searches all the documentation or the index of all the documentation, and it comes back here with a quick tour of Xcode, which looks like a good place to start if you want a quick introduction. Now one thing I'd like to point out, it may be hard to read back there, but up here we have what's known as a breadcrumb path.

And this is the path in the hierarchy of documents leading to the document you're looking at. So if you find a search takes you in too deep, you may want to click up a level. Here's everything about tools in Xcode, and more generally, tools, and so on. So you can go up to a more general level quite easily. And, of course, like in the code editor, you can use the back forward buttons to get to back to previous pages.

Okay, let's say instead of being absolutely new to Xcode, you're new to this version, 1.5 or 2.0, and you haven't yet looked into its new features. What you should do is take a look at the release notes, and you can always get to them through the help menu.

But I'd like to suggest a new place to look, and that's over here, Bookmarks. This is new in the seeds that you have, a bookmarks folder, and by default it's populated with a number of useful sites, including the release notes. So here we have the release notes, and you might get to them that way.

One thing I wanted to say, I skipped something I wanted to point out. The current documentation on your disk is much more web aware than it has been in the past. And we're moving more and more in that direction. You'll find as you browse through these pages that many of the links will take you directly to the website, so you will be able to get to the tech notes and Q&As. They don't live on your disk, they live on the website, but the content will take you there.

Another change that we made is we're making use of the website for the PDF content. Rather than install over a third of a gigabyte of documentation in PDF format on your local disk, which we've done in the past, we're now relying on the website for that content. So the links in your pages here will take you to the website for those PDF documents.

Now don't worry. Okay, that's good. For some of you that's good, for some of you it may not be so good. You like the PDF and you want them locally. So we're making those available to you as a package, and you can get that at the developer website. So you can still have them locally if you want.

Okay, so let's look at a different scenario, and that is you're using Xcode, you've built a project, and you're in the code, and you need some help. Dave mentioned this in the previous part of this talk, that option double click is the quickest way to get from a system API in your code to the related documentation.

So option double click is another take home point. If you're not using that now, please remember, option double click, quick way to get to the documentation. A couple of things about our reference documentation. As you can see, it's heavily interlinked, hyperlinked, so you can get to the types that a method takes, and you can easily motor around through the documentation.

A couple of other navigation notes. Up here, where you have a function pop-up in your code editor, here we have a similar use. This shows you all the API that's documented on that page. It also shows you some of the high-level headings in the page to help orient you. And you can not only get a summary of the page this way, but of course navigate to the individual APIs.

Okay. All right. Now, one thing I wanted to mention, when we did that option double click jump to this page, what really happened is we went up here automatically, Xcode, took your selection, stuck it up in the search field, made sure it's on the API search mode, and did the search. And of course, you can use this manually. Oops, I don't mean to do that.

You can type in whatever string you want, and it'll give you all the completions in the API. And that is, again, scoped by the group in the upper left here, library. So we see we're getting Java, Objective-C, and any other C and C++ APIs that we happen to have. By selecting a different group, let's say Java, you'll filter that down to just the Java APIs. Or for Carbon, you'd have, I guess we have no window wills, but we definitely have window prefix APIs.

If you forget, I hope you don't, but if you forget option double click, you can still use the context menu to... We have find selected text in API reference, that's equivalent to option double click, and of course you can do a full text search by using that menu.

Okay, if you're doing object-oriented programming, as Dave pointed out earlier, you can use the class browser to get around your classes and These classes are all system classes, so they have associated documentation. Just click the blue book and you can get to the documentation or to any individual method in that page.

The other thing you can do if you're writing a tool, let's say using Unix commands, make sure you know about the open man page panel. You can both get to a man page by name or do a search. For example, grep, let's do a search for all man pages that have that. Actually, it's doing an apropos search, and here are some of the results. Your man page is a--thank you. Your man pages appear in HTML, and they're all hyperlinked so you can get back and forth.

All right, one last scenario, not about the code, about the IDE. Okay, you're working in the IDE and you have a question. Let's say you're using one of these inspectors. Take a note that we have help buttons in the bottom right corner now. And by clicking those, it takes you directly to the appropriate documentation. This is fairly new, so we don't have them everywhere we want them to be, but we're working in that direction. So take a look for these links to the documentation. Okay, you're working in the IDE and you have a question.

Okay, you're working in the IDE and you have a question. Let's say you're using one of these inspectors. Take a note that we have help buttons in the bottom right corner now. And by clicking those, it takes you directly to the appropriate documentation. This is fairly new, so we don't have them everywhere we want them to be, but we're working in that direction.

So take a look for these links to the documentation. Xcode is accessible to--made accessible to scripts in a number of ways. You can use Apple scripts to automate operations in Xcode. You can use build scripts, build phase scripts, to intercede in the build phases, worksheets, and user scripts. And I'll talk about those in more detail.

Okay, AppleScript, of course you're aware that with AppleScript you can, We run an application by remote control. And with applications, you can do as much as their AppleScript dictionaries allow you to do. Xcode's dictionary is not complete by any means, but it has a lot of important functionality that you can use right now.

For example, in the seeds that you have, there's the import command. So you can batch import Code Warrior projects into Xcode. Or if you want to set build settings on a number of projects, you can do that as well. And that's what the code up there is showing. And of course, you can automate the build process.

Build phase scripts, I won't go into this, because the next session that's in this room at 3:30 goes into the build system in detail. But build phase scripts let you interpose your own set of operations in the standard set of build operations like compiling and linking. And you can have scripts that would do any of these kinds of operations such as logging the progress of the build. And you can write build phase scripts in any of the supported languages like shell or parole.

Okay, so let me show you a little bit about scripting in Xcode. First, I'd like to show you worksheets.

It's a very simple idea. You have a command in your code editor, like this one, simply listing the root directory. Hit Control-R, and the command is executed, and the results come back into the code editor. Now, why would you need that functionality? What kinds of uses can you put it to? I'll tell you one that I've used is when I was debugging a bundle that my application was using, I would have different versions of the bundle and I would load one or the other depending on a default setting. And rather than type in the default command each time, I could just execute it here, restart my app, and it would load the other bundle.

There are a lot of different suggestions here for things you might do. Some of them are written in Unix utility commands, some of them like sample or default. Some of them are written in Perl. So you can get this sample worksheet at the developer website this evening. I believe the disk image of this session will include it.

Here's one I'd like to run for you. I think anyone in San Francisco, any programmer should know where all the local earthquakes are. This one has just gone out and told us where the ones that occurred in the last two days are. It looks like we're pretty safe, so let's go on. What I'd like to show you now is the user scripts menu that's up here. And by default, it has a lot of useful commands. Let's take a look at some of them.

One that I use all the time is the comment-uncomment command. And if you haven't used it, I suggest give it a try. It's bound to the command slash And you can easily take a section of code out of service that way. Another one that I think is quite useful, especially for Objective-C programmers, is if you have an instance variable and you want to set up some accessor methods, just select the instance variable, go to the code, place accessor declarations on clipboard command, and paste in the accessors. And there's an equivalent one for the definition.

Thank you. There's another suite of commands I think you should know about, and that's the HeaderDoc suite. And I'd like to show those quickly. This HeaderDoc is like Java doc. It allows you to put structured comments in your headers and then run them through the utility and generate HTML documentation. So let's do that quickly here. Here's our class declaration. Let's put in a class template. So it's parsed the class and superclass. We just put in this method.

Let's add the method template for that. And again, it parsed out the parameter. Save the file because HeaderDoc works with save files on disk. And then view the HeaderDoc for this header. What will happen is it went out, ran HeaderDoc on that header. Here's our class, and here are the methods, the ones that I had already marked up and the new one that we just put in. So it's a very quick way to get some good looking documentation for your classes.

What will happen is it went out, ran HeaderDoc on that header. Here's our class, and here are the methods, the ones that I had already marked up and the new one that we just put in. So it's a very quick way to get some good looking documentation for your classes.

What will happen is it went out, ran HeaderDoc on that header. Here's our class, and here are the methods, the ones that I had already marked up and the new one that we just put in. So it's a very quick way to get some good looking documentation for your classes.

The installed documentation, Xcode help, and especially the quick tour that we saw earlier, I think would help you, remind you of some of the techniques we talked about today. And with that, I'd like to bring up, I don't think Matthew Formica, but virtual Matthew Wiley Hodges. Thank you.