Welcome to Session 314 at WWDC 2007. Our session today is Project-Free Xcode and Mixed Language Development. I'm Chris Hanson, and running demos today is going to be Norbert Schatz. We are Developer Tools Engineers working on Xcode. So what are we going to talk about today? What's the whole point of this session? Well, Xcode is a really, really great Mac OS X development environment. And historically Xcode has been targeted specifically at developing native applications for Mac OS X. Developing applications, plug-ins, and so on for Mac OS X technologies, and the Mac OS X overall technology architecture.

But there's a lot of people that come to Mac OS X because it has such a great user experience, because it has such a great development experience, that still want to use their existing infrastructure. They have all sorts of projects using all sorts of different infrastructure, and we don't necessarily want to force them in to the Xcode project mold.

So specifically what we're talking about is community development. This might be development with all of the different scripting languages that have come out, from Shell scripts, to Perl scripts, to Python and Ruby. It might involve Java development, and targeting the Java platform. It typically involved open source development, although not always. That would be development targeting, say, auto conf, configure, make, and so on.

It even covers non-open source, traditional UNIX style development. There are a lot of people with very large code bases that are built for traditional UNIXs that are really drawn to Mac OS X because of the strength of the user and developer experience on the platform, that still have these large code bases, but they want to use on Mac OS X. So what we're going to cover is how the Xcode Organizer works, and how you'll work with it to enable all of this kind of development.

How you can create your own templates for the Organizer, and put actions in them that you can use with that template to enhance the Organizer so it can build your kinds of projects. And specifically, what the Organizer can do for you in different types of development, specifically in native Mac OS X development, because it adds some value there too, plus build-free and scripting development, and community development built around external build systems.

So let's dive right in, and start talking about how the Organizer can help you when you're working with native Mac OS X projects. Now a native Mac OS X project is one that you're going to build something with that you're going to deploy to Mac OS X users.

And these projects are going to be using Mac OS X native technologies. Technologies like Carbon, Cocoa, they might be applications, they might be plug-ins, they might be enhancements to our pro applications, and so on. Typically you'll be using native tools along with Xcode to work on these projects.

You'll be using tools like Interface Builder and X-Ray. And even when we're working on these types of projects, which are already very well supported in the Xcode environment, there are a lot of issues that we might run into. For example, a lot of people, including us at Apple, have a lot of inter-related Xcode projects. We have a bunch of projects that we need to work with to work on one particular product.

So we might have applications that have a bunch of frameworks. We might have whole suites of applications that are all related and share some common code, and we might also have plug-in based applications where most of the application is implemented in terms of plug-ins that need to be related back to the original application. All this means that we'll probably have a large number of Xcode projects that we need to work with and integrate with.

And it can be really hard to keep everything you need close at hand, typically, in this kind of environment. You wind up creating, say, folders full of aliases, which you put on your dock, or you put things on the desktop, or you just have a folder that you know to go to, and you start using the Open Recents menu item, except the Open Recent Project menu item only holds so many items, so you go in and turn up the volume on that setting, and then all of your applications have very large Open Recent menus. It's just kind of inconvenient. So with the Organizer, what we have is essentially your dock in Xcode, so you can put your Xcode projects on it, put your related resources on it, and work with them straight from the Organizer.

So what we're going to do is a simple hands-on example using one of the developer examples that's already on your systems. I know the slide that you saw as you were coming into the room said you needed to go to connect.apple.com and go to the WWDC 2007 attendee site to get the materials for this session, but actually you don't need to do anything to have the materials for this session other than boot into Leopard and launch Xcode 3.0, because everything that we're going to do is actually part of the developer examples, or is something that we're going to do from scratch.

So the example code that we're going to see comes from the PictureSharing foundation example. It's actually a pair of examples. One is PictureSharing itself, which is a Bonjour example which shows how to share a simple picture using the foundation Bonjour APIs, NSNetService and friends, and the other example is PictureSharing browser, which shows you how to use the Bonjour APIs to browse for pictures that are being shared by PictureSharing. We won't actually be running this. I'm just giving you sort of the overview of what these examples are about in case you're wondering. What, instead, we'll see is how we would work with these in the Organizer itself. So let's go hands on.

We can see up here we have our normal Mac OS X desktop, and if we switch to Xcode, we can open the Organizer. Now, the default Organizer has nothing in it, and I've heard some comments already this week about, well, what is what is this window? What am I supposed to put in it? The answer really is anything you want.

Anything that will help you in your work. So let's first go to developer examples foundation, which is the folder that contains the PictureSharing example. And Norbert is just putting this into column view so we can easily see the path down there. And let's create a folder on our desktop called PictureSharing.

We don't necessarily want to work with the examples right in the examples folder. It's always good to drag them out before we actually start working with them in case we make modifications. Then we still have a pristine example in our developer folder. So we're going to drag out the PictureSharing and PictureSharingBrowser examples, and copy them into the folder that we just created on the desktop. And now we're going to drag that folder into the Xcode Organizer.

