Ladies and gentlemen, please welcome Technology Manager for Development Tools, Godfrey DeDorji. Good afternoon. Welcome to the Exploring Project Builder IDE session. I hope you've been having a great show. You've probably seen Project Builder in various other sessions along the way. In this session, we're going to talk to you about all the things that we've been doing over the past year with it. And to do that, I'd like to introduce Mike Ferris, the manager of the Project Builder team.

So I'm going to just get things started here, and then I'm going to pass off to one of the other guys in my group to run us through some demos. But before we do that, well, first of all, let's see what we're going to cover today. So we've just released a beta release of Project Builder, the developer tools in general. We shipped out a CD earlier this month, and there's the one that you got with your Jaguar stuff, too. I'll talk about that a little. But we want to really concentrate on some of the new features here while also giving you an overview of everything.

And just so that those of you who've actually used Project Builder quite a bit have something to not bore you, we're going to try to also point out some things that are lesser-known features that not everybody knows about, just to make sure everybody kind of has an idea of some of the more advanced stuff that you can do. So here's the itinerary.

I want to cover a little bit about the CDs that you have, talk a little bit about what will be after that. Then I want to go through some underlying project concepts that Project Builder uses. Then we'll have a tour of the IDE's feature. And then at the end, I'll come back and talk a little bit about future directions for PB.

So let's start with talking a little bit about what we've been doing, the CDs that you've gotten here at the conference. So first of all, there's the April 2002 Developer CD. This is an update, our normal sort of periodic updates of the CD. This CD contains a beta release of Project Builder, a beta release of the GC3 compiler.

You also have the Jaguar Seed CD, which is similar content. It actually has a slightly newer Project Builder than the one on the April CD. And then we'll talk just a little bit about what's coming after Jaguar. So, first of all, the April CD. Again, this is a beta release of Project Builder 2.0, which has some major new features that we want to get some input on you before, from you, before we finalize them.

We feel that the Project Builder 2.0 beta is quite solid, but like I said, we'd like your feedback on how we can improve some of the new features. Mike Ferris, Lance Saleme, Scott Tooker We feel that the Project Builder 2.0 beta is quite solid, but like I said, we'd like your feedback on how we can improve some of the new features. Mike Ferris, Lance Saleme, Scott Tooker before we call it finally released. We also have the GC3.1 prerelease.

So, you know, use the 2.0 IDE if it's working for you. If you like it, you know, build your projects and ship them. That's great. But don't, please, ship code that you've built with GC3.1 in this release. The Jaguar final release will have a GCC3 that we will, you know, be endorsing as what you should be using to build your code, but we're not quite ready for you to do that yet.

So once we get to the final release of Jaguar, That's when the beta will go away here. So we'll be shipping the final version of Project Builder 2.0. We'll actually probably call it 2.0.1 or something. And it will be concurrent with the OS release for Jaguar. And then after that, we'll be doing our ongoing periodic releases as we usually do.

So, okay, that's a little bit about the product roadmap. Now let me talk about some of the underlying concepts that Project Builder uses. And I know a lot of you are coming from other IDEs or other environments which, you know, have slightly different concepts. And I think that if you, you know, take some time to learn about the Project Builder concepts, you'll have a lot easier time sort of coming up to speed on how to use Project Builder effectively.

So these are the main concepts that I want to cover today. And these are the main building blocks for projects in Project Builder. We'll just dive into them one at a time. In the, uh, the main thing, you know, that you have in Project Builder is a big list of files that are going to be processed in some way. The files are organized as references and groups. References represent files that your project uses.

Actually, they can represent files that your project doesn't use too if you just want to have access to them from within Project Builder. You can organize files, you can organize these references in user-defined groups. These groups can match the structure of the file system folders or not. You can organize them basically however you want.

References use paths to refer to the files that they represent. There are basically two kinds of paths that a reference can use. It can either use an absolute path or it can use a relative path. And if it's using a relative path, it can be relative to a number of locations. It can be relative to the project directory as a whole.

It can be relative to the folder associated with the group that contains the reference. or it can be relative to your build results. So for instance, the reference to the app that your target builds is going to be a build product relative reference, which means wherever you choose to do your builds, that's where it expects to find that application.

The next major concept in Project Builder is targets. And targets are made up of build phases as well as build settings. A target defines how to build a project. actually how to build a particular product. A project can contain multiple targets if, for instance, you have a project that you want to build a framework and an application that uses that framework and then several plug-ins that the application might load. Each of those individual products will be represented by a target.

