Good afternoon everybody and welcome to Streamlining Your Workflow. I'm Chris Espinosa. I'm the User Experience Manager in the Developer Tools Group at Apple. And I have one and only one objective for this session today, which is to highlight the new Xcode features that help speed your work. You saw a quick demo of them yesterday in Ted Goldstein's keynote presentation. I'm going to take you in-depth to the new features in Xcode 3.0 in Leopard. Let's talk about your Xcode workflow before, from Xcode 1.0 all the way on to Xcode 2.4. I've had a fairly simple workflow.

You acquire a project, which usually means going to the terminal and connecting to your subversion or CVS repository and checking it out, or maybe you drag something down using the finder from a server. Then you edit it in the editor, and that's worked pretty well. And then you build it and you get a build products window, a build results window on top of your editor window and then you can find your errors and warnings.

And then once you get your errors and warnings resolved, you debug and you step through in the debug window. And then at some point you rewrite your code and then you have to reconfigure using... then to rewrite your code you do some research, you need to bring up the documentation window. Notice where your code is. It's now buried beneath level after level after level of window.

And then you reconfigure your project. You set your build settings, you bring up the build inspectors, they're covering up your text file, and then at some point, if you want to restore because you've completely messed things up and you need to go back to the beginning, you've got to go all the way back to the finder and get this copy that you saved on disk.

We want to cut through all of this and help you focus on your work. The really only two things we're doing in Xcode 3.0: focusing on your work, which means bringing the tools to you right where your source code is when you need them, and second is finding and filtering so that when you do go to another window to find something, you can get there fast without a lot of scrolling around. And everything we're going to show you today helps you focus on your work. work and find and filter.

So, the focus is on your editor and it doesn't matter whether you're a one window or a many windows kind of programmer. We're pretty much eliminating that war by bringing all of the tools you need right into your editor window, whether it's separate or whether it's embedded. If you're editing, we're going to bring you tools that focus on your code and help you show you what you're working on in code focus and code folding in the editor.

When you're building, we will bring you your errors and warnings right to the line of code on which they occur instead of putting them in a separate window where you have to navigate to different files according to where your errors and warnings are rather than dealing with your warnings where they sit in the file you're working on.

When you're debugging, we will bring you the debug information right there into your text file in terms of stepping information, breakpoint information, and debug symbolic information right there in the text file where you work. This is what we mean by focus on your work. So let's work through these four phases of streamlining your workflow. First, acquisition of a product, of a project, and editing that project. The first step to streamlining project acquisition is that we've built repository management right into the Xcode user interface for CVS, Subversion, and Perforce.

You don't have to use a different tool, you don't have to use the command line in order to connect to or browse a repository, to import a new project into a repository, to export a project from a repository into a plain project on disk, to find different versions or tags of a project in a repository, or to create a new tag or version in a repository. All of these are handled in one window built into Xcode and we're going to show that to you.

Second thing is streamlining source editing. Once you have your project and once you're working on your source, we're doing a lot to make editing faster and more intuitive. You saw in the demo yesterday that we're handling large files much, much better. We can open and scroll to the bottom of a very large file in a few seconds where it used to take us 30 or 40 seconds. It's not just improvements in Xcode but some improvements in Coco's underlying text classes that allow us to do that.

We're also improving the syntax coloring so you see more vividly on your screen what's a method, what's a function call, what's a constant, not just a bunch of black text on a white background with occasional pragmas or macros or comments in one color. We're helping you get unneeded detail out of the way by letting you focus on the particular nested block of code that you're working on and dimming back other things and seeing the block structure of your program regardless of your indentation style. I'm sure most of you have had the experience of getting somebody else's file and seeing what curious indentation paradigms that other people tend to use.

Sometimes you really can't figure out what brace matching style or what indentation style, one tab plus two spaces for this level, they may use. You can ignore all of that by using the code focus mechanism in Xcode 3.0 to see what the block structure is quickly and easily. You can also use code folding to move extraneous code out of the way and just collapse it so that you can see just what you're looking for, just the function names, just the code without the comments, or just the function that you're looking for.

So to demo these features, we're going to bring up Dave Ewing of our group. He has done most of the work on the Xcode editor and he's going to talk you through the demo. Thanks, Chris. I didn't do all the work. There's a lot of other people involved here. Well, the first thing we're going to do, well, we want to spend most of our time in the text editor because that's where the focus is, but you can't get to text without having a project.