And we can see that we've added a folder to the Organizer. It looks sort of like an Xcode project, and it has a disclosure triangle next to it. If we just option click that disclosure triangle, like every disclosure triangle, all of the things beneath it will be shown.

And you can see that we can highlight things. Down at the bottom of the window, we have some controls that let us do things like show some actions that we can apply to the selection. The one to the left of it, the plus button, lets us add a new item to the Organizer, and we could have added the folder that way.

By just clicking that it would bring up a sheet, and we could select the folder that we wanted to add. And there's also a button that lets us toggle the embedded editor. So we've embedded Xcode's text editing environment right into the Organizer, and if you want to, you can edit right there instead of in separate windows.

Also, along the top of the Organizer we have a few action buttons. And these are buttons in the toolbar that also act as menus. So if you click and hold on one of them, you can see that there are no actions defined for what Norbert has selected. And you can also see that, for at least some selections, you can edit an action as well. We'll talk about what that does a little bit later. For right now, though, we're just going to build these two projects. So first, highlight PictureSharing, the Xcode project, itself, and just click the build button.

And what this does is it invokes Xcode's build infrastructure, and it will build that project. And you can see, if you have your build folders to show up in your project folder, that it's created a build folder right in the Organizer. Unlike folder references in Xcode, when something changes in the file system, and you have that open in the Organizer, you see the changes reflected immediately. If we were to go into the finder and rename something, those changes would show up immediately in the Organizer. Now we can just go to the other Xcode project, and we can also build that.

And this makes it a lot easier when you have to deal with multiple Xcode projects at once. You can even just put the projects themselves directly in the Organizer, rather than the folders that contain them, and you can just go down the list and say, okay, I want to build this one and this one, and now I'm going to double click this one because I'm actually going to work with it and manipulate the project.

We could even, if we wanted to, go into some of the source code, using the embedded editor, work with the code, change it, highlight the project, click build, and our project would build. We wouldn't have opened the project in Xcode at all with that overhead. So let's go back to slides and talk a little bit about what we've learned.

Oops. Okay. So what did we see? Well, we saw that the Organizer lets us keep frequently used resources, such as projects, really handy. Aah, I didn't show you one thing, though. Let's go back to the demo and see one of the coolest things about the Organizer. It's always good that this happens early in the presentation, right? So we've also enhanced Xcode's find in folder functionality.

It used to be called find in project, but if we bring down the edit menu and show the find menu underneath it, we can see that it's called find in selected Organizer item. Or find in selected Organizer folder. Excuse me. So if we bring up that panel, we can search for, say, NSNetService.

And just click the find button, and we found all instances of NSNetService, which is the standard Bonjour advertising and browsing class, in the folder that we have selected in the Organizer. Now we can even close that up well, first we can control click on one of the results, and it will take and we see a reveal in Organizer item. We can choose that, and it will bring us right to that item in the Organizer. If we were to show the embedded editor, and then do that, it would take us, even in the embedded editor, right to that line.

The other thing we can do let Norbert show that in a second. The other thing we can do is close the find in Organizer folder window, get rid of our selection entirely, and then go to the edit menu and look in the find submenu. Now we see just find in Organizer.

What this will do is find across all of the items in the Organizer. So right here, we can even say do a regular expression find. So we want to find all of the things that start with NSNetService, and we can just change the find type to regular expression, and then click find.

And you can see that we find results such as picture and controller from the PictureSharing project, and we find results such as let me see here. I think there's a pic browser controller in there from the PictureSharing browser project. So we've searched across multiple projects, multiple folders at once.

So if you have a set of folders that you want to search against, you can just drag them into your Organizer, and then just do a search in Organizer. And you can even bring this up by choosing by just pressing command, shift, F, in Xcode, with the Organizer in front. This time, let's really go back to slides and talk about what we've learned.

So of course, we've already seen how we can keep frequently used projects handy in the Organizer. But we can also use the Organizer for our easy find in project, and find in folder functionality. And we can find across the entire Organizer. And especially if you have a lot of things to search against, the enhancements that we've made to the multi-file find in Xcode, combined with the Organizer, can really make it useful.

You'll have no more, you know, going to the terminal, and going to the folder that you want to search, and figuring out the right syntax to use with graph to make it search recursively or non-recursively. You can just use the Organizer, and do all of this in a very natural, intuitive way.

And before we go on, just drag the item that we've added to the Organizer out of it. Just like you would the doc. And you can see it disappear in a puff of smoke. It won't actually disappear from disk. It's just being removed from the Organizer. But that will keep the Organizer clean for our next demo.