Build Phases is one of the concepts that is somewhat unique to Project Builder, at least possibly not familiar to people coming from other environments. Phases represent the steps that the target will take in order to build your project, and typically phases represent specific activities like compiling a set of source files, linking the resulting O files together, copying a bunch of stuff into your framework resources directory. We also have some build phases that allow you to get more custom. For instance, at any point in the target's build phase list, you can insert a shell script build phase that will call out and execute a shell script at that point in your build.

The other main thing that a target has besides the build phases is build settings. What build settings allow you to do is basically control options for lots of different things. Various compilers have build settings that they pay attention to that affect the options for the compiler, what flags are being passed. Same with the linker. There are other build settings that control the overall build process.

The build settings, you often have custom UI that tells you a little bit about what these build settings are to set some of the more common ones. But there's also a bunch of other settings that we will be exposing with better UI over time, but for now are often available only through an expert settings table. And there's a release note on the system that's linked to from the Project Builder release notes that describes in some detail all of the different build settings that are available for you to use, even if they're not represented by a specific UI in the target editor currently.

Here's another thing that is potentially a new concept to folks coming from other IDEs or from make file-based systems. I'm told actually that Visual Studio has a similar feature. Build styles allow you to customize the settings in the target. So instead of, say, duplicating your target and having two copies of your target that builds your application, one that builds it with debug symbols and one that builds it, you know, without debug symbols, for when you're ready to ship, you can set up one target that knows how to build your application, because after all, you're building the same thing both times, you're just changing a little bit the way that it's built.

And then you can define build styles that will actually override the settings and allow you to, you know, say, "Okay, well, when I'm building for development, "I'd like for there to be debug symbols, "but if I'm building to ship to my customers, "I don't want the debug symbols." You can use build styles to override or add to any settings that the target might have.

Build settings. You can't use build styles to alter, say, the list of files that are built by the target, but you can use it to deal with any of the build settings. And the override is dynamic, so as you change what the active build style is, the overrides are applied on top of whatever settings the targets that you're building have, and if you change it to another one, that's recomputed.

This is used for a number of different things. So I mentioned, you know, development versus deployment. You can also use it for special compiler options. You know, let's say that you want to try out GCC3. But because we've told you not to ship your code that way, you don't want to actually make the project use GCC3 all the time.

You'd like to be able to sort of enable that for testing purposes. Well, you can set up a build style that switches the compiler to GCC3. And then, you know, when you normally build, you'll use the old compiler. You'll be fine to ship your app. But for testing, you can choose the GCC3 build style and do it that way.

So the final concept that I want to cover here is executables. Executables represent things in the project that the debugger can run. So actually you can run them directly or you can run them under the control of the debugger. An executable is automatically created for any target that builds something that is directly executable. So if you create an application target or you create a Unix tool target, then you'll automatically get an executable that represents the thing that that target builds. But what if you're building a plugin? Let's say that you're building a Photoshop plugin.

Now that you can build Photoshop plugins using Cocoa and Mako and so forth, with all the great integration that the Carbon and the Cocoa guys have been doing. You build your Photoshop plug-in, but you can't just launch a Photoshop plug-in, right? You have to launch Photoshop and then load your plug-in. So you can create a custom executable inside Project Builder that points at the Photoshop that's installed on your system, and then when you say debug, it's actually going to run Photoshop in the debugger. When it comes up, you load your plug-in, and you can debug.

Executables, in addition to just pointing at the thing that they're going to execute, give you some control over the execution environment. So, for instance, you can specify command line arguments, or environment variables, and various other runtime options within an executable that will then take effect when you run or debug that.

And starting in Project Builder 2.0, executables are no longer associated with a specific target. So once again, you know, if I have an application target, an executable for that app is automatically created, but it's not part of that target, so the active executable and the active target are now separable things.

If I switch to make an application target active, it'll also make its executable active. But if I have 50 plug-ins and I switch between them, I don't have to define 50 custom executables, all of which run, you know, Photoshop. You can just have one of them, and it can remain the active executable as you switch between the different plug-ins.

So these are some of the main concepts that Project Builder uses. And I really encourage you to look at the documentation. We're adding more and more conceptual documentation to explain sort of what the underlying concepts are behind Project Builder. And if you take the time to become familiar with them, I think you'll be a lot more productive with PB. So enough of this boring stuff.

