Good morning. My name is Henri Lamiraux. I'm the engineering manager for Interface Builder. In the long tradition of Interface Builder, I have a French accent, so hopefully it will be okay. This is the plan today, or what we're going to be talking today about. I'm going to be introducing what is Interface Builder.

We're going to go through what's new in Interface Builder, and also our short-term goal, which is what we are working on today. You're going to see very soon. And our longer-term goals, which is what we're thinking about doing for the future release of Interface Builder. First of all, I'd like to know how many people here have never been using Interface Builder. I hope next year.

There will be no hands because Interface Builder is Apple's Interface Builder tool. We have only one tool at Apple to be able to create user interfaces for both Cocoa and Carbon, and this is Interface Builder. The big push also for Interface Builder is to be able to create a compliant Aqua user interface.

Here you can see we have one tool. Our tool creates what we call Nib file. I will talk about that later. And we can target Cocoa application, which was a traditional target for Interface Builder. We can now target Carbon application. The WebObject people are also using Interface Builder to create Java client application.

And as you can see at the bottom, we put, our big work this year was to create the infrastructure in Interface Builder to be able to support other platforms. The fact that we put Carbon support means that now we have this infrastructure in place to support other platforms.

And you will see that in the future. So a question, should you use Interface Builder? If you're a Cocoa developer, yes. You have to use Interface Builder. It is a big part of the development cycle. It makes it easy to use, outlet and action concept. You cannot develop in Cocoa without using Interface Builder.

Now, if you are a Carbon developer, it's yes if you're directly using the toolbox. If you are a hardcore Mac OS developer and you are using the toolbox, and you've been using a resource editing tool like Resedit, for example, to edit your UI. So if you are one of those developers, Interface Builder is for you.

If you are a framework application developer using a Power Plant or Mac App, I say maybe, but in fact, you may not want to use Interface Builder. Power Plant has its own GUI builder, Mac App has Adlib. We don't support those frameworks with Interface Builder. If you have a mix of toolbox in your Power Plant application, yes, you could use Interface Builder for the toolbox part of your app.

So I'm not talking about the advantages of Interface Builder for Cocoa, because they are obvious to Cocoa developers. But for Carbon developers, they have really good reason to use Interface Builder. First of all, it creates Aqua-compliant UI, which is important. In fact, it's the same thing for Cocoa developers.

It supports all UI elements. In the past, we haven't been able to really support all the new stuff we put in the toolbox. IB will be supporting all UI elements that you're going to find in the toolbox. Data browser, everything is there. It's also the easiest way to support the new Carbon event model. In Interface Builder, you can set your command, you can do everything you have to do to be able to support the new Carbon event model. This is a big plus.

It's also Unicode compliant because we're using XML for our file format, which means that you can easily localize your application. And it's integrated with the Apple Project Builder. This is also important. You're going to be able to work with them to facilitate development of your application. But for Carbon developers, we are not tied to Project Builder. You could use Code Warrior if you want with IB. The second topic today is what's new in the Carbon event model. interface builder.

So I want to cover three big parts. The general improvement, which has nothing to do with Carbon and Cocoa. The things specific to Cocoa we've been putting in this release. And the new stuff for Carbon. So let's start with the general improvement. The biggest thing we have to do this year is to support Aqua, not as a new developer, but for the user interface of Interface Builder. Make IB look good with Aqua. After all, you're going to be using that. This tool to develop your UI, we better be compliant with Aqua. We want to give you a good example of how to use Aqua in your application.

We've been also adding some other little features. When we're going to show you the demo, you're going to see those features. We've added a starting point to easily be able to choose which template you want to start with. We have a better selection model. For example, people who have been using Interface Builder, I'm sure, didn't like the fact that when you want to edit inside a group box, you have to double-click.

Now you can just click once and you're going to go through directly, so you don't have to do all those double-click things. We have put some new features in the size inspector where you can change the origin, so you can easily measure the distance from an object to the right side, to the bottom side of this container.