So the next thing we're going to talk about is how the Organizer can really help you with what we call build-free projects. Now these are typically scripting projects, and scripting has always been extremely popular on the UNIX platforms, and the UNIX drive platforms like Mac OS X, and it's really been coming into its own lately, with technologies like Python and Ruby. And script based applications are more and more, and progressively more common.

And they're also getting bigger. And as they get bigger, it gets harder and harder to organize them. So a lot of the project management functionality that Xcode offers might actually be useful for these types of scripting projects, but Xcode projects themselves are really targeted towards building, towards the traditional C style compile, link, build, run, debug cycle. Whereas most scripting projects, you can just edit and go. And the Organizer really supports you in this. It gives you just enough Xcode project-level functionality to make your life easier when working with scripting projects, but it doesn't impose the heavyweight build paradigm on these projects.

So what we're going to do is a simple example of Ruby unit testing. In our developer examples folder, we actually have a bunch of Ruby examples, including both Ruby and Ruby Cocoa examples. And under the Ruby examples themselves, we have some examples of the Ruby unit testing framework that comes standard with Ruby itself, and therefore with Mac OS X. It's called test unit. It's a really cool framework. And, for some reason, in our developer examples folder, there are actually two Ruby folders on the path to it.

So what we're going to do is see what that edit script, edit action item in the Organizer's pop up menus meant, and we're going to see how we can use the Organizer to run existing scripts from disk. So let's go hands on. And we can start figuring this out. So the first thing you'll want to do is to navigate through your developer folder to developer, examples, Ruby.

There's no oh, thanks. Okay. There is so developer, examples, Ruby, Ruby. And under that, towards the very bottom, you'll see a test unit folder. Now we just want to drag that entire folder to the Organizer. And if we open that folder up, we can see that there are just a few simple Ruby files inside of it, and these show how to use the unit testing framework that comes with Ruby. We're not going to talk in depth about that part of it. Instead, what we're going to see is how we can actually run some of these.

So the first thing we're going to do is show you that yes, this really is Xcode's editing infrastructure. You see that when we open the embedded editor window, and we highlight one of the Ruby files, that we have full syntax coloring for Ruby, just like we would in an Xcode 3.0 project. And we even have, in the function pop up, all of the functions that are defined in this file, the classes, and so on.

Now say we want to actually run this unit test. Well, there's no easy way to just do this without going to the terminal in previous versions of Xcode. But now, we can go into the action, the gear pop up button, and choose edit actions. And what this does is bring down an editing sheet that allows us to associate actions with the test unit folder.

It's not actually putting anything in the test unit folder. It's just associating them with the test unit folder. So all of these actions are associated with the Organizer itself, and you don't have to worry about cluttering your folders up with things that, say, the build system that you're using might not understand. So the first thing you'll notice is that we have a table view on the left of this that lists action names, key bindings, and has a couple of buttons below it for adding and deleting items.

And then to the right, we have an editing area, and we'll see that in a minute. And we also have a couple of pop ups for choosing where we get input and output, and we'll also take a look at that. So the first thing to do is add a new text script.

You can see that this adds an item to the table at left called text script. And we can just rename this to run, to just run. And you can see at the right that the script already has some boiler plate in it. It's going to be just a generic shell script by default, a born shell script, and it already comes with the shebang to tell the shell or to tell the operating system how to run this. And we can just type in some text in here to invoke the Ruby interpreter with the test tc_adder.rb.

Now if we look at the pop up menus above and below the text field, or the text area, we can see that we can take our input from different places. For example, we can take the input that we provide to the script from the current selection, or we can say that the script has no input. Since this script was just going to invoke another script, we're going to tell it that it has no input.

Below that, we can see that we have a pop up menu that says what directory this script is going to execute in. By default, it will execute in the script in the directory that it's defined on. So for example, we're defining this script on we're defining this action on the test unit directory, and that lets us associate the action with that directory.

But if we had a large directory hierarchy beneath test unit, we could actually define an action on test unit, and invoke one of those actions on a sub-directory, or on something far below it. So we need to tell the action infrastructure where we actually want to execute the action. What context we want it to execute it. And that's what this menu allows us to do.

Below the script, we have options for where our output should go. Of course, in the UNIX world there are two kinds of output. There's plain output, and there's error output. And, of course, we can choose independent options for each. We're just going to send our output for this one into a new document, and we're going to merge any errors that occur into the same output.

So let's click OK, and if we pull down the action button now, we can see that there's a run item under the test unit item. We use a disabled item to indicate that there's a folder that has actions, and then underneath that we have an indented item that represents the actual action.

And, of course, you can add hierarchy yourself to the actions that you define through the editor, just like you can through the user script editor. Now if we choose run, we can see that we ran the script, and the script ran the unit test. It finished in two ten-thousandth of a second, and it had no failures.

Now let's see what this looks like if we were to run it and show the output in an alert instead. For example, you might do that if you, you might choose to do that for errors, so you really get noticed or so you really notice if there's an error when running something, but you can only half pay attention if you're just running these as a normal course of business.