You can't get to a project these days without having it in a source code repository, so the new source code repository management feature. And this is in the Xcode preferences where, could you put the demo machine on the monitor up here? Or I can just look back there all the time, right? So that one's not set up.

Well, if we had the repository set up on that machine, which it was set up moments ago. Sorry, we're starting with setting up the repository. Oh, well, let's start. So you can go ahead and click the plus button down below here and point to the directory. In this case, we have a repository set up on this machine in the file system so we can use a file URL to get to it. You have to name the repository. Here he's going to type in a file URL. Let's see if he types well. And you can see down below there's a little status that tells you it's evaluating what he's doing. So once he gets to the right place, SVN repository.

And look, it says connected to the repository. So good, we can do that through the preferences. And then in the SEM menu, we can bring up the browser. So this repository has the AppKit examples imported into it. You can click through these folders here and see the source code. Browsing is very quick. We also have this other project that we imported called Xjournal. And let's go ahead and check that one out. We'll just put it on the desktop.

And you can see it's the little spinny wheel there is spinning. It takes a few seconds. There's about 45 megabytes of stuff in the project. And when it's done checking it out, it notices that there's an Xcode project sitting there at the top level and it, you know, helpfully offers to open it for you. So let's go ahead and open the project.

So here's a new project. We'll make things a little bigger so we can get to the text editor. And the first thing we want to show you is, well, the first thing we want to do is put a file in there. And we'll open the main document window for this, the source code for the document window here. The first thing you notice is that it's a lot more colorful than it used to be. Now it turns out that, you know, as the freight train that is Mac OS X was moving along towards WWDC, they make you stop and make a DVD to give to you guys.

Well, we didn't stop working just because we built a DVD. So this feature that shows source code coloring of indexed symbols is something that's not on your disk, but it is something that will be in the final version of Xcode 3.0. So we're coloring index symbols, so classes, type defs, preprocessor macros, method calls.

And it can differentiate between those symbols that are in your project and those that are external to your project, so framework symbols. So the next thing we want to do here is show you a little bit of a demo of what we're doing here. show you one of the new features in Code Sense.

So Xcode 2.0 had two ways of doing code completion. One is the next completion that would cycle through the best guesses that the editor had for you, and the other one would bring up the pop-up list. Well, we wanted to do something that was a little more similar, a little more familiar to people that was a lot like what's done in Mail and Safari.

So with automatic completion turned on, you can type right in your editor, and if we type a few characters there, it'll offer to complete the rest of the word right where you are. And you can hit the tab key to finish completion. You don't have to hit a next completion key or whatever. The tab key is just too convenient. So there we typed "for" and it offered to complete format string. Let's go ahead and complete that.

And we'll do a little bit more. Let's-- So in demos you always duplicate the line above because that's the easiest thing to do. So let's see. So when there's, you can see there's a little selection there. There's a selection. So what happens is it's guessing the most likely completion for you and when it selects a little bit at the end, what that means is that part is actually unique. So if you hit the tab key it will complete to that. NSUserDefaults of course is a class that it knows about, but there's also this NSDefaultsController class that it knows about.

Let's go ahead and bring up the completion list for that. And you can move around with the arrow keys to complete. So this list is still there. It's still useful. So if you don't really know what the name of things are, you can bring up the list and backspace and type and find what you're looking for. So he's doing a little bit more here to complete the line.

So we're doing next completion now, right? Mm-hmm. So if you type a character and you just want to cycle, you want to quickly insert the most likely completion, you hit next completion. So it's in the edit menu. It's control period is the default key binding for it. And it will just cycle through a list of the most likely completions. And you can go ahead and type right away. You don't have to hit tab key to finish that completion. All right. So let's... Oh, he's completing. Oh, we can of course complete inside strings too. So it knows about the words that are in the file.

And we're going to delete that. So let's go ahead and show one of the perhaps most underused feature of code completion, and that's text macros. So let's go ahead and type the word for. Now, the most likely completion here is actually going to be format string because it's a local variable. So if you hit next completion, it should complete to format string.

There we go, it has format string there. But we also have some text macros in there for for loops. So go ahead and hit next completion again. Here's a placeholder for a for loop. And do another one. Let's say here's one that actually puts a loop around an NSArray. We need to change that one for Objective-C 2.0 now that you don't have to do all this extra code. And let's go ahead and delete that little bit of code.