We have a new alignment panel, where you have all the alignment in one panel now. You can do align to left, align to right, center in container. All those things are in one panel. We have live resize of objects, so you don't have anymore this outline. You can resize objects live, seeing the full resize. We have enhanced the palette setup. We have a new palette setup where you can load your palette and stuff like that. And you have a lot more features. I'm not going to go through that today. So let's talk about Cocoa now.

In Cocoa, we've changed the palette. We've added a new Cocoa palette, and we've added a bunch of objects to existing palettes. So let me go through the palettes. This is the menu palette. The biggest change here is that there is no more the Apple menu. There is an application menu, which is the far left menu in your app.

This is the new View palette. We've added a separator below the box. You can see a line, which is the separator. We've added the non-rounded button directly on the palette, to be easily accessible. We have a more View palette, where we have new sliders, we have the progress indicator.

This is a new window palette. Basically, we already added two objects here. We have the drawer. The first one at the top is-- A window plus its drawer plus a drawer object. So it's like one object you can drag on your document and have the full drawer ready to use. The second object in the NSDrawer is just if you want to add a drawer to an existing window.

The data view hasn't changed much, same thing. We have also here the tabulation view. We have added the tab view. Also, we have a new tab view editor for the tab view. We've also added the outline view on the palette. We've also added a new graphic view, which right now has the OpenGL view, so you can directly drag the OpenGL view from the palette. And we have also a Quick Draw view, if you want to draw a quick draw in your Cocoa app. We will be adding an Smovie view as soon as the app kit is done with that. So the QuickTime view will be on the graphic view palette.

We've also added some features on the inspectors. Now you can set the autosave frame name on the window inspector. You don't have to do that in code. You can also set the max window size. You can also, on the matrix inspector, you can set the number of row and column. And as I said before, we also enhanced the size inspector, so you can change the origin and how you want to see the size of a view.

The Aqua user interface has now those shadows. If you are a Carbon developer, you don't have to worry about those shadows because the shadows are drawn outside of your bounds of your control. On Carbon, there is no clipping around the button or whatever, so they can draw outside. On Cocoa, you cannot draw outside of your frame. So the shadow is in fact inside your frame. So if you just leave the frame size as it was with the previous look and feel, your buttons are going to be too small.

And they have to be a little bit bigger. But it's not very practical to work this way because all the UI specifications are given without the shadow. So in Interface Builder, just for Cocoa developers, not for Carbon, for Cocoa developers, we have introduced this notion of a layout rect, which is the size your control should have.

uh... according to the u_s_ specification So to facilitate going between frame rate and layout rate, we've added a pop-up in the size inspector, where you can toggle between the frame rate, which is what you have to create your view, and the layout rate, which is the real size of your control. So you can see here, for example, the layout rate is 20 pixels high, which is what the UI guideline says, but the frame is 33.

This is only for control with a big shadow, like the push button, especially. What's nice with IB is that you don't have to worry about that. If you leave the pop-up to layout-rect, you just type the size and it's going to set the frame to the right size.

There were also changes for Cocoa that were driven by the adoption of Aqua. We've added, I'm sure you saw that in the Cocoa demo yesterday by Ali, we've added the apply layout guidelines, which allows you, if you have a nib with the old look and feel, to convert it to the new size, to the new matrix.

So we have it in a menu. You can load your old nibs, apply UI guidelines, and we're going to resize everything to match the Aqua guidelines. We also updated all the templates in IB. So all the new templates. We've added the new templates, respect the Aqua specification as far as size, menu layout.

We've added separator types, so you can have line separators, horizontal or vertical lines. We've added split view. Aqua has two types of split view. So you have that on the inspector. You can set the different split view type. And we've also added tint for buttons, so you can have the blue button or the clear button. That's on the inspector. So actually bringing Scott Herz, who's going to show you a demo of improvement in Cocoa.