Let's actually see a tour. And to do that, I'm going to bring up Lance Saleme, who is an engineer on the Project Builder team. He joined us around WWC last year and is responsible for a lot of the multi-window UI you see in Project Builder 2.0. I also am going to introduce Scott Tooker, who is our QA engineer and part-time coder. He has been doing a lot of sort of polished bug fixing for us and is responsible for a lot of the new context menus. So take it away, Lance. Okay, thank you, Mike.

So I'm going to give you a whirlwind tour of a cross-section through all of the features in Project Builder. A lot of you are experts, but please stick with us because we're going to point out some of the new features as we're going. We're going to talk about the interface concepts and the multi-window UI. It has spent some time on accessing documentation, move on to navigating and searching projects, navigating editing code, using source control, and then talk about some of the build system features and new features, and then the debug and new debug features.

So let's move straight into the interface concepts, which is some of the biggest changes you'll see in Project Builder 2.0. The first thing you'll do as a new user or getting started with your project is to create a new one. You'll find a lot of options under that, and we'll see some of those in the demo. But you'll then move into using the project workspace window.

And for a long time, Project Builder has been a one-window interface, so you'll see all of your content and all of your tools combined together in this single interface with a simple animation to move between the pieces that you focus on, the pieces of the work that you're doing. They're broken down into the content tabs, which are along the left edge of the screen, and the tool tabs, which usually are across the top, and then the built-in editor itself.

Okay. Something new in 2.0 is the work we've been doing for the multi-window user interface. You've probably seen some of this already during the sessions, especially with AppleScript Studio. It was right before this. They heavily used the multi-window user interface to organize and work within the project for their demos. To understand how we decided to break out the windows for the multi-window UI, you have to have an understanding of the development tasks. And these are kind of arbitrary decisions.

And we've made some decisions on our part to break out all the various activities that you do, to build your application, to work with it, debug it, et cetera. So you'll see tasks related to the project, source editing, classes, targets, help, and then the fine building, debugging, and running pieces as well. Now, we can't second-guess.

We don't know everything that you may want to do with the environment and exactly how you want to set it up. We tried. Everybody gave us a different answer. It became impossible. It became impossible to try and make every possible window work and have preferences for every window. So you'll see that we have window templates. And these allow you to decide how you want to organize the tools and tabs in your windows for the development tasks. So we'll go straight into a demo, and I'll speak more about it as we're going.

cheat sheets here. So the first step would, of course, would be to open a new project. And you'll see that we have a lot of support for building Cocoa applications, Java, standalone UNIX tools and, and AppleScript Studio if you're using that. But for our demo purposes, we're going to start with an existing application.

And Scott's going to bring up the window, and he'll show you the traditional view onto Project Builder. So as you see, we have the content tabs for files, classes, bookmarks, targets, and the breakpoints. And then across the top, you have batch find within the project building, So, let's get started.

So, I'm going to start off by talking about the So let's take a look at some of the preferences that are new to 2.0, specifically in task templates. You're going to find that a lot of you are very happy with the user interface as it is, and we want to acknowledge that and keep a single window interface for you, so you're, you know, just go ahead and use it as you've always used it.

Some of you maybe want to keep more information about your build pieces as you're going, your run results, your batch finds, so we have a some windows option. which breaks those out into separate windows. But for the case of the majority of people and for this demo, we're going to focus on the many windows version.

And then we'll go in and edit that new template. And let's say you want to always have your breakpoints visible. Open up the breakpoints tab, size the column the way you want it. Resize the window the way you want it. You can hide and show other tabs if you find that you don't need them. At the bottom there you'll see that. So once he's got the window in the configuration that he's most comfortable with, He can then save the changes. And then any time a new window for debugging is brought up, it's brought up from that configuration.

Okay, so I think we're ready to go back to... I'm sorry, I should say, now that we've created, let's go back and actually reassign it. So you'll see that now his template is assigned to the debug task. Okay, I guess we're ready to go back to the slides.

So, one of the other common aspects of doing your development is to get to your documentation. Accessing documentation is quite well integrated into Project Builder. You'll find a number of access paths for it. You have the Help menu for accessing Help Developer Center, the Developer Help Center. Then you have Project Builder Help, Developer Tools, and Project Builder Tutorials, as well as Framework References, Release Notes, and Integrated Documentation features, which we'll talk about in the demo.

At this point, I'd like to give you a heads up on a new capability or a new feature that we're offering, which is a print-on-demand book called Developing with Project Builder. And this contains the Project Builder help and tutorials for those people who really want to have a printed-out version of the help available next to them while they're doing their job. Yeah. This is in conjunction with Vervante, and it will be available the summer of this year. See your URL down there at the bottom if you want to get some information on it.