And select those, the if-else blocks there. So the other cool thing about text macros is that they can wrap around the current selection. So if you go up into the Edit menu and down into Insert Text Macro and the set of ones for C, there's an if block down there. Let's go ahead and, the farther one down below.

That's a pound if block, so that's a pre-processed statement. That works too, but for the demo, what it does. I want to do this pound if block. He likes that one. So you can insert a pre-processed macro around it, so you want to delete some code. And there we've inserted the if block, or the preprocessor block.

All right. Okay, so he's taking a snapshot. We're going to talk about snapshots a little later in the show, but in preparation for that, we want to take some snapshots. I think most of you probably saw Ted's keynote where they showed a little bit about snapshots. It's a way to get back to previous versions of your entire project. Okay, so the next thing we're going to show is -- Well, let's see. It's code focus.

So we have this method here called commit sheet and it's, oh, 100 lines longer. So why don't you scroll down a little bit so we can see a little bit more of the method. And you can see there's a lot of if statements. It's not always easy to see exactly the structure of the file though. So the new feature in Xcode 3.0 to help you with this is code focus. And the way you get to it is by hovering over this little ribbon on the left-hand side.

And when you do that, it grays out. It's a little hard to see on the screen. You guys have the software so you can look at it at home, of course, or in the audience. But as you hover over, it's actually animating that block and it's got a little balance animation. I can see it from up here. You guys probably can't see it. So that lets you focus in. You can scroll around a little bit in that. If you use the mouse wheel, you can scroll down and see what little bit of code is highlighted.

So that's good. I mean, that helps you see the overall structure of that or little parts of the structure of the routine because you're, you know, what's in the view. But sometimes the routine's big and you want to see the overall structure of it. So the way to do that is with code folding. You can hide portions of it, sub-portions, blocks of your code. Let's go back up to the beginning of that method.

And when you're hovering over that, you'll notice that the folding ribbon there changes a little. There's a downward and upward pointing triangle. And if you click, it'll actually collapse. So it's collapsed the whole method there. Let's go ahead and expand that again and go down to the first if block.

Right there at the top. Go ahead and collapse that. And let's collapse the next else if, and the next else if, and the next else if. And you can see that this routine has actually got a pretty simple overall structure. See the little pound warning up there? We could really clean this up. I guess maybe you should be doing that a little differently, eh? Okay, another thing you can do is you can hide all of your functions. You can collapse all of them. So let's go ahead and just use a contextual menu for that.

So if you control-click. On the Code Folding menu down inside it says Fold All Method and Functions. So go ahead and do that. And you can see they're all gone and you can just see the methods you're interested in. That's something that people have been asking for a couple of years now. So we're very pleased to be bringing it to you finally. That one's a little uninteresting. Let's go ahead and unfold all of them inside of the contextual menu.

And fold all. Up above. Okay, well let's go ahead. So fold one of those methods. Any way you please. So the other thing is there's that little placeholder there, the ellipses inside of the box. You can double click on that and it unfolds too. So don't just have to use the ribbon. There's keyboard equivalents for all of these menu commands now.

Okay, so let's show one more thing with code folding. So let's go ahead and go up to the top of that file and double click. There's... A method for you, LJ or a class. There you go. LJ. So we brought up this header file here. And it's full of documentation comments, which is really great, and we love them, and we want you to use them, and we want to use them more than we do.

But sometimes when you just want to see the methods that are in the file, they're kind of in the way. So we also have a menu command to hide all the block comments. And so now you can just see the methods without any of that extra stuff.

So find and replace. Obviously you'd want it to unfold what you get to. So here it unfolded the method, it unfolded the method below. So it automatically unfolds to get you where you need to be. Okay. Thanks Dave.

So obviously there are a lot of new features and functions in there and there are obviously new controls and preferences for controlling those functions. We will have controls for setting your syntax coloring in the final product. The syntax coloring, as Dave said, isn't in the preview that you have, but it'll be in the final product.

There are controls for showing or hiding the code folding ribbon. It's actually called the code sidebar in the version you have in the CodeSense preferences. There are preferences for CodeSense code completion for whether to automatically complete inline and if so, to do so with a delay or without a delay. Those are in the CodeSense preference panel. And there are some other controls about code folding in the text editing and indentation preference panes.