Okay, I'm going to show you some Cocoa stuff. Specifically, I want to talk a little bit about our support for drawers, our support for tabs, which I hear is something a lot of people wanted. And just the overall, I want to give people a good impression of how just easy it is with, especially with Cocoa and Interface Builder, to hook all this stuff up. So, this is the starting point window that Henri talked about. Just so when you first pop up IB, it's going to give you a... So, let's make a drawer. So, we're going to bring up an empty nib here.

And go over to our Windows palette. Like Henri said, there's two ways to do drawers. You can either use a-- if you have Windows already set up, you can use this drawer object and connect them up. But we have this nice ready-made drawer composite here. So we're going to pop that on.

And so it's going to bring up two windows. This one over here represents the content view of the drawer. And this window here represents the larger parent window. So editing stuff in Interface Builder is real simple. I'm going to make a little close button. We can do all sorts of other interesting things with it. Like Henri said, we have support for tint. Just come up here, bring up the inspector. You can choose between the default control tint, which is you're going to use if it's something that you really want the user to see. Make it blue.

What I want to do now is I want to link this button to the method in NSDRAWR that is going to close the drawer. It's incredibly simple. You hold down the Control key, and you just draw a line down to NSDRAWR. And the inspector over here changes, and you're given a list of all of the methods that that NSDRAWR object supports. And, whoop, it closes right there. So I'll connect that, and we're done. That simple. Go ahead and close that. Next I want to show you our tab view editor.

Over here, right on the palette, bring that up. Here's some of our nice live resizing, which is very helpful when you have shadows. It's very nice to be able to kind of nudge stuff up, to be able to see how things line up. So. Make a new tab here, like another closed tab. We can put another button on it.

I like how stuff kind of highlights and kind of shows that this is something that is a container, so we draw this little ring around it so that you know that you can drag stuff into it. I think that's a little easier than just knowing that, oh, the little nubbies got a little mark knocked out of them.

That's what it did before, which was kind of lame. So we'll call this Close. And here again, everybody knows what to do now. I'm just going to draw a line down to NSDRAW. Select Close. That simple. We'll make an open one here so that we can actually pop it back open.

And just to show you how this drawer-- I'm going to click on this drawer here. And you can see here that it is already-- since we drug it off the palette, it's already linked up the content view and the parent window to link up to the associated windows. If you were going to do this with the actual NS drawer object, you just hook those up to the windows that you already have. OK.

So we're done laying out our interface. And one of the very cool things about Interface Builder is we have this great thing called Test Interface Mode, which allows us to actually unarchive the nib and this is just as it would in your real app. So if I hit open, doors open, and click the tabs, close the door, open it back up, close it there, just works. Very cool.

And just as easily as it works for this demo, it works for everything else in the kit. It's just-- How do you add a third tab? Huh? How do you add a third tab? Okay, it's not in my script, but I'll show you. You can copy and paste them. You can click on here. I'll change this to foo. You can move them around with the arrow keys, just to show you that it's different. Very good. Works very well. So that's my demo.

So now let's talk about Carbon. We spent a lot of time this year adding support for Carbon in Interface Builder. Which, by the way, for Cocoa developers, this is good to have Carbon support, because IB, as I said earlier, is an Apple Interface Builder tool. And we'll be covering those two platforms in parallel and adding features to one or the other frameworks at the same time. So Cocoa developers don't say, "Oh gee, I don't care about Carbon support."

This is important for you too, because we're working very hard to be sure that both platforms are fully covered. So let me talk about Interface Builder for Carbon. There are two distinctive pieces. There is the Interface Builder application, the tool, and there is also the IB Carbon runtime. Those are two different pieces.

So let me talk about the application. IB only works on Mac OS X. This is a Cocoa application, and it only runs on Mac OS X. It allows you to layout your user interface to what you've been seeing here. It generates a Nib file, which is a replacement for all the DLOG, DITL, MBAR resources that you used to use.