You know, if a window pops up, you can say OK, everything's fine, just close it, and go on. So let's go back, edit our actions. We've got the run item already highlighted. We can change its output to display an alert. Click OK. And now if we invoke this again, it shows in an alert panel titled command output.

Now let's say we want to run a whole script through the Organizer. We don't necessarily have to create a shell script that turns around and then invokes that script again. Instead, we could just add that script directly to the actions menu. So let's open the actions sheet again, and go back to the finder. And at ne level above test unit, under developer examples, Ruby, Ruby, we'll see an item named test.rb. This runs a larger suite of tests against the Ruby interpreter itself to test things like assignment.

And it's a fairly comprehensive test suite for Ruby. It's not too big. It doesn't take too long to run, but you might want to run it directly rather than having a shell script run it indirectly. So we can just grab that in the finder, and drag it directly to the table at the left of the edit actions sheet.

That will put that that will put a reference to that script right in the edit actions sheet. If we were to change it on disk, it wouldn't it would still be those changes would be reflected in the would be reflected in what gets run. If we highlight test.rb in the table, we can see that instead of showing an embedded editor, it shows us the path using the new Cocoa path control.

But of course, we can still choose where to send its output, and where to send its error output. We can tell it where to get its input from, and we can tell it what directory it needs to run in. So let's just click OK. And then we can run this script.

And we can see that we get a whole bunch of output in a new Xcode window. And a lot of the tests passed, and there's some error output at the top. That shows us that, in fact, error messages are being merged with the with the script output itself. Those error messages are harmless. They're basically saying, hey, you're running this from a write-protected directory, because it's actually being run in the developer examples directory, which, by default, is owned by root. We can close this window, and talk about what we've learned.

So let's go back to the slides. And what we really saw in this example is how to work with the command editor to create new scripts and add scripts that we already have, and how we would change command input output error settings, and so on. And one other thing we can do is look to Xcode's user scripts menu as an example. The user scripts menu, the edit user scripts option at the very bottom, uses exactly the same editing sheet. It gives you the same kinds of options, and it gives you the same embedded Xcode editor for editing your scripts with full syntax highlighting and so on.

And it gives you a lot of good examples of the syntax that you need to use if you want to, say, extract the text selection from the selected item in the Organizer. There is a there is some syntax for doing that. It's something like %%%[pbxfilename]%%%, something like that. I always just look at the examples in the user scripts menu. And we've got a bunch of them.

So that's great, but what if you want to do a lot of repetitive actions? Like let's say that you always create a lot of similar items. You create a lot of command line tools. You create a lot of simple Ruby projects that might have one, two, three Ruby scripts, that might have some actions that you want to perform for building, that might have some actions that you want to perform for unit testing.

Well, we have a template mechanism in the Organizer that's a lot more lightweight than the Xcode project template mechanism that a lot of people have figured out how to use. We can use this through the action button at the bottom of the Organizer under the new from template menu item.

And what we've done with templates is just allowed them to be folders that are copied with some very, very simple substitution. When you create a template, it's just a folder that you put at a certain location in the file system, and the name that you give it is what shows up in the menu.

Once you instantiate that template in the Organizer, the Organizer will ask you to pick where you want to instantiate it, where you want to create a copy of that template, and what name to use. And then it will go through any text files in your template, and wherever the name that you used for the template appears, it will replace it with the name that you've used for the that you've specified for the new folder.

So it won't change the names of the files that are copied, because for some build systems, some project systems, that really makes a difference. For example, Java. Java always wants the Java file named the same as the class inside of it. So we don't really want to mess with file names or anything else. We just want to give you a mechanism where you can say, this substitution is safe.

So how do you tell Xcode about your Organizer templates? Well, you put them in Xcode's new application support folder. Because we have co-existence technology now, you'll need to put this in your own library folder, or your machine's library folder, rather than under /Developer. And since we can have multiple co-existing versions of Xcode, you'll probably want to put this under the Developer/3.0/Xcode folder within your library application support folder, as opposed to the developer shared Xcode folder. Now you'll probably already, if you've run Xcode 3.0, have a library application support Developer/3.0/Xcode folder itself, but you won't have the necessary Organizer templates folder underneath that. So you can just create that.

The items within the Organizer templates folder are going to be folders themselves, and they're going to be folders representing categories. Organizer templates are always in a category of some sort because we've found that, by and large, people do like to categorize things. So we've given you one level of category of hierarchy for these categories. You can say, these are my command line tool templates. Or, these are my Ruby templates. Or, these are my Java templates. And within that, you can put your templates.