So let's talk about the next phase of streamlining your workflow. Streamlining building and debugging. Building and debugging have been vexing for people not only because they take so long, but because they require so much window manipulation. Bringing this window up, bringing that window up, it's hard to see your errors and enough text at the same time in order to get a sense of context. Sometimes when you're building Universal, you get two errors in every file, so you get twice as many errors to wander through.

And then in debugging, you're constantly switching back and forth between your application under test and your software to trace through it. There's going to be an entire session on debugging coming up later. I strongly recommend you go to that. They're going to go through a lot more of the steps there. But we're going to talk a little bit here about streamlining, building, and debugging.

The first thing is that we have introduced message bubbles, a kind of annotation to your source code. This is a generic architecture that we're going to use a lot more in the future. Initially, it's for errors, warnings, and breakpoints. And what it allows us to do is to take an external data source of anything that pertains to your text file, anything that can give us line and column information about text in your sources, and we can inject it right in the source in a seamless and transparent way.

So that you can scroll through it, you can codefold over it, you can do anything you like, and that the annotations, the message bubbles, are not saved to your backing file, but instead are metadata that come from some other source. So it lets us give you an overlay of information on top of your source code, especially information that's kind of ephemeral or transitory, like warnings. You want them there when you fix them. You want them to go away. So you just want a way to see them in your source code. source code, and then when they're fixed, to just go away.

We have really worked on the workflow of building and debugging with message bubbles. We have wired up the next build warning error, previous build warnings error, so it will step through every error and warning in your project and bring up the right file and scroll you right to the position and show you the text of the error right there along with your source code so you don't have to go anywhere. Just one key, command equals, will take you quickly through all of the warnings in your project.

We've really worked on streamlining the workflow of building and debugging. We have a streamlined debugging model where not only are the debug window and the console window and the standard I/O window now all unified so that they're all the same thing, but also the debug and run commands are the same thing. If you have breakpoints on, command Y debugs. If you have breakpoints off, command Y just runs your application. Un-command key, it does what you want.

When you're debugging, we try to keep you in your source code as much as possible. So we have the debug bar at the top of any source code window that you're debugging and it has all of the basic controls you need for debugging. You can step, you can pause, you can continue, you can look at your stack frame and you can navigate to other stack frames or other threads right there in your source code. And you have the basic debug information in a message bubble right there in your source code.

Right now only the enable/disable checkbox is operative, but we'll have essentially the full breakpoint interface right there in your source file. So you can stop, expand the bubble, set breakpoint conditions, put in breakpoint actions, for example, to evaluate something on a breakpoint or print a log message, and do it right in your source code without having to go to a separate breakpoints window or the separate debugger window. We can also show you the value of variables in the data tips, which are not just tool tips, but they are a completely hierarchically structured inspector of your program's data space right there in your text editor. I think you're going to be amazed by this.

So Dave's going to come up again and we're going to show you message bubbles, the debug strip, and data tips. All right, well, we need to build the project. Ah. Which I gratefully forgot to do before I left the stage. Luckily. Luckily, these are fast machines. This is a dual-core power PC and it's quite fast. Yep, that's right. So did we build? We are building. Okay, so this project is actually two projects. There's a framework project that has 30, 40 files in it or so. And then there's the project itself, the main application. So it takes a second to build.

Oh, build succeeded, but there's warnings. How did that happen? Turns out there were warnings ahead of time. There's a lot of pound warnings in this project. We also made a little modification. So let's go ahead and go to the next build error warning, command equals. And it takes you right to that warning.

Little hard to see, these are optimized for a regular screen, not for display up on the big wall. Let's go ahead and go down through a few more warnings here. Keep going, let's get back into the XJ document file again. Detect Music Now. So this particular method is inside of this file. So why don't you go ahead and fold all the methods.

And just so you know, when you're folding methods, if you're inside of a method currently, it doesn't fold that method for you. It figures you're trying to hide the other stuff. So let's go down and see if we can find that method, detect music now. And there it is down at the bottom.

And we want to move that. So since we've folded, it's a lot easier to find the method. We can just drag it up to the top. We'll put it somewhere above that particular method, perhaps even near the top of the file. There we go. And we can build again.

and the warning is gone. So, all right. So let's see. We want to do some debugging. So let's go to the control text and editing method. There we go. Let's go ahead and set a breakpoint. Actually, before we do that, let's go up into the file navigator there. There's a pop-up menu over to the right that will allow us to hide those errors and warnings. So we don't need to have them there.