Those are now replaced by a Nib file. It's XML-based, so we generate an XML file. It's plain text. You can open it into a text editor and go ahead and change it. We don't want you to do that because there is some syntax here. Don't mess with it. But you can go and change your label with any text editor.

What's very interesting with the XML format is that it provides both forward and backward compatibility. The way it's done is that we could potentially open old Nib file with a new IB, or open new Nib file with an old IB. It works in both ways. It's a Unicode compliant, because we use XML by default, UTF-8. So we can have Japanese inside the XML file. It works great.

So the second part now, the iBCarbon runtime. It is a piece that allows you to reload, to load a Nib file from your application and recreate your user interface. It's available today on Mac OS X. It's part of Carbon. It's completely part of Carbon. It's not something on the side that you, "Oh yeah, I may use it a lot." It's really part of Carbon. It's real. And it will be available on Mac OS 8.6 and up as part of Carbon Nib 1.1. So you'll be able to design your interface once and maybe a little tweak, use the same Nib file on Mac OS 8.6 and up.

So this is a diagram of how it works. With Interface Builder, you generate a nib file. And using the application, using the iBCarbon runtime, can recreate the application. Something I forgot to say earlier is that a Cocoa nib and a Carbon nib, you can't mix them. You can't have a Cocoa nib and say, oh, I'm going to use it in Carbon. Although they are the same format, the content is not the same. Carbon controls have different properties than the Cocoa controls. So they are not interchangeable.

So a lot of Mac developers ask me, OK, it's great. I have this nib file. But what do I do with it? They are used to resource fork and put their DLOG and DITL into a resource fork. So I have this nice text file. But what do I do with it? The new application packaging provides the contentment facility.

I'm sure you've heard about this new thing on Mac OS X. So this is an application which will show you the structure of the folder inside this application. And the nib file goes into the English Lproj like it was doing on Cocoa. This is the same thing. If you have a French version, you're going to have a French.lproj and a French nib inside this folder. So this is where you're going to put your nib. If you use Project Builder, just add your nib into your project. And you're going to go at the right place. You don't have to worry about anything. We're going to find it for you. This is really smooth.

There is one header for the IBCarbon runtime and six APIs. What we decided right now is the API is very, very simple, and it's really the bare minimum. I'm sure you're going to say, oh, I can't do this, I can't do that. We don't want to put too much API now, having to support them later, and say, oh gee, we shouldn't have done that. So this is really the minimum API to be able to start using IB. We will be adding new APIs as we need.

So let me go through those six APIs. We have first two APIs to create a nib reference and dispose of a nib reference. So you just pass the name of your nib to create nib reference. In this case, for example, main, or my nib. And it returns a reference to this nib, which you're going to use to pass to other functions. Once you're done with this nib, call disposeNibReference, which you should try to do as soon as possible. don't keep those nibs open for nothing.

So once you have a Nib reference, you can ask, give me a window. So pass the Nib, pass the name. In Interface Builder, we're going to show you that later, every object has a name. So you can say, my main window, for example, and you're just going to pass my main window as a name. And it's going to return you a window ref, with all the control inside being set up as you design them in IB.

If you want to have access to one of those controls, for example, you want to have access to a button inside this window, just set a control ID to your button in IB, and just say, get control ID, and you're going to get a pointer to your button.

We have also three APIs for menus. You can create a menu, a single menu from a Nib. Same thing, pass the Nib reference, pass the name of the object in a Nib, and it returns you a menu ref. You can also create the full menu bar, which is what we're going to do usually.

You pass the Nib reference, give the name of the menu bar, and you're going to return the whole menu bar. And you can set the menu bar if you want. We have a shortcut for that, because usually you just want to set the menu bar directly. So we have a set menu bar from Nib, where we just set the menu bar directly for you. This is a little program. This is a simple Carbon app that's going to put its menu bar on the menu bar and the window.