And we already have a bunch of Java templates on your system that you can look to for examples. They're in developer library, Xcode, under Organizer templates. So what if you want to provide commands for these templates? Well, for certain kinds of projects, Xcode will actually sniff out that they are that kind of project and supply some default commands. For example, if your template, or a project that you drag into the Organizer, has a Makefile in it, or has a configure script in it, Xcode oops, sorry. Xcode will say, hey, this is a Makefile based project.

Or, this is an autoconf based project. And it will populate the build, the clean, the run, and the action menus with some default actions. It won't necessarily look inside the Makefiles and figure out what the targets are, and what the executable is, and so on, because that's almost an intractable problem. But at least we can provide some template actions that get you started. For Java projects, too, we can look to see if you have an Ant build.xml file, and if you do, we can actually look to see what its targets are, and generate build commands for those.

However, if you have your own kinds of projects, you'll probably want to supply some default commands when you create Organizer templates for them. So what we've done is come up with a simple syntax for what we call "xccommands" files. And these what you just specify in an array of dictionaries, a set of commands that will show up under the Organizer when under the Organizer's toolbar buttons when the template is instantiated. And what's more, they're copied, rather than referenced, so the user who creates who instantiates their template, can then go in and modify them without actually modifying the template itself.

So of course, all of this is done by name. And the name describes the toolbar item that the commands should be associated with. For example, if you have a build.xccommands file, the commands within it will show up under the build button in the Organizer toolbar. And we've already talked about how they act as a template, where the changes are kept with the Organizer, and not written back to the original file, or to your template.

As I said, the syntax for command template is just a simple property list. It's an array of dictionaries, and you can create it using either the old style, or XML plist format, using any text editor you like, such as the Xcode built in text editor, or you can use property list editor if you're more comfortable that way.

There are three properties that are required for a command for an individual command. In particular, you need to specify the name of the command, and that's what will show up in the menu item itself. And you actually there are two required properties. There's an or there. And you need to supply either a script or a path. Now the script is the text of the script to associate with that command, and the path is the path to an executable to run for that command. And that path is relative to the location of the xccommands file when it's when your template is instantiated.

There's also one optional property that you can supply for a particular command, and that's directory. And that can either be a path that's relative to the commands file, or it can be one of several constants indicating that you want the command to run in whatever the directory of the selected item is in the Organizer, that it should run in the topmost item of the directory of the topmost item in the Organizer that that command is associated with, that it should run in the directory in which it's specified, that it should run in your home directory, or that it should run in your root directory.

So here's an example. We see here that this is just an array of two dictionaries. One specifies a command named build for debugging. And this is just the this is effectively what you would get if you just went into the build menu and chose edit actions and added a new text script named build for debugging.

We can see here that it has a name. That's what will be shown in the Organizer. It has dot for a directory, indicating that it will be run in the directory in which the command's file is located. And it has a script, which is just the text of the script to run. We can see that that script ends with \n. And that's because we actually want to put that new line in the script. If you want to put new lines, quotation marks, or tab characters, or other characters in the script, you'll need to quote them.

Our second command here is very similar. It's called package for deployment, and it, too, runs in the directory in which it is defined. But instead of being a script, it's a reference to a script outside via xccommand's file itself. Instead it just references a script in the script's folder at the same level of the file system as that xccommand's file. That is named package for deployment. And this is the kind of Ruby script you might write to, say, put everything in the right place on a disk image, generate a disk image, and then upload it to your web server.

So let's say that you often create very simple command line tools. I know I do when I'm figuring out new low level APIs. I like to create a command line tool where I can just say, okay, I'm going to use this one API. I'm going to maybe create just a couple of files. One is a wrapper, and one where I really exercise the API.

Now, I'll create one or more source files, and I generally won't bother with creating a whole Makefile for that, or with creating a whole Xcode project for that, because that's really kind of heavyweight. Instead, I just recompile everything every time. But sometimes I get myself in trouble, because I either edit my command line wrong, and I wind up not compiling something I should, or what have you. So it's really handy to have a template to do this with.

So let's go hands on, and see how the Organizer can help us with that. The first thing we're going to do is create a directory to represent our template. So we're just going to create this in the finder, and we're going to call it my tool, because this is my type of command line tool. And then we can drag that folder to the Organizer, so we can actually use the Organizer to build things for the Organizer. It's a little meta.

Within the Organizer, we'll just push that down and create a new file inside of it. And now we're going to go to the finder and rename it, just so we can see that as we change things in the finder, they're reflected immediately in the Organizer. We're using the great FSEvents technology in Leopard to do this. I have to tell you, it's really cool. It just works.

So we're going to name this mytool.c, because it's going to be the simple template that we're always going to start from when creating a C command line tool. Now if we we say add to the are you sure you want to add an extension alert that we get. Of course, on development systems, typically you'll turn that off. And we can highlight the C file itself, open up our embedded editor, and just put some boiler plate, hello world, type text in it.