So another major natural part of doing your development is navigating in the projects. Since we have multi-window UI now, there's a new impetus to have shortcuts and simple ways of moving between the windows to not stopgap you or to not slow you down and keep your progress moving. So we have some new menus and toolbar items to move between the various task windows directly.

In the case of the Class Browser, we have some more of the integrated documentation features where you can get directly to API documentation, and then if that Class Browser isn't set up exactly the way you want, you can create advanced options which isolate and filter out which pieces of the class hierarchy you're interested in seeing. As Mike mentioned, we have the Group Tree, which is your logical organization of files and frameworks.

So it's obvious that sometimes you'll want to be able to jump directly back to a file that you're working on, see exactly where it is in the entire project. So we have a shortcut which is Reveal in Group Tree. We'll show that in the demo. And then finally, it's not really new, there's some new features for bookmarks, though. There's the context menus pretty much everywhere that you're working with the file, so you can create a bookmark and have it available later on when you're moving between the other tasks.

Next we'll move into searching projects. This is a common feature of IDEs. You have the batch finder. Of course you have textual search and replace, but we have a very nice regular expressions search and replace we'll demo. And then we have definition searches, which help you get directly to the definitions of a particular symbol, and then jump from there to the API documentation for that symbol.

Something new in 2.0 is Documentation Search, and this is a natural language interface to all of the documentation available on the system for quick and easy access to look up something like hierarchical views on the fly. And if the defaults that we provided for you in the search process aren't exactly what you normally work with, you have the ability to bring up a dialog for find options to set up your controlling, to control your match criteria and also to limit what gets searched. So, back to another demo.

As you can see, we have the Help menu where the Project Builder Help Center is a natural part of it. And then you have the Frameworks. Scott Tooker, and Scott Tooker, who is the executive director of the Project Builder IDE team, will be joining us shortly.

And since it's a task, it can have its own window instantiated directly from the menu.

In here you'll see the overall hierarchy of your classes and methods, and your classes will show up in blue to give you some differentiation. But as you click on the various methods, you go directly to the source code in the attached editor. As for example, if you want to look at NSObject, you'll find that You have the ability to go directly to some documentation when it's normally available. Yes. Which actually points out something interesting to point out about 2.0 since I've made the snafu.

Unfortunately, you have to run the PB Help Indexer. This is only for the beta. This will be fixed for Jaguar Final. I'm not going to do it right now because it takes a little bit of time, and I don't want to waste time in the demo. But I just want to point people out, if they don't see the help books, just go ahead. It's in the release notes. You just have to run this one tool using sudo, and then you'll get all the help books, and you'll get your index. Okay, so we'll move on.

If you want to find out where the file is that we're looking at is in the group tree, just click on the file and do a reveal in group tree. There's another context manual shortcut for that. And that'll drill down into the hierarchy and get you directly to the file so you don't have to hunt and peck for it. And let's say you want to come back to this file regularly. Again, another shortcut for getting back to a particular method is to set a breakpoint on it.

Once this breakpoint is set, it will be available in the project window under the breakpoint tab. And you can jump straight back to where you were without losing a beat. Okay, so let's move on and bring up the Find window. As I said, we have the common standard textual search. We can bring up and look for Release Bracket, let's say. And this will give us all the places in the code where we're releasing objects.

Single-clicking on the result will give you a built-in editor view, and double-clicking on it will open it into a separate editor if you want a larger context. So, for people who want to go a bit further and have a lot more control over how their searches are done, we have the regular expression searches.

Scott's going to do a demo here where we do a search across the entire project for all the places where the copyright notice is. So, something that is done commonly every year when you have to update your source code copyrights. And then once we've found them, we can actually go ahead and change those copyright notices to the current year. Let's do that on just one of the files. So as you see, now we're up to 2002.

So, I'm not sure how much further we can go with the definition searches without the help, but let's go ahead and try. I guess we can do that. We can do that. Alright, so let's do a definition search for init with frame. And that'll give us all the places that Project Builder believes that there's information about init with frame.

: And in those cases where we did have, where there's supposed to be a book or where we have a reference in the documentation, you'll see a little book over here you can click on and bring up, just like we had in the previous release of Project Builder.

: For full documentation search, which is one of the new features in 2.0, you can type in natural language. Tell me everything you know about view hierarchies. If I can type, I will do it. And that'll cut across all the available documentation and give you a weighted result of the places that it's found for view hierarchies.