And believe me, this works. You can take this code, compile it, and you really create a Carbon app where you can drag the window, all the menu are functional. This really works. This is not fake. Only thing missing here is the testing of the status. You see, OK, do I really have this menu bar in my Nib and stuff like that?

But those, what, 10 lines of code really make a real Carbon application. So as I said, first line, you create your Nib reference, pass the name of the Nib. Without the extension .Nib, you just pass the name, and you get a Nib reference, set the menu bar, passing the Nib, passing main menu. Create a window from Nib.

When I'm done here, so I dispose of the new reference, I show the window, and I call run application event loop, which is a new Carbon event way of doing your main event loop to replace what's next event. And once the quit is going to be there, so if you press, you select the quit, it's going to quit your application, you have nothing else to do. This really works. I was a Macintosh developer before Cocoa, and that's relatively amazing to be able to do a Carbon app with so little lines.

So, I'm going to show you now what you have on the palette for Carbon. The Carbon palette and the Cocoa palette are different, depending on which template you choose. I say I want to do a Carbon palette or a Cocoa palette, you're going to get different palettes. So I'm going to go through all the different Carbon palettes now.

So basically you have an application, which is the Apple menu where you're going to put your about box. You have a file menu, an edit menu, which are fully populated and all the commands have been set on those menus. You have a sub-menu, which you can use as a sub-menu, just an item, the window, and a separator. All those menus are fully there.

If you drag the file menu to a menu bar, you're going to get the wolf file menu with all the commands for those menus set. So the open command, etc. is going to be set. We have the first control palette: Push button, Edit text, Checkbox, Radio button, Radio 1, Radio 2, Radio group, Image well, Scroll bars, Pop-up menu, Progress bar, Static text, different types of Bevel buttons.

We have the second one, which we may really get out later on. It's a bit messy right now. We have scrollers, we have icon view, box separators. We have custom view, which doesn't work in DP4. It's there, but it doesn't work yet. You'll be able to drag a custom view from your palette, assigning a name, and be able to automatically get your custom control into your application.

We have a user pane, we have tab view. We have the two versions of the--which I don't look very good here. I need to do a better job here. We have the two versions of the data browser, the list view and the column view. We have the clock, etc. So everything is there. We're covering 100% of Carbon UI. We have two types of windows, a document window and a dialog window.

And now I want to bring back Scott, who's going to show you how to build a Carbon app. What we've got going here is a Project Builder project. You can make your own at home if you want. Just go up to the File menu, New Project. We're down here with this Carbon application, Nib-based.

It's going to do the same kind of thing that I'm doing here. I want to show you a few of the files that we've got going. This is the main .c file. It's not much more than what Henri covered in his slides. We just have the, you know, if it's an error, we exit gracefully.

But the same, we're using the new Carbon event loop, which is great. It significantly cuts down on the amount of code that you have to write to do this stuff. Next, we've got the main .nib, which we'll get to in a second. This contains the interface. And as you can see, the only thing we're linking against here is Carbon.framework, the Carbon framework. If you look up here, the only thing we're including is Carbon.h. There's no Objective-C runtimes or any other strange little things. It's very lightweight. So, what I want to do now is I want to show you how we're going to, we can edit this.

We can double-click on this. So this brings up our window. There's two objects in this nib. There's a main menu and a main window. And if you look, these are the names that we'll be calling out for down here in the code. You can kind of see it right there and right there. So keep track of that. Other than that, it's very simple. I'm going to build just a simple little dialogue here. We can drag a box out. Make it bigger. Let's see, we can put-- let's put a radio group in it here.

One thing I want to show is we have embedding, which is, for Carbon, pretty cool. When we actually save this out and you read it back in, if you apply a signature to this box, you'll actually be able to, if you want to hide the whole box, you can hide the box and everything inside it also gets hidden, which is nice. I want to add a few more radio buttons to this. We come down to the Attributes Inspector. We can say we want to put four there, just for fun.