So we'll just include standard I/O, put in, say, a main declaration that we would have standard in C, and say, let's put in a printf of the name of the Organizer template that we're creating. We're just going to say my tool, just like we did in the finder for the folder.

Of course, we have to return something, because this function has a return value. And we can save. And of course, we do get all of the normal syntax highlighting, and function pop ups, and so on that you would get from any Xcode project within the Organizer, too. Now, let's create another new file in our folder here.

We can go back to the finder and rename it. And we'll name this one build.xccommands. Now if we drag now if we pop open the embedded editor again, we can just create a very simple array of dictionaries, so put in parentheses, and a brace. That means an array in a dictionary, in the old style property list format. We can put in a set of key value pairs, starting with name equals, say, build.

Or build for debugging, actually. And we'll terminate each of these key value pairs with a semi-colon. We're going to say that we want this to execute in the directory in which the Organizer command comes from. And we're just going to put in the text of a script. So we'll just say script, and we'll invoke GCC -g. The -g is important, because that means generate debugging information.

And we're going to compile all C files, and we're just going to generate an executable named my tool. And we'll terminate that dictionary with a closing brace, and we'll terminate the array with a closing parenthesis, and we can save. Now let's hide our embedded editor, and find where we need to put this in the finder.

So let's go to our Leopard volume, and let's just go to column view, because it will be easier to navigate this way. And start with our user directory, and look in our library folder. Under application support, hopefully we'll all already have a developer folder underneath that. Under that is Version 3.0 for Xcode 3.0, and there's an Xcode folder under that for the Xcode IDE itself. And underneath that, you'll probably have a user script plist already to represent the items in the user scripts menu. What we're going to do is add, under that, a new folder, named Organizer templates.

And underneath that, we're going to add another new folder named my templates. And this allows you to categorize all of the different templates you create. So for example, if you have some templates for command line tools, you could name it command line tool templates. You could have a separate set of templates for Ruby tools, for Python tools, or for templates that you're creating for different clients, for example. There's a lot of flexibility here.

Now we can just drag our my tool folder directly from the desktop into that new folder that we've created, and we can go back to Xcode. We'll just leave this up on the why don't we go back to that window and leave it up on the screen so people can navigate.

We start with the home directory, we go to library application support, developer, 3.0, Xcode, and we can just leave that path open for people that need to navigate there. It is a little bit cumbersome to get to where we're going, but fortunately, we actually can get there. Now let's go back to the Organizer window, and let's look at that action menu at the very bottom. First, let's make sure that we don't have anything selected in the Organizer, of course.

And let's go to the action button. The action menu at the bottom of the Organizer, rather. And we can see our new from templates item has two sub-items now, one for the built in Java templates, and one called my templates. And that includes an item called my tool. That is the template that we just created. So if we select that, the Organizer will give us a sheet that lets us instantiate that template. And it says, Do you want, please name what you're...? Actually, I can't read that.

But it lets you name whatever you're instantiating, so let's call it hello world, and let's put it on the desktop. We can just pick that from pop up at the bottom. This is a full save panel, so of course, you know, you can navigate anywhere in your file system with it. But we have that convenient pop up at the bottom of it. And the Organizer has just created a new folder on our desktop for us.

And if we twist that down we can see that it has the contents that we were expecting. It has our mytool.c file, and it has our xccommands file. If we look under the build pop up item, the build toolbar item, we can see that it added our build for debugging command to the build item, and if we look at mytool.c, we can see that it replaced in the printf where we had been saying mytool, it replaced that with hello world, because my tool was the name of the folder, the name of the template.

It replaced it with what we decided to name our instance of that template. And if we wanted to, we could even go in and edit our commands now without affecting the xccommands file that's either already in this folder, or in the template folder. So let's go back to the slides and see what we've learned.

Well, we've learned how to create Organizer templates to automate a common task. And we've even seen how we can use the Organizer to do that. We've seen where we should put these items, and that they go under the Organizer templates folder in Library/Application Support/Developer/ 3.0/Xcode/ in your home directory, or they can go on your machine if, say, you share among multiple people. Or if you want to you know, if you just prefer to have it installed there. So you're providing an SDK to others. And we've seen how to use this template right from the Organizer.

So often you'll want to work with community projects. And these are projects from the outside world, from the open source world, from the UNIX world. And the reason you'll want to work with them is that there are a lot of different technologies out there, all over the place, and they are created by a lot of different people with a lot of great ideas.

And they are written in a lot of different ways. So rather than try to figure out how to cram everything into Xcode's project model, we really want to help these people get to Mac OS X with its best-of-breed user and developer experience without having to change the way that everyone's projects are built.

So most community projects use one form or another of a non-Xcode build system. They'll use make, they'll use rake, they'll use ant, they'll use maven. I've seen projects that use C-Make. There are all sorts of different options. And traditionally what you do is you work with files in the finder, you work with a text editor, you work with the terminal, you issue terminal commands to configure, to make, to make install, to remake, to remake as you edit some files. You remake it again to make sure that it all builds everything that it needs to. Maybe you issue a make depend to have all the dependency tracking happen.