You can hide them. They do remain hidden once you've hidden them. And let's go ahead and show breakpoints. So here it is in line. So it turns out actually the auto continue checkbox also works. Both checkboxes work. The condition text field does not work at the moment for these. But I guess let's go ahead and debug.

So we'll bring up Xjournal here. I don't know if we explained this. It's actually an editor for live journal blog posts. We don't need that particular window. We want to go in and add a new entry to our blog. And we'll add a name to the music field.

and it'll hit the breakpoint. So, we're here in the debugger, but we're really just here in the editor, aren't we? So this bar at the top of the text view there has all the information you need. It's got a threads pop-up on the left. You can see there's multiple threads there. It's got the stack trace over on the right. Let's go ahead and go down to one of the other methods and back up.

and all the buttons to continue, pause, all that sort of stuff, the standard stuff. You can get to the console window right from here. So let's go ahead and look at a notification. So we have data tips, right? Now you've seen these in other IDEs perhaps. I've seen them in other IDEs certainly. And usually they're very simple. They just have a little tool tip that describes the basic information. But that's not enough. I mean structures are big. They have lots of stuff in them.

So let's go ahead and over... A notification actually doesn't have much in it, does it? It has an "is a" field and that's it. Well, in order, a lot of Objective-C objects and in fact core foundation objects as well have description methods. So you can get to that description method if you move over. The two upward and downward pointing triangles brings up a contextual menu. And let's go ahead and print the description into the console.

So this is a way to get that information in the console. The console will always be a useful feature in the debugger. You can do a lot of your stuff inside the editor, but really there's so much there in GDB. Sorry, we just kind of love it. It's a little weird. So let's go ahead and look at something a little more interesting. NS Text Field is a good one. So hover over the little triangle on the left. It brings up the field. Let's go up to the underscore bounds field at the very top.

and hover over that triangle over there. It actually gave you a description of it, but you can go down multiple levels. and just get to anything you want to see. So you don't have to have that field taking up your whole window all the time. When you need to look at the value of something, you hover over it and get to it.

But it's not just for variables. Let's go ahead and select a-- Arrange down there. Yeah, self-entry. That's a good place to go. So we can also evaluate expressions in these fields. So if you hover over them, it knows that the expression looks a little dangerous so it doesn't automatically evaluate that, but it puts up this little info button. If you click on the info button, then it will bring up the field and then you can go down and inspect it.

If it's an expression that it doesn't know how to evaluate, it doesn't end up bringing up the field. So we need to give some feedback. In the final version, we'll do a little bit better job of that. But right now, you can actually evaluate all sorts of expressions there. You don't need this separate expressions window either. All right, let's see. I think that's probably good. Yeah. Thanks, Dave.

Thank you, Chris. OK, I'd like to show you a little bit about the research assistant and the new features in the documentation window. But let's first look at how you got to documentation in Xcode 2.0. The fastest way to get from an API in your code editor to the documentation is Option-double-click. So if we could do that.

And you see, as Chris pointed out, the documentation window takes you right where you want to be, but it obscures the work that you were currently in. So the lighter weight solution is to bring up the research assistant in Xcode 3.0. You can get there from the Help menu, or you can get there with a toolbar item. So if we can bring that up. Okay, the research assistant is this small window that, as Chris said, hovers on the screen and listens to your selection in the code editor.

As you click around in your code, you can see how it updates to show you what the current selection is and gives you some information on that selection. So if you twist open a few of those slices, we can see a little bit more of what it's showing you.

OK, and if you would select a few of the methods and classes and show them how it's updating. So you can see that the Research Assistant offers a variety of information on the selected API. Let's take a closer look at exactly what that is. Starting at the top, there are three lines of links. The top one is a link to that API documentation itself. And clicking that would be equivalent to option double-clicking in your code editor.

It takes you right to that reference. The next line down takes you to the enclosing document. The document, in this case, the class documentation for that string class. If you were looking at a method, this would be the class that contains that method. And the next link down is to the header file that declares that API. Clicking that will bring up the header file, just as you would bring it up by command double-clicking in the code editor.

And below those three links we've got a series of slices, each one dedicated to a specific topic, declaration, abstract. And if you twist open a couple more like related API and sample code, Now, this is data-driven and it's a work in progress. We have a lot of entries for certain slices, other ones we're working on.