Okay, so there we go. And you can go directly to view hierarchy information. So... If the find results or the find criteria that we're using isn't exactly what you do normally, we do have the options dialog for you to be able to set up custom settings that you'll use regularly, and that will pop back into the pop-up later for you to be able to choose. Okay, so we'll come back to the slides again.

One of the common things you'll need to do is be able to navigate your code efficiently. Well, Project Builder tries to provide as many shortcuts as possible. We have a symbols popup that will be populated with all the information for the particular file you're editing, and there's some preferences for that we'll look at.

And then you have the counterpart toggle, which gets you directly to the related file source if it's a header, header if it's a source. And then you have the loaded files pop-up in history. Now this is a little different in 2.0 since we heavily use the multi-window aspect, and that means that every editor is only going to show you the history for that particular editor.

So if you have a file per editor, the history is pretty thin. But we can show you some other ways to use that. Next, there's the included headers pop-up. And this is a nice way to find out where your code is being included and what your code is including in the case of headers and source files. In this case, it will show you the headers for this file. Then you have some shortcuts for getting directly to the definition of a symbol. The command double-click shortcut on a symbol also for going to documentation, option double-click.

Next, we move into standard editing of code. We have some control over tab and indent widths, and we have since the December release syntax-ware indenting. And this is pretty useful if you're in a hurry and you want to actually have the editor help you finish code, put in the finishing bracket, format the file for you as you're going.

But in 2.0, one of the new features is the ability to assign an editor by file type. So for the people who had the issue of trying to have their HTML rendered versus having their HTML displayed as source, you now have some control over exactly how that will work for your files.

Of course, we have standard arrow key navigation and some of the standard Emax bindings for those familiar with Emax. If those aren't enough, you have the ability to set your own custom key bindings. And I know a lot of people on our team have a wide variety of sets, and it's interesting to see them navigate in a different way. Lastly, we have the file encodings and line headings. That's also per file if you want to have some internationalized files.

And then we have the source code control. So in Project Builder we're heavily integrated with CVS. That means you have a CVS menu always available to you if you have a CVS repository for your project. It has the basic operations for status on the files, updating, reverting, committing your changes, adding and removing files, and then the ability to do compares against the base of the head revision and against any two revisions arbitrarily. We'll do a demo of that. So we'll switch back to the demo.

So we'll bring up an editor window, and we'll take a look at the symbols pop-up. As you see here, there's a lot of direct symbol information that you can jump to. But if this isn't everything that you want to have available in the symbols pop-up, there are some preferences for it.

So you can have marks and www.microsoft.com/mechanics In the editor you also have the Counterparts widget, which I mentioned. This will take us to the header from the source and vice versa. That gives us two files to look at in the history. and the ability to move backward and forward.

Something that's not in Scott's script, but I wanted to show is if you want to keep this one window open and just keep editing in it without necessarily obeying all of the multi-window features, you can drag in a file from the file list into the editor and it will load in that editor.

and that'll give you the other pop-up entry for that new file. I think you pulled the same file in. Anyway. If you click and hold on the Counterparts button, this is where you'll get that list of all of the included headers and files that include you as a header. It's very useful for finding out how your code is tied together.

I think, I don't know, did you get the documentation reset? No, actually. Okay, so for going to the definition, we have that ability with a command double click, jump straight to the particular line of interest, and then hopefully we can option double click and go to some documentation. There's the one I want.

So, I'm going to show people one thing. Just the books. If you've never seen the books before, this is what they look like. And so, if I can double-click on a book, obviously it's going to come up. So, wherever you see that book, single-clicking on it will put it in the same frame. Double-clicking will bring it up in its own window.

You'll find that's a general rule across most of the multi-window UI. We've moved towards supplying some of the features of keyboard navigation, so you'll see some differences in how the lists operate. Sometimes the list will keep its focus in there, which is unusual for people who are used to it, switching focus to the built-in editor. But that's a different topic. We can go into that in the Q&A if you wish.

So, if you look at some of the preferences for editing, you see that you have the control over your tab widths and your line endings. And then for file encodings, and the syntax were indenting. You don't have to turn this on if it bothers you. If it gets in your way, turn it off. If you like it, leave it on. It's very useful. Next we have the per-file editor. And you can drill down and show you exactly where we've assigned editors to the HTML file.