Well, integrating all of that kind of work style with Xcode was really a pain, because Xcode really wants you to work on Xcode or Mac OS X native projects. But with Xcode 3.0 and the Organizer, it's a lot easier to use those action to use those action buttons, and to use just the file reference capabilities of the Organizer to integrate with these types of build systems.

So we're going to show you an example of how to do this using Java and and. And this works really well for these Java types of projects, because they already have their own world, their own way of doing things, that works really well, that they've tuned over the years for Java. So we're going to leverage that from the Organizer.

So let's go hands on and see what happens when we actually create an ant based Java project. Now I said we had some Java templates already as examples of Organizer templates. And you can see those in new from template, right in the action menu from the Organizer. So what we're going to do is just create a simple Java applet, and we'll put it on our desktop, and let's just name it hello applet.

When we create it, of course, the folder is created on our desktop that contains all of the Java files, the ant build script, and so on. Let's expand it in the Organizer to see what it actually laid down for us. And you see that it actually put down a folder structure.

Now let's highlight the Java file, and then pull down the build menu, just to see what's in it. You can see that it has multiple layers of hierarchy in it, so you can see that it shows the applet the hello applet directory itself has the ant, the ant compile, and ant jar actions on it, and then the source directory doesn't have any actions to find on it.

What this shows is that you can actually define actions on different levels of hierarchy, and whenever you define an action on a level of hierarchy, or whenever you have a selection, you can actually use the actions that are at that level, or any higher level, to operate on that selection.

For example, if you have, say, things that you need to do across your entire project, like get the status of something from your source code management system, you can put those at the very root of your project, and then invoke them on any item within your project, no matter what subdirectory it's in. Now let's just show the embedded editor, and you can see that we'll still have Java syntax highlighting that we have the pop up menu for our classes, and functions, and so on.

And let's just change the text that we're going to show from hello world to hello WWDC. I just want to show you that we're not pulling this out of the oven, that this is real and building live. Let's save the file, and go to the build toolbar item.

Pull it down and choose ant. And that does the whole build process. You can see that it brings up the Xcode build window, and it actually uses the Xcode build window, because that has a lot of knowledge about how to display errors and warnings, and if you actually get errors and warnings in your code that's being built through the Organizer, as long as those errors and warnings are generated in a fashion that Xcode can understand, Xcode will take you to the appropriate source code when you click on them, it will show the source code in the embedded editor in the build panel. It will show it can take you straight to a separate editing window, or to the Organizer, and it can even show you message bubbles in your source.

So we can see that this built successfully, and it added a bunch of additional folders to the Organizer, because it put a bunch of additional folders on disk. What we're going to do is just go to the disk folder, and we can highlight the HTML document that got put in there to contain our applet, and we can control click, or click on the action button to see the actions that are available on this.

Now, there are a couple that include reveal on finder, and open in finder. Since this is an HTML document, chances are that opening in the finder will open it in Safari. So let's just do that. Let's open it in the finder, Safari opens, and we see hello WWDC, because Safari ran our Java applet. We've created this Java applet without bothering with Xcode projects at all. Instead, we've just used the ant infrastructure. So let's go back to the slides and talk a little bit more about this.

We saw how we can integrate with the mainstream of Java development through the Organizer by intuiting what's available in an ant based project, and just running the ant scripts ourselves through ant. And you can really use this to work with any external build environment. So you can use Makefiles, you can use rake files, you can completely invent your own build environment. I've heard some people still use JAM, and in fact, JAM is a pretty cool environment. So this is a great way to leverage Xcode for a JAM based project.

Now one other thing that, at least I tend to do, is I want to get a quick start with a new language or a new technology. And, you know, the obvious case of this are the people who just get a Mac, they say, Okay, I want to learn how to program this thing. I've never programmed before, I'm new to programming, and where do I start? Obviously, we're not new to programming.

We're all developers, but in a lot of ways, whenever we do want to learn a new technology or a new language, we sort of go back to square one. And for really small projects, starting out by creating projects in Xcode feels like you're pulling out a really big gun. You know, you don't really want to you don't really need to use heavy artillery just for target practice.

But with the Organizer templates, and with the Organizer itself, Xcode 3.0 is a lot easier to use for getting started with this kind of new technology process. So let's just see what standard C 101 would look like when using the Organizer instead of the command line. So what we're going to do is just go through the process of printing hello world to the terminal, and then we've already done that once, and instead of using an Xcode project for that and figuring out, well, where do we start, what do we modify, what does all this stuff mean, how do we debug it, where what goes on in this huge thing? We're just going to create a folder, put some source in it, and go. So let's go hands on to the demo machine. And you can see that we've cleaned our Organizer out again. And let's just create a simple folder to contain our hello world example. Let's just call it hello. We can call it anything we want.