For example, the sample code, we have a few entries, but we'll be working on that over time and it'll become a lot more valuable by the release of Xcode 3.0. Another area that's quite helpful is look at that availability slice. It tells you when an API became available in Mac OS X and if you would select that font method near the bottom, it also tells you about APIs that have become deprecated. So if you'd open that slice, it tells you not only that the method is deprecated, but it gives you a reference to the replacement API.

We really hope that that will help you bring your projects up to date and make sure when you're creating a new project that you don't use deprecated APIs. So that's the way the research assistant can bring targeted information to you. But sometimes, as Chris was saying, you need to get to the documentation so you can browse and search it. And for that we have the documentation window.

It looks very much like it did in Xcode 2.0, but the plumbing's all new. It's all core data driven and the metadata is in core data stores. So what does that mean to you? Well, the first thing you can see is on the left at the top under Apple, there are two documentation sets instead of the one that you had in Xcode 2.0. And we're going to be breaking out further documentation sets. We no longer require one monolithic documentation set. In this case, we broke out the Java documentation set from the rest. And now we have two. We'll have others by ship.

Now, as Chris clicks between those two documentation sets, you'll see that the API list updates to show you just what's available in that documentation set. So that's the first thing you need to do. And then the second thing you need to do is you need to go to the documentation set.

So this Configuring your work environment, you'll be able to download and install just the documentation sets you want and your searches will be just on those APIs that are relevant to your project. Okay, another piece that's new is we've introduced one more type of search. We had API search, which you saw here, full-text search that's been around for a while.

Now we have title search. And I think this is going to be very valuable, especially if you're looking into documentation for a new technology like Core Data or Objective C2. You can quickly narrow from the 3,000 plus documents down to, in that case, just the primary entry point for Objective C2. So those are the two new features of documentation access in Xcode 2.0. 3.0, eh? 3.0. 3.0. And we're still refining them, so if you have comments and suggestions, please let us know. We want to make sure it works well for you. Thank you.

Thank you, Matt. So we're on the last phase of our streamlining journey back to the beginning where we give up and acquire another project. Project configuration. This is where a lot of people unfortunately spend most or far too much of their time, is changing build settings so that their project actually builds. Finding the right build setting among the myriad settings we have has been a historical problem.

Well, we've made some significant changes in the build settings inspector for Xcode 3.0 using some new technology that's in Leopard and I think you're going to love it. We have added searching and sorting to the build setting inspector. We have added built-in per architecture build settings so you don't have to synthesize your own separate build settings for PowerPC and 386.

Which is going to become increasingly important as you now have four architectures to build for, not just two. We support the research assistant for build settings so you can get the same kind of documentation on build settings that you have on APIs. And just incidentally, we now support code completion of build settings in XC config files so you don't have to go back to the documentation and copy and paste.

Now one of the big things about project configuration is that it makes changes in your project file and your project file is hidden and opaque. And it's very hard to see what changes you've made and the changes you make often break things, so you have to roll back to the previous version and often you just do it blindly saying, "Oh, I've screwed this up, throw it away, go back to the backup." Backup and Restore. We have added built-in backup and restore to Xcode.

You've seen the snapshots I've been taking all along. You can go back and look at those individual snapshots over time to see the changes you've made and diff them, not only diffing your source code changes, but nib file changes and project file changes as well to see what changes you've made.

Now the... The Snapshot File window is not as whizzy as Time Machine. I apologize. We don't have an animated Starfield background on our Restore window. But very simply, every time you make a snapshot it goes in the list. And you can pick one from a list and go back and restore to it.

So if you know what you want to do, go back to a certain point in time, a date, before or after a certain operation, you can do that with one click. If you want to see what the changes were, you can look at the file list and then see a comparison on a file-by-file basis as well. To show you both of those, I'm bringing up Scott Tooker of our group.

Thanks, Chris. One thing I wanted to clarify is we actually do have searching in Xcode 2.0. It's not as good as in 3.0 for the build settings. One new feature that we're not showing you today that I would encourage people to try out though is we do support type completion for include statements.

So anyway, so we've shown you a lot about the editor. And so now what we want to do is turn your focus to actually the target inspector. Because this is where-- you don't tend to spend a lot of time there all the time, but you tend to deep dive into it every once in a while, because you need to get your project building or you want to change what architecture, you want to change something about it, set up or release, build, et cetera. So we wanted to make a lot of changes that would make it a lot easier for you to get to information quickly and efficiently.