So I guess the next step is to go back and look at some of the CVS integration. We have the CVS menu, as I said. The files in the project list, in the files and groups list will give you some hint of what's going on in the status for CVS. It has the modified flag updated, added and removed. All of the operations you want to do with CVS are usually available under the CVS menu.

Let's take a look at the The history for the file. So bring up the info panel on that particular file. You'll see the history of all the CVS check-ins that have happened or commits for this file. And this is where you can actually make an arbitrary choice of two versions. And, uh, Then go directly to comparing those and get a graphical UI view of all the changes on a per-change basis using File Merge.

Okay, so I think we'll go back to the slides again. We're on the home stretch. Stop orbiting. Okay. So we move on to building. This is where you spend a lot of your time during your development processes, building and debugging. So you can define targets and build styles.

Mike spoke quite a bit about that earlier. Your target editor gives you a view onto that set of rules or recipes for your project. And then you have the build style editor for doing the dynamic overrides of some of your target settings for debug versus deployment, as an example.

Some of the other shortcuts we've added into the toolbar but have been available in the menu is the ability to go directly to your active target or build style or executable. And then some build preferences that we'll see in the demo and I'll talk more about. And then we'll do the actual build and talk about some of the warnings and errors that we see as we're going through that.

So some of the new features, this is the things that a lot of people have been waiting to hear about for 2.0. We have the GCC 3.1 support. I'm sure you've heard that enough times already. I don't need to go into much detail. But to help you shorten your compile times, which is a major issue for Project Builder, you have the persistent front-end support now, which is pre-compiled headers, basically. But beyond that, we're going to try and bring this up to new features and new functionality to get even better turnaround time on your compiles.

Another little shortcut that we've added is the ability to duplicate your targets. If your project has two different versions that are different enough that build styles isn't enough, you can duplicate the entire contents of the target and then go back and edit it. Then we have framework variants.

Now, an important point of this is that you get one framework entity, but you can have multiple binaries in there. You can have a debug version, a performance version, and then your shipping version, and this is the resultant framework. Some of you who are Java people wanted some better UI feedback or better UI support for setting up your Java settings. That's in 2.0.

And finally, there's the script phases that can actually operate on your project after it's been built. So once you've installed or gotten to the point where you need to do some post-processing, you have the ability to execute a script phase. So that's good for cleaning up and doing other things.

So once you've got the project to build, you want to get your errors out, you move into debugging. We have the standard set of features you're expecting in a debugger: breakpoints, stack backtrace threads, popup, something that's pretty useful in 10 since your multi-threaded applications are starting to become very, very important. Variable lists with some new features I'll talk about in a second.

And then execution control as you'd expect for step, step, and two, et cetera. And then if what we're providing in the user interface isn't enough for you in the GDB world, you have a GDB console that you can go and type in commands directly without changing your context out of Project Builder.

So, the new features. Getting down to seeing what your actual data looks like. This is a very important feature for anybody who tries to debug and they need to be able to get past just the hex address of something. You'll see that the tip of the iceberg that we've provided, which is a step towards the full set, is now the ability to see NSString values directly in your variable list.

There'll be more coming, I promise you that. And now we have a new type column, which allows you to see on a one-to-one basis what each one of the types of your variables are in the context of the variable list. And then the ability for Java programmers to print descriptions directly to the console within the debug window.

And finally, if you want to set breakpoint, I'm sorry, set watchpoints on your variables, we're taking advantage of that through the page protection watchpoint support in GDB. This is a very quick and very useful way of tracking exactly specific changes to variables. So let's do the last demo.

take a look at the target editor. Well, for the observant, you'll find right away that this is not exactly what you're used to seeing. This is some of the new features that are going into the real Jaguar version when we're done. It's a hierarchical view. There aren't tabs anymore. And whenever you select a particular area of settings to operate on, that is what's compiled -- I'm sorry, that's what's assembled together in the editor panel to the right. So you have the ability to drill down to specific areas of the settings.

We also have the ability to go to the shortcuts for active targets, active build style, and active executable. You'll see those in the upper left corner of the toolbar. It's a nice way to navigate around quickly. So let's take a look at some of the build preferences. This is where you'd have the ability to set exactly where your target application will build and still keep your symbols and intermediate files separate. This is a global setting for Project Builder. If you don't override it on a per-project basis, this is where the pieces will go.

So we'll take a look at... If you check... If you bring up the info window on the project itself, this is where you have the ability, as I said, to override that location information. And this project will build in a different location if you tell it to. Okay, so let's do a build.