And we can drag it to the Organizer, like always, making it available to Xcode. And we can just put a file in it through the new file item. And we'll rename that to hello.c. And of course, the finder asks us if we really want to put an extension on that file. In this case, we do. Now, let's just use the embedded editor to put in sort of our standard hello world. So, of course, we include stdio.h. And all of the things that we saw before with adding a main function.

And we'll probably want to put the \n inside the quotes. Now we've got our standard C 101 program here. Well, what do we do with it? Typically a book that's introducing C programming, or something like that, will say, Well, you type at the command line gcc hello.c -o hello, or something to that effect.

Well, rather than pulling up terminal and figuring out where to CD to, and how to use terminal, and all that, let's just edit an action under the build item. We can create a new text script. Call it build. And we'll just fill in gcc -g hello.c, and we'll say -o hello.

Now if we click OK, and we go back to the build item and choose our new build action, we see that it builds. You show again, it shows us through the standard Xcode build window what it builds, and we see that we've gotten a dSym file, and that we've got a hello executable in there.

Now let's say we actually want to run that. Well, what do we do? Again, our book might say you type ./hello. Well, in this case, well, let's say that we want to clean up. You know, we've made some mistake, or we just want to be able to rebuild things first. Before we run things, let's make sure we know how to clean. So let's add an item to the clean menu item, and say clean.

And let's just make it rm - rf, or rm -f rather, that hello executable, and let's make it rm -rf hello.dSym. The dSym file is our debugging symbol information, and you'll see why that's important later. And actually that needs to be spelled with capitals. The last I believe SYM is capitalized. Yeah. So that way if we were to execute clean, we'll see, again, that it removed all the files that it had just added. Now let's rebuild it.

It built really fast because we're just invoking gcc once. We can go to the run menu item, and show Xcode or show Xcode's Organizer how to run this tool. So we're just going to create a new action under run called run. And again, we just create a new script command, but in this case, we're going to replace the entire contents of that script command with just ./hello. And this is because Xcode will interpret the contents of this script as a command line, and figure out how to run just this command directly. So we can click OK, and now we can choose our run command.

And you can see that it brought up our debugger's console. And unfortunately, due to a bug in X, in this release of Xcode, you'll need to resize the window a little bit to see its output. We're working on that. But you can see that it printed our hello WWDC. Now if we close this window, and we want to debug what we've just created say it didn't print what we wanted, we can just do the same thing. We can duplicate our text script.

We can name the new one debug, and we can replace its contents with what we would normally use to debug this on the command line. We can just say gdb ./hello, click OK, and then we can actually set a break point in, say, our main.c file. So let's say we want to break on printf. If we go to the if we go to the build menu, the build menu in the menu bar, rather than the toolbar, hmm. The run menu, I'm sorry. We can say activate break points, and now we should be able to put a break point in that file.

And unfortunately, the demo gods aren't smiling on us right now, and we're not able to actually set that break point. But if we do choose debug from our if we do choose debug from our run item, you can see that it is run through Xcode's integrated debugger. And if we had been able to set that break point, we would actually be stopped at that break point in the debugger right now.

And if we show the debugger console, which you can see at the right of the debugger window in the toolbar, just like last time, you can see that it shows hello world. Only this time, we ran gdb first. So let's go back to the slides and talk about what we've learned in this whole session.

So first, going back to standard C 101, we saw how we could really just get started fast. We could just work with the same kind of flow that we would normally have when developing on the command line, only what we're creating is persistent, and we can reuse it.

We can scale up the environment with your with our needs. So for example, I may start out by just invoking by just running what I'm trying to what I'm working on, but then I might start debugging it. Or I might start passing different command line parameters to it, and different situations. I can keep all of those things around. You can customize and write your own commands for anything that you put in the Organizer, and, of course, what you do in the Organizer integrates with the rest of Xcode, including the Xcode debugger.

So overall what we've seen today is that the Organizer really lets us leverage Xcode to work on community and scripting oriented projects. It opens up the world of Xcode to a lot more projects that would normally be handled on the command line, using the finder, using external text editors.

So it makes it a lot easier for these projects to come to Mac OS X, as they really want to, and take advantage of the best-of-breed user experience that we have when working on their code. And of course, we can see how the Organizer lets you scale up your use of Xcode, and Xcode's features with your project's needs.

For more information, you can contact our developer tools evangelist, Matthew Formica, and of course, we'll have documentation, sample code, and other resources on the attendee website. We also have a couple of labs, including an open lab, today at 3:30 where I'll be, and a bunch of other members of the Xcode team will be. And we have a developer tools lab tomorrow morning, as well. I'll be there, and a whole bunch of other Xcode people will be there. And you can certainly ask us anything you want about this.