What else is good? We've got level buttons. One thing that's kind of cool, we have this Images tab down here, which for right now is just populated with a few simple icon refs from the system. But eventually, one of the things we'll be integrating with PB is we'd like to be able to pull out any interesting resources that you have, that you're managing in that project, and then we'll fill them in in this tab down here. So if I want to drag a stop icon up here, or any other, if you've got pictures or other different icons and any other structures in here, you'll be able to drag those on and use them in your nib.

Got buttons here. I don't know-- how many people here went to the Carbon event talks? Good number of people? Cool. So when they say, "How does Interface Builder use the new Carbon event model?" This is how we do it. You come over here, all All controls have a signature and an ID, and that's how you pick them out using the control manager.

They also can have an HI command, and we've listed the ones that the system knows, and you can choose them here, but if you want to set an event handler on a button or any other widget, you would type it in here, and then you attach the event handler to the signature looking for these specific commands, or any commands that you type in there.

So we put quit in here, so what's going to happen is when we hit quit, we haven't installed any other handlers on the buttons or anything, so it's going to fall through to the system ones, and it'll cause the app to quit. So when it quits, it's because I hit quit, it's not because it crashed.

We'll drag a progress bar. These always demo very well. So make it one of those. So I'm done here. And I'm going to come down here, and I'm going to build it. And PB has politely told me that I forgot to save it, so I'm going to save it before I build.

So we build it, copied our Nib into the package in the location that Henri told you about. So now I'm just going to run it. And here we go. So we have radio buttons that know that they're radio buttons, which is cool. Got buttons that click, progress bars. Here's the menus that we had before. down there in the editor. And when I hit quit, it quits. So there we go.

Just so you know, I really want to encourage people to check this out. This is where it is inside the new PB. So have fun with that. And back to Henri. So, let's talk about what we are doing right now, what's going to be in the next release of Interface Builder, our short-term goals.

One of the biggest things we have to do is integrate with Project Builder. We used to have a very good integration with what we call now Project Builder Woo. And we want to bring back this integration with Project Builder. Today we have a very minimal integration between IB and PB.

The main thing we have is that if you haven't saved your nib, PB is going to call IB and say, "Hey, please save your nib before continuing." So we have a minimal integration now. We want to bring that back to the states where we were with Project Builder Woo.

So if you add an image to your project, IB will know that and show you into the image tab. If you add an image inside IB, we will be adding it to the Project Builder. Same thing to generate .h and .m, so you're able to add those files directly to your project.

So all the stuff that Cocoa Developer knew about the integration with PB, IB, we want to bring it back to the same point. The other thing is for Carbon. What you have to do is we want to finish completely Carbon. There are some little holes here and there in Carbon. For example, you can't set a pop-up menu on the Bevel button, little thing like that. It's mainly 90%, 95% I would say there. But we have to finish that a little bit better. We're also adding cool features for Carbon developers.

One of them is being able to import resources from the Resource Manager resources. So if you have your application using DLOG, DITL, and you want to take advantage of the new Carbon event model and of the interface builder, we will be allowing you to import those resources in IB and convert them to Nib file. We want also to use--implement the applied layout guidelines, which right now works for Cocoa but doesn't work for Carbon. So we want to bring that also for Carbon.

We want to bring back also, we have a test mode for Cocoa, but for Carbon it's not there yet, and it will be in the next release. That's very important to be able to see your interface immediately as you build it. So, I'm going to bring back Scott again, or test Gode. I didn't sign up to test any Godes, so I don't know how this is going to work.

Oops, coming soon for Carbon. What he's going to show you is not in the DP4 release, but hopefully we'll be able to make that available before-- it will be nice. Somehow. Yes, somehow. One of the things we've heard a lot is-- oh, can we see the menu bars would be cool too.

We wanted to be able to-- you have all these resources that you've used for Carbon. We want to make sure that we can move those forward, because it's a real pain to have to drop all these buttons down. So we have this great thing called-- we can-- whoop. We can import the-- you can import your resource file now.