You see that there is a separate build window now, and the log information is available. You can collapse the panel if you want. You can edit the window to be exactly the size and form factor you're interested in. Now, we found an error, so when you click on the error, you go directly to that line in the source code. But if you double-click, you get your editor, so you have a larger context. So let's fix the bug and move on.

So now we're going to go into the debugging phase. As you see, this is the template that we defined. This is the new view onto debugging. So when we get to a breakpoint, you see how the information is organized. You have your stack frame, your variable list, you have your breakpoint tab open with the breakpoints that you currently have set in the application, and you have your threads pop up. Of course, you have your navigation controls for step, step into, step over, etc. And then there's a different one than most people are used to seeing, which is a restart, which allows you to quit and restart without ending your GDB session.

Now, some of the things you're going to see that I mentioned that are new are the view onto the string. You have your NSString content directly available in the variable list itself. It's very nice to actually see below the curtain, or below the sheets in this case. And it's going to turn on the type list column, so you can see where your actual variables relate to their types. And as we go back to the slides, That's actually it for me. I'm going to bring Mike Ferris back to give you some of the future directions. Thanks.

and good demos. Let me take this opportunity to mention, yeah, definitely read the release notes that came with, especially the Jaguar seed. As we saw there is the one glitch with having the index, the help so that PB can show the book icons. You'll need to do that manually in the Jaguar seed.

It should happen automatically in the April CD, and it will certainly happen automatically by the time we ship Jaguar. So I want to talk a little bit about where we're going with Project Builder. And I figured that really, I mean, All you really need to know would be our group's mission statement. And if you knew that, you'd know exactly where we're going. So here it is.

I hope that that answers all of your questions. All right. But, you know, let's dive down a little bit in some detail here. We get a lot of bug reports. We get a lot of ideas and suggestions from all of you who've been using Project Builder. And that helps us to figure out where we're going. We also have a lot of our own cool ideas and things that we'd like to do and provide for you.

Like every other team in Apple, we keep track of all of the bug reports that come in using our radar bug tracking system. Your interface to that is through the bug reporter site at the ADC. We encourage you to submit bugs when you find them, submit enhancement requests if you think you have a good idea as to what we can do.

You also may hear us talk from time to time if you subscribe to the Project Builder users mailing list about this list of features that we have. And you'll say gee, wouldn't it be great if Project Builder could do this? And we say yeah, yeah, that's on the list.

Well, there is a list. Just so you don't think we're making it up. This is part of the list. So, you know, I'll leave that up there for a moment, so if any of you, you know, see that your feature isn't on there, you can just shout it out.

There's only two items on here that aren't real. So, you know, as you can see, the point of this slide is that, you know, we have a lot of stuff that we really want to do and we really want to provide. And obviously we can't do it all at once. The Project Builder team is not huge, all right? And so we need to prioritize these things.

There are some major areas. Let me talk in a little bit of detail here. So that list was all fine and good. But we really want to support some plugin APIs in the near future so that you guys can actually help us to implement some of the things.

We want to expose plugin APIs for many different areas of Project Builder. Some of the key ones that will probably be coming first would be things like plugin build tool support if you have languages that we don't support and you have a compiler and you want to integrate it in Project Builder.

We'd like to support plugin editors so that, you know, you can do like the technical publications group that Apple did and provide a Project Builder plugin that reads HTML documentation or that reads whatever file type you want, that it can happen right inside Project Builder. The other way around on that one, we'd like to support an API that lets us use other editors. So if you really, really like some other editor instead of our code editor, we'd like to let you use it.

We also would like to provide APIs for new indexing engines for other languages, debugger plugins, SCM plugins, new preferences panes, new assistants, project templates, all this stuff. We want to do all of this stuff eventually. We're not going to do it all at once. And you'll see, hopefully in the near future, some rolling out of various plugin APIs that will let you guys get started with various areas of this stuff.

We have a lot of ideas for the editor and the indexer. A lot of those are related. We'd like to provide code completion. We'd like to provide some refactoring support. We'd like to provide you with the ability to edit your code from the class browser. You know, I want to be able to select an inherited method in my class and say, "You know what? Override this." I want to be able to select a class and say, "Make me a category on this class," or "Make me a subclass of this class." All of this stuff, we'd really like to be able to do this stuff.

Lots of stuff in the build system that we'd like to do. We showed you the new target editor, but that's still showing you a sort of a process-oriented view of things. You have to tell us the steps to build your target. Ultimately, we'd like to provide another view.