So one of the first things you'll notice is that we put the categories-- we pulled them out of the categories pop-up, and we put them right into the table. And so now we actually have an outline view. You can collapse categories. It's much easier to see just the build settings you want to look at.

Now the next thing I should show you is that even though it's an outline view, we still support the searching and filtering. So for example, type debug and I see just the build settings that deal with debug, but they're still grouped by category. So once again, you can just focus in on one category and it's much easier to see.

Chris Espinosa, Dave Ewing, Matt Morse, Scott Tooker Now if we go ahead and look at the filter field, we've also improved that. Previously in Xcode 2, what we did is we allowed you to just search on an amalgam of the description, the name, and the effective value. Now we also let you search on the definition and the category, but in addition, we also added the menu so you can just search on one of those criteria. And so we think that's going to be a lot better for people when they want to find things. For example, warnings. You can see here we're just looking at the one group. the one category.

So actually let's go back and one more thing I wanted to say is that we've replaced the categories pop-up if you use Xcode 2 with the show pop-up. And we got rid of all the category items because they weren't needed anymore, but we still have, you can show all settings, settings defined at this level and user-defined settings.

So for example, here are all the settings set in this project. So let's go back to all settings. In the search pop-up, if you can select category, and type in "warnings." So you see here now, we're just looking at one category. And it's great. In this case, we can see all the settings here on one thing.

But it's kind of hard to see exactly what I have set. They're kind of spaced apart. They're not grouped together. It would be great to group them together to get them more organized by their value. Well, in Xcode 3, now you can click on the Value column, and there they are. They're all grouped at the top. You can see exactly what you have set. And if you want to go back to grouping by alphabetical titles, you can just click on the titles.

And the nice thing is that if we turn off the warnings and show you everything, we actually keep these grouped by category as you're sorting on them. So for example, if he clicks on Value, you'll notice that we're still keeping the categories grouped for you to make it really easy to understand what you're looking at.

So if we look now down at the bottom, what we used to have is we used to have an edit button and a plus and a minus button. And there were more things that we needed to add. For example, the per architecture settings that Chris talked about. So what we decided to do is when you have an item selected, we just wanted to have one kind of pop-up menu that you could use to act on that selected setting. So for example, here if we look at the prefix file, prefix header, sorry. And if you go ahead and click, you'll see that now there are a number of-- click on the menu and there's a number of options you can do.

You can edit and delete. You could edit that setting, for example, and that will bring up the sheet. And you can type in things here. At this time, you could also go there and you could delete the setting defined at this level. You could also add per-architecture settings and add per-user defined settings.

One note about per-architecture settings. We'll be talking about this more in other sessions, but I should note that we actually look at the build setting and we will either have it enabled or disabled depending on what the build setting is. So we don't allow you to set a per-architecture setting when it makes no sense.

So if we actually go and select Prefix Header, we're now using the new AppKit style of editing in tables and outline views. All you need to do is select and click in the cell you want to edit and you're right in. It's very Finder-like, it's very simple, and we think you'll really like it.

So in doing all this, we also realized that we really wanted to expand the kind of help information that we had for build settings. And that little split view we had just wasn't going to cut it. There was just too much we wanted to show you, too much we wanted to link back to, and we wanted more structure.

So what we did instead is we just got on the research assistant train. And so now you can click on research assistant and we'll actually track with the selected build setting. And you can see right now, just as a beginning, we show you the actual build setting. So you can see the name and an abstract, the help text description. But in the future, we definitely want to flesh that out with both deprecation information, related build settings, related documentation, even potentially sample code.

So I've been at Xcode a long time. I actually worked on Project Builder before Xcode, before Project Builder with Xcode or whatever. But one of the things we did when we moved to Xcode is we started showing you effective values. And this was great because you could see what things were going to actually be. It was much, in some ways it was much better than showing the definitions. But the flip side was there were times when you wanted to see the definitions because either it was clearer because of the structure or you may have had one build setting related to another.

And while it's true that when you edit you can see the definition of what you're editing, that isn't really useful when you want to see all your settings kind of in context. So now what you can do is you can control click on the table itself and we give you two new options. The first is show definitions. What this allows you to do if you select it is that we'll actually change over and show you all the definitions.

And you'll notice that we've also gone through and made the pop-ups and the checkboxes strings. And while it doesn't work in the preview you have right now, the intention for the GM is that you would also be able to set things like pop-ups and strings to other build setting values. So you can get some of the value of config files where you could set a yes or no value to another build setting right in the inspector.