And so I'm going to apply this on an actual classic copy of this copy, because it had some interesting dialogues in it. And what we do is we go through and we look for the resources that apply towards interfaces. Now we're not ResEdit, okay? We're not bringing in all sorts of, you know, all assortment of resources. We look for D-logs, Dittles, menu bars, menus. If you have a control, we'll map that back to the PROC ID and we'll actually convert it to an actual appearance control here. So, and Windows.

So these are, this is everything that it found in disk copy. You can look through them. I'm just gonna check off the win, 'cause it's just gonna bring up a window. It's not that interesting. Here's its menu bar and here's its associated mess of D-logs. The one that's kinda cool is 250, 'cause it has some neat appearance controls and I'm gonna bring those forward. So we hit import.

and went through, it got all of the menus. We've got the D-log here, so I can open that up. And if anybody's ever opened up the preference panel on this copy, which isn't maybe many of you, but it might look a little bit familiar. And so it's gone through, it's brought in all of the very simple dialog items like check boxes and buttons and things.

But it's also gone through and it's mapped the control, the custom control to the control and then using the proc ID mapped it and actually brought up an actual pop-up button. And so we're going to do that for all of the controls that are like that, so you'll be able to bring all that stuff in.

One thing that we don't do, like these right here are kind of misleading. They look like separators, but they're actually user items, which are just erect, and so we map those to user panes in using the appearance manager, which is sort of the lightest weight thing we can get.

So I'm going to delete that and I'll pop over here and we'll actually grab an actual separator just so that, Because in a minute those are going to show up blank and I don't want anybody asking. Why do they show up blank? The other thing to notice-- What's that?

Well, there's that, too. You'll notice that the buttons are a little tiny, and things are a little squished. So I can go up to Layout, and I can apply the layout guidelines to the window. And you'll see that everything kind of enlarges just a little bit. Buttons go. Good.

One other thing I want to show you, just to reinforce that we do use H-I commands for everything. If you want to come in here and you want to type in your command tag here, you can type it. like that and it'll fire. I don't have any handlers set up. Obviously I haven't poured disk copy or anything so that's not going to do anything here.

So the other thing that Henri said that we were going to do is this test mode for Carbon which is very cool. We're actually, we write out the nib and we actually have a little application that runs in the background and reads it back in. So we go to test interface just like you did in Cocoa.

It pops up this slick little external editor and there you go. We've got check boxes and pop up button or yeah, pop up button. If you in your real app went to execute descriptor it would actually fire that exact tag and you would look for it with the handler. So there again it's just a, it's a little bit Just works, which is what we like. So come over here, we can quit the simulator, jump back into here. Done with that. Bring back Henri.

As I said also, we want to have a better integration with Project Builder. Last year, we showed you some code synchronization where in I/B, if you add an outlet, automatically it will add this outlet into your .h. Because of the change of Project Builder, this doesn't work anymore.

But we want to bring that back, which will be even better with the new Project Builder because they have the right support for us. So we want to bring you back full code synchronization between I/B and PB, so you don't have to go back and forth between your code and the user interface to be able to be sure that everything is in sync. That will become also very important for us.

Also, we want to improve the experience for developers who have an extending IB, especially the Cocoa developers. We have this mechanism with IB with the palettes, where you can create your own palette and add them to the Cocoa palette. That's always been very, very fragile. It broke every time IB or AppKit was changing. So we want to revisit that. Something also that has been impossible to do is having your own editor, in-place editor. For someone trying to do the tab view editor outside of Apple, it would be a very big challenge.

So we want to try to bring APIs for you to be able to do your own editor for your own object. This is a big task. Cocoa will also be moving to XML Nib file at one point, so we will both have XML for Carbon and Cocoa. It works great for Carbon, so I'm sure it's going to work great also for Cocoa.