We'll probably have both, so you can switch between them. We'd like to provide you another view that allows you to, instead of so much telling us how to build your thing, tell us what your thing looks like. And then we'll figure out what the steps are to build it.

We'd like to provide more feedback if you have a target and you're looking at the build settings and one of those settings would be overridden by the current build style, you should be able to tell that by looking in the target editor. You should be able to tell what the value of a particular build setting would be if you hit the build button right now.

You should be able to tell what files need to be rebuilt before you build. You should be able to, you know, have some way of looking at a build setting and not only say what its current value is, but how it got that value. You know, it started out with this in the target and then the build style added this thing, and, you know, the product type that you have selected added these other flags. That kind of stuff, we'd love to expose that.

Lots of areas for improvement in the bugger. We'd like to add, you know, a lot more of this opaque data type viewing, which the NSString value, you know, in the variable list is just the beginning of. We'd like to add support for, you know, watch expressions. Actually, we've got some support for that that'll be shown in the debugger session. We'd like to add memory inspection windows and register windows, and there's lots of stuff in the debugger we'd like to add.

There's lots of stuff all over Project Builder we'd like to add. We're really proud of what we've done with Project Builder, but we know that there's a lot more stuff that we could do. And I think that, you know, we're, as a team, very enthusiastic about doing all this stuff.

So the point of this is not to say, "Yeah, all these things I'm talking about are coming tomorrow." In fact, it's more the opposite. What I'm saying is, there's so much stuff that we want to do, it's not all coming tomorrow. And, you know, we can't really say when specific things are coming because we don't often know too far in advance. what the most important things are gonna be. But you can help us decide.

We do, you know, listen to external feedback. We listen to internal feedback. A lot of people at Apple use this stuff. Often the needs for internal and external developers are the same, but sometimes there's some very specific need for internal developers. We have to factor all that in. We also occasionally have stuff that's going on with Mac OS X as a whole that's some new thing that's going to need Project Builder support. And so those platform initiatives also feed into how we prioritize.

From your point of view, though, the very important thing to keep in mind is that if we don't know about something that you'd like to have done, we can't prioritize it. So be sure you report bugs when you find them. Be sure that you file enhancement requests. Use Bug Reporter if you also want to use the Project Builder users list or the Mac OS X tools feedback list to sort of, you know, get some community reaction to, you know, whether your suggestion is a good one. That's all fine, but definitely use Bug Reporter.

So I hope we showed you some good improvements today. And I hope that, you know, we'll be continuing to prove this stuff for you as we go along here. And that's the end of our prepared program here. And now I'm going to ask Godfrey to come back up to run us through the road maps and so forth, and then do the Q&A. Thanks.

Thank you very much, Mike. What do you think, everyone? - Hey everyone, do you think they've done a great job? Okay, the slide on the screen is showing you more information sources about Project Builder, about our tools in general, including the address for the bug reporting page, something that if you have a concern, if you have an issue, you should definitely go to the bug reporter and send it to us. We need to know this in order to prioritize and build our new feature list.

A roadmap to sessions to come in the Tools track tomorrow afternoon using Interface Builder. For those of you who are just beginning to get involved with Interface Builder with nib files, this will be a very, very good session to introduce you to the concepts and the means of working it. Apple Performance Tool. In addition to Project Builder and Interface Builder, we also supply on our CD in our Tools package a suite of performance tools so that you can optimize and make your applications perform at their best.

On Friday, we go into great depth in Project Builder to talk about how you actually deliver applications, how you can get the most out of the build system. A very, very good session. I highly recommend that you come to that one. And of course, Friday after that session, we have our development tools feedback forum. We'd love to hear your feedback. I believe most of the team will be there at the session looking to listen to you.

For contacts, I in technology management remain a single point of contact if you have specific needs. If you're looking to move to Project Builder, if you're looking to integrate something into Project Builder, I'd like to hear about it. I can help work a relationship with the team as necessary.

We have a set of mailing lists. The master address here includes Project Builder users, which allows all of you to collaborate with each other as well as with us. We get a lot of input from this. We try to put a lot of input back. And sometimes you can actually help each other get your problem solved.

And we also have the development tools engineering feedback address. This is if you have an issue or a feature request that you'd like the entire engineering team in our tools development organization to know about, this sends your message to us internally without broadcasting it to the world. So this is often a way for you to get in touch with the right people. We all monitor this on a daily basis and try to give feedback and try to give responses on a very timely basis. very timely basis.