The other thing we added was we added the ability to show you the raw names because sometimes you're dealing with a config file where you need to pass something to Xcode build or a script. And so now you can do show setting names and we actually show you the settings.

So the nice thing is is that during all of this research assistance is still working for you. So if you get confused by the raw name and you know it by the title or you know it by the title but not the raw name you can always look at research assistant and it will have all the information.

So let's go ahead. I think we wanted to change. Did you change the build setting? Yeah. Excellent. So one of the other problems is that when you go in and you change build settings, sometimes it's kind of hard. You're going through, you're trying a bunch of stuff, and you're like, oh, that worked. Oh, that gave me the result I wanted. That didn't quite work.

And you might want to go back and forth. And so that's where snapshots can be really useful. So what we've been doing this whole time is doing a bunch of snapshots just to kind of show you what the possibilities are here. And you'll notice here with the snapshot windows, we have a list of the snapshots. And they each have a name that you can set.

In fact, we can rename this one right now to say, made build setting change. You can also provide comments. And we also give you the date and where it was actually archived. So let's go ahead and choose one of these. And we're going to want to-- after he.

So let's go choose one. We can go ahead and we can show the files. Now, as you've probably seen in some of the other demos, Once Chris decides which one he wants to look at... This one. We can actually look at the different types of files. And what you may have seen in the demos before is that not only can we show you differences here with like header files and source files, is we can also show nib files and more importantly for this demo, we can show you the project file changes. So for example, here's a .m file and you can see this is where we actually moved some code. We also did some white space changing when we put in the F1.

So if we go ahead and we look at the PBX project, you see, there we go. There's where Chris added in his new warning. And we think this will be really helpful because one of the things that we're working hard to do is we want to make it really easy to understand what changes you're making to your project and how those are affecting you. And while this isn't the complete answer, we hope this is a step along the way to getting to a clearer Xcode, a little bit that's more transparent and easier for you to use.

And then finally, yes, I know Chris, I know, we want to restore. So if you've ever reverted a project, one thing to note about restore is this is going to go back and that's not a bug, it's actually intentional. Just like when we revert a project, we're tearing down the project entirely and we're bringing it back up. And see, there it is. Thank you, Scott.

We've made a couple of other workflow improvements that you may enjoy in the course of working on Xcode 3.0. We'll probably make more before we get to the final. We've got a little time before Leopard ships. We need to get the bugs out of this version. Obviously, it's a developer preview and we have to smooth off some of the rough edges on what we've done, but we also want to do a little bit more for you.

We have added a project compatibility setting in the project Git info box. On any project, you can set whether you want this to be an Xcode 3.0 project or whether you want it to be compatible with 2.x. And if you set it compatible with 2.x, anytime you use a 3.0 feature that won't work on 2.x, an alert box will come up and tell you that you can change the project compatibility to 3.0 and take the change or you can cancel the change. So you know if you're making a change, that will make your project incompatible with 2.x. That's going to be even more important when we get 2.x running on Leopard, so you can have Xcode 2.x and Xcode 3.0 running side by side, sharing the same projects.

Second thing is, you saw a little bit of it, we can now search in nib files in the Project Find dialog. If you have key value coding constants in your nib files, Project Find will find them as well. So if you're looking for a method name, the nib files are completely indexed and anything you can find in the index, you can find in Project Find and that includes nib files. We've added a recent files menu.

Now this is under a user default. You go to the expert preferences setting and you read the first line there and it will tell you how to turn it on. I won't. This is the standard Cocoa recent files manual and you'll find that for program editing it is to some degree suboptimal.

Cocoa throttles it to 10 entries. You can set another standard NS document defaults right to increase it to 50, but every file you touch will be put in here. We're going to do a better job on this by the release product, but in case you want a recent files menu in Xcode, you can in Xcode 3.0, you can turn on this expert preference and get the recent files menu in Xcode. We've also fixed the doc menu so that you can pop up the doc menu and you get the full list of projects and windows inside your doc menu, just like any other application.

These are minor workflow improvements, but from the email I see and from the duplicate bug reports I process, these things are just annoying people and we want to get as many annoying things as we can out of the way. To streamline your workflow: acquiring and editing projects, building and debugging, rewriting and researching, reconfiguring and restoring your projects, we want to allow you to focus on your work and to find and filter to get to the information you need quickly.