Please now welcome to the stage, Tim Bumgarner. Welcome. It's exciting to be here. This is our fourth year, I believe, at presenting AppleScript Studio at a developer conference. And it's been an exciting, terrific ride that we've been working on here. Before I get started with my presentation, I'd actually like to take a little bit of a poll, so it'll help me gear what we talk about. How many people have ever actually used AppleScript Studio? Great.

How many use AppleScript Studio on a regular basis? Okay, terrific. So I'll keep it at about that intermediate level. Thank you. All right, let's talk a little bit about it. And of course, I'm Tim Bumgarner, AppleScript Studio Lead Engineer. What I'd like to do is to show you a little bit about what you're going to learn today in this session.

And we're going to do an overview of AppleScript Studio. So for those of you that haven't ever seen it or ever used it, we'll give you a quick tour of what it's like to create an AppleScript Studio application. We're going to touch a little bit upon the enhancements we've made for Xcode to better support AppleScript Studio. And of course, the most exciting thing is to talk about some of the new features that we're going to be providing in studio for Tiger.

So what is AppleScript Studio? AppleScript Studio is this very exciting technology that we've put together, and it pulls together a lot of different aspects of technologies that we have at Apple. It takes advantage of the developer tools we have so that we could integrate AppleScript support into Xcode and Interface Builder to make it very easy for you to create these applications that are, in fact, native Mac OS X applications.

So that when you build these and construct them using AppleScript as your language, you can save and distribute these applications to anybody else that has a Mac OS X system. And they can run that application without needing any other additional frameworks or components to go with it. It all just works.

Now, additionally, you can take advantage of all the features of Xcode such that you could add additional functionality using either AppleScript or Objective-C or other languages, even Java. And you get to take advantage of Cocoa, its rich user interface. So it's really a two-part solution. It has a runtime component, and this is an AppleScript kit.

It's a public framework that's provided with the system. It contains, in essence, it's the glue between Cocoa and AppleScript itself. So it'll know when something happens in the user interface, and it knows how to call your script and execute a particular handler. And that's what provides the functionality of a Studio application as it's run by the user.

Now, it's also a development side piece to it. And we've developed plugins into Xcode so that it knows how to edit, add, or edit, compile, and build, and even debug AppleScript inside of the development environment. And we've also added a palette and interface builder to make it very easy to put these things all together.

So how's it being used? Well, it has been about four years. So we've been paying attention, watching what's been happening with Studio and how people are actually using it out there in the real world. And we found that a lot of people have taken Studio, and it's a great tool to use to wrap shell commands. So there's these low-level tools that are laying around in this wonderful Unix environment that we have, but smear mortals don't know how to use them for the most part.

There's a lot of parameters. I don't know how many have ever actually pulled up a man page and go, hmm, what was that? Some of them are quite long. But people that do understand it, understand Studio, can take and put the best of both together so that they can provide a nice, simple user interface that has checkboxes and pop-ups and little fields.

And when it runs, it actually executes that low-level functionality. And there's a lot of great examples of that in use. We also find it's a great prototyping tool. And the reason it's such a good prototyping tool is that you get to use the same exact developer tools, the same process, as you do in the real world.

And that's because you can use Studio as if you were to start off with a Cocoa application so that you learn all of the methodology of creating that application. And so you can start off in Studio, put together some things very quickly, get a look and feel that you like, and then as needed, you can replace performance-critical areas with direct Cocoa calls or correct Cocoa classes as you need them.

And of course, the other thing that we've seen is people create applications using Studio to control other applications, because that's really where the leverage comes in. Apple Script is awesome at being able to talk to other applications that are scriptable, of course, and get data from the other application and even to control them. So we find a lot of examples of that.

And we also find that, of course, our core customers really use that for their workflow solutions. So they will create workflows as needed and use these controls. Excuse me. So that they can put together these nice interfaces and have this workflow. Instead of the old way with AppleScript is you would have to prompt the user dialogue after dialogue after dialogue. You'd have a dialogue that come up, ask a question, hit okay, and it would bring up another dialogue. Well, you can do away with all of that with AppleScript Studio.

And last but not least, and the thing I'm most excited about, is that Automator uses Studio itself. As a matter of fact, many of the actions that you've seen in Automator are done with AppleScript Studio in conjunction with Cocoa Bindings and Objective-C. And they all work just seamlessly together. And we're very excited about that.

So what I would like to do is just take a moment, switch over to the demo machine, and just give you a quick feel of what it's like to create a studio application from scratch. So I'm going to go into Xcode and close this project. And we're going to start off with a new project in the file menu. And you'll notice that when I bring up the new project assistant that there are several different templates that are already pre-built for you in order to create studio applications.

The first one will create a very simple application that has a single window. The second one is a document-based application. So if you need multiple documents, this will be the one you choose. The third one is a droplet. So if you need to be able to create an application that sits on the desktop and users drag files onto it, you can process those files in interesting ways.

For those of you that have used AppleScript a lot in the past, this is very similar to an applet that you would save or a droplet that you would save from the script editor. For our purposes, we're going to go ahead and choose the AppleScript application. And I'm going to call this project user info. And we're going to go ahead and override these selected files.

And I'm going to go into the very first thing we're going to do, just a quick overview of where things are located in a project. First is there's a scripts folder. This is typically where you put all of your .AppleScript files and the resources. And here is our main menu .nib. Those are the two most important aspects that we need to deal with in this project. So I'm going to go ahead and double click on this nib, which is our interface. And it'll open it up inside of Interface Builder. And here I've got a simple window.

And what I'm going to do is actually, instead of creating a simple hello world, which I've done in the past, it has a simple button, you click it, and it says hello world, we're going to take advantage of a new feature that we have in AppleScript that we've added for Tiger, and it's called system information. So actually, if I fire up Script Editor, and we'll take a look at the library window.

This is an easy way to get to the dictionary of the standard editions. I'm going to double click this and take a look at, and I believe it's under the miscellaneous classes. You will see that there's this new thing called system information. It's a new class or record. So now it's very simple to get, for instance, the AppleScript version. I can get the system version. I can get the short username or long username. There's other things like its home directory, the computer name, IP address, the CPU type.

So it's some really new functionality here, so it makes it very easy for you to determine what type of environment is this script running in. So for our purposes of the demo, all I want to do is grab the username, the long username, and I want to also use the computer name. So I'll go ahead and hide this, and we'll drag out a text field.

And you'll see as I'm dragging around, I get the nice interface builder we'll put off the guidelines so I know that I'm actually putting everything as far as Aqua is concerned in the right location. And I'll drag out a text field. And we'll go ahead and call this one username. And we'll write a line that as it should be. And get those all lined up nice and neat. Make a copy of that. And just we'll add a simple button in order to fill that data out.

And we'll call this Get Info. And grab-- don't quit. Grab all these. Again, line them up here as close enough for the moment. And then the next thing we need to do is we've got our interface laid out. Now AppleScript is very containment oriented. It needs to be able to talk to objects through its containment. In this case, window is the top level, and I'll make sure that I name that window.

by going to the AppleScript panel in the info window, and we'll call this main. And I'm going to then name some other objects that I need to reference. So I'm going to reference this field, and I'm going to give that a name of user name. Good, thank you. Good catch. Thank you, Paul. So we're going to call this one Computer Name. and Nehmer, not Nehmer, okay, there we go. And we'll change this to computer name, thanks. Okay. Well, not quite wide enough, so we'll fix that.

and it will launch the application. If everything is right, I'm going to click Get Info. And there you go. It went and got the user name logged in as AppleScript Studio, and it happens to be the computer name is WWDC 2004. And just that simple. Now it's an iterative process. Then you just go back into Interface Builder, add your additional interface, and just keep attaching handlers and scripts and filling those out. So I can go back to slides, please.

So let's talk just a few minutes about the new Xcode support we've added. We've added native target support to Xcode. So now, and that's very important for several good reasons. The main reason is that the native target system or native build system in Xcode is where all the new features are going in. So for things like ZeroLink, we now get to take advantage of. So it's very quick in your turnaround as you build your application. You don't have to go through this long link process. It's very quick.

And so any other new features that come into Xcode, we'll be able to take advantage of that. So we stay current with all the other languages that are supported. We also took advantage of improving the code assistant. It had a very limited amount of support. We've now increased that so that it's on the parity with the script editor script assistance, which also got enhanced. So now you're going to have the same look and feel no matter where you're editing scripts. It will have all the same terminologies and autocompletions for you. So it's a consistent look and feel.

And we've also added support for compiled scripts. Up to this point, AppleScript files have been saved as .AppleScript. And what we wanted to do was also be able to support .SCPT or compiled scripts. So that you can compile a script on your machine, which might do something like a tell application FileMaker Pro. It will save that application.

If I give that project to somebody else, they don't necessarily have to have FileMaker Pro on their system, whereas before they did. So this makes it a little more convenient. And then if anything in the terminology changes, you get that for free. The next time you open up that script, the terminology will automatically change. Whereas before, you would have to go and fix the broken terminology.

Finally, we get to the fun stuff. Since we're at an intermediate level, we'll talk about some of the new technologies, the new features that we've added to AppleScript Studio for the Tiger release. The first thing I want to say is we actually do listen. I personally read every mail that comes across the AppleScript Studio mailing list. And we look at that. I try to answer as many as I can. Unfortunately, it's not as many as I'd like to.

But we do read them and we see the trends. Where are people struggling? What are they having difficulties with? What areas are a performance issue? Where is it not flexible enough? And so we've tried to incorporate as many of those as we could in the best priority that we could determine.

So what are some of those new features? We've got more data view support. The data view seemed to be one of the top things that people want to script. And so we've found that we've tried to make it easier and better performance to add data to your data source.

But we found that it's still difficult to get that data back out so that you can do something meaningful with it. For instance, store that data and put it back with the same fidelity as you put it in. So we've made that simpler. We've also made it sure that it works for both table views and outline views.

Outline views have sort of been the stepchild, a little often ignored. So we've taken care of that. We've also found that people wanted to be able to have better control in their drag and drop for data views. So we've had some support so you could drag in items, but we haven't given you the opportunity to determine where in that view you want that data to drop.

And more importantly, people wanted to be able to reorder items within their table or outline view very simply. So we've provided that. And another one I'm very excited about is toolbar support. That's sort of the one thing that if you looked at Studio, it was sort of missing from a native Cocoa application. That was very difficult for you to actually add your own toolbar. You would have to go directly to Cocoa to do that. We've made it incredibly simple for you to do that, to add to your own applications.

We've also taken care of some of the term-- we're going to look at the terminology that we have. And I had to do a review over the documentation of the reference manual. And there were just too many places where it said not supported. We'd have it defined, but not supported. So we're going to address that as well. And of course, we've added some additional functionality to better support Automator. So that's built right into the new features that we have. So let's go look through these one at a time.

More data view support. We've had this command for a little while called append. And it was very simple to append data to a data source. Unfortunately, it only worked for table views. Now it works for outline views. So you can append hierarchical data at any place that you want within the data source.

And the thing that's really cool is the content property. For most of the AppleScript people, it's like sort of those duh things. Why wasn't there one to begin with? But now there's a content property. So it's very simple to simply say set content of table view to some data.

And it just creates it for you. It takes care of all of the work that needs to be done. But since it is a content property, you can get it right back out. You can say get content of table view or outline view, and you get all your data right back.

And you can also control how that data comes back. You can put the data in as a list of lists or a list of records, and then you can also figure out how you want to get it back as the same format. And we've also added support for the sort indicators.

And the last one is that data sources historically have been sort of this all-knowing, all-powerful thing that gave you great performance but was very inflexible. It didn't want to give any control back to you as the scripter or the application writer. And so we've tried to add that support as well.

and as I discussed, and now the append command works for both outline and data views. You can append data as a list of strings. So if you have a simple table with a call or table view with one data, one table column, you can list that as add as a list of strings or list of lists or list of records, whatever is the most convenient for you to use.

The content property. What's exciting about this is that you can set the content of that table view and it will do everything for you. It will create the data source, create all the necessary data columns, and create all the data rows or data items that are needed for that view, for all the data that's provided. With one line of script, you can now populate an entire data source or data view.

And that's very exciting. And again, as I mentioned before, both table view and outline view. Outline view is no longer the stepchild. Getting data out. Again, as I mentioned, you simply ask for the content of a table view or an outline view and you get that data back.

Now, the problem with a content getting the data is that we have to give it back to you in some format. And there's unfortunately in AppleScript it's not possible to say get content of table view as a list of records or as a list of lists. It just doesn't work that way.

So we have a property on the data source. It's called returns records. You can set that to true. The data comes back as a list of records. Faults, you get it back as a list of lists. So you get the flexibility that you want to decide what format you want that data in.

And here's back to that sort of all-knowing, all-powerful data source. It's been a wonderful thing because the performance is so much better. The very first iterations is that you had to provide all the event handlers, but the table view, every time it needed to update that cell, it would ask you for the value. Well, that's terribly slow because it has to send an event every single time. When we added the data source support, it all came very fast because it took care of everything. That was sort of the problem. It took care of everything.

You didn't get an opportunity to know when the user changed something in your table view. So if they edited a data, a table cell, you didn't know. It's a little event handler. Even we would let you add the event handler, we just ignored it. So that little table event handler would go, tell me, tell me, tell me when you change data, please. And the data source would say, I know better. I know better. I'm not going to talk to this guy over here.

So he'd go ahead and do it, and he'd just ignore it. But we finally realized the data source got smart and said, you know what, that little event handler knows something I don't. So it gives him an opportunity to call you. So you get to pick and choose which event handler you want to implement in your table view so that you can get the best flexibility out of it as you want. So we're much happier with the new way.

and sort indicators. So it's very simple to set now a Boolean property on the table view to say whether or not you want little indicators up in your table column. You don't have to call Cocoa to do that. And the default is false at the moment. So what I'd like to do is invite John Coelho.

He's our AppleScript Studio quality assurance engineer and to help make sure I don't mess up like I did before. Thank you, John. And we're going to give you some quick demonstrations of this technology. So what he's going to do is we're going to first start off with our table view.

And the first thing we do is go into the interface builder, and we're going to see we have a very simple table view here with two columns. And he's going to drill down and select the table view. And what we're going to do is we're going to use Awake from Nib. That's a handler that gets called when the window is open, and it's a good place to populate our data.

And then let's go to the application object, and we're going to make sure that we've got the launched handler. Because a very good strategy in Studio is if there's something you need to put in the window, add data, change the UI, make sure you do that before the window becomes visible.

So by default, we make sure that the window is not visible, and launched is a good place to show our window. So let's go ahead and save that, John. And we'll go back in and we'll add our code. So from Awake from Nib, he's going to add our code. And go ahead and add that line. And we're going to add our code.

And let's take a look at that. There you go. One line of script is going to populate the table. It does all of that work that I mentioned, creates the data source, creates the data columns, creates all the necessary data rows. Before this would have been about ten lines of script. Now it's one. So let's go ahead and build and run this.

And there you go. Just that quick, it's populated the table view and it works just fine. Matter of fact, let's show you now how easy it was to get it in, that's how easy it is to get it back out. And he's going to go into Script Editor, drag in a little bit of script that's going to talk to the table view and ask it for its contents. Now you'll notice that it came back as a list of records. How did we put it in? It was a list of lists. So we can go ahead and set our returns records to false and run it again.

And you see it comes back now as a list of lists. So you've got fidelity with the data going into your data source. You can get it back out in that same format. That way it makes it very simple to store it in just any type of a file that you like. Okay. Now one more thing we talked about is that flexibility issue. What we want to know is when the user actually changes one of the table cells so that we can do something about it. So let's quit the application, John. Glen Interface Builder.

And what we're going to do is we're going to go to the table view category, and we're going to add a change cell value event handler. This handler gets called when the user tries to change the data. So let's say that. and go ahead and add our line. Now, looking at the handler itself, it passes a few objects. The interesting one is at the end is the value. This value is whatever the user typed in.

So you can decide to do something interesting like if a checkbox got changed in one column, update something in another column. In this case, we're just going to force it to return a different value so that we can actually change the value as it comes in. So let's build and run this.

Okay, and so when John goes over and tries to type no, it'll let him type no, but as soon as he goes off of it, you'll see it says, I don't think so. So we actually got to control, we get to work with the data source instead of the data source working against us. All right, thank you, John. Let's go back to slides, please.

Drag and drop support. Don't go anywhere, John. I thought he was going to get away. So we're going to do our drag and drop support. Talk a little bit about that. Now what we've done is that made it very simple for you to not only drag items in, but control where they go within the drag. And then also be able to reorder items within the drag.

And we've done this also by making it very simple. With one property, you set allows reordering to true. You don't have to do anything. You just set the one line of script. And you can automatically drag items. Cocoa doesn't even make this available. So this is something we've got to leg up on.

We do the new drag and drop through three new event handlers. So now that there is a handler for when the drag begins, and you can put whatever type of data you want on the Paceboard as the user drags things around. There's a handler that gets called as the drag is happening. So you get to decide whether it's a copy or a move, or if it should happen at a particular location. And then there's another handler that gets called when the item is dropped. And there's three handlers for table view, three handlers for outline view.

and there's also two additional ones. We've added two event handlers called rows changed and items changed. You can have these handlers attached to a view so that you can find out whenever the data changes. So for instance, if some other data is driving the source, you can get notified of those changes.

And reordering support I mentioned is simply setting a Boolean property on the table view. Just a couple notes. Obviously if you're going to reorder, that means it's not a sorted data view. So if you set sorting on, you're not going to be able to reorder. You have to decide which is more important. It only works, this automatic support only works if you drag items within a table view. If you need to support dragging things in, you're going to have to do that work as well. So it's not, it doesn't automatically support the external drags.

So let's take a look at an example of this. Now, we've showed you the table view, and just to prove the fact that it actually does work with the outline view, this time we're going to start with an outline view. And let's look at the nib. And again, he's going to drill in, and we need to attach-- we're going to go to our outline view.

and we're going to add these three new event handlers. Can't quite see it down there, so I'll have to look up here. And what we're going to add is the prepare outline drag. We're going to add prepare outline drop. And the last one is accept outline drop. And that's all we need to do in this. So we'll go ahead and save and edit the script. And John's going to enter in, the first thing we need to do is whenever you're going to start a drag and drop, you need to tell the view what type of drags you want to receive.

So whether it's files or other type of things or colors. In this case, we want to make sure that we register for the items that are being drugged so that we can do reordering. Or we want also to support file names. So let's go down to the prepare for drag and add that script.

and what it does is it sets the contents on the pasteboard. And then the very last thing in that handler is to make sure you return true or false. If you don't want the drag to start, just simply return false and it will stop. But you always typically want to return true. So it's now going to fill out the handler that gets called as the user drags things up and down in your view.

And the thing that's most important in here is we have to return a type of drag operation. And it's an enumerated type. There's like a no drag operation, move or copy. And we determine that based on whether or not they're holding down the option key. and now we'll go down to the last one. Now admittedly, this is a fairly long bit of script here. and we'll let John put those in there till we get down to right about here. You are an incredibly fast typer, John.

Okay, so we're down at the bottom of this handler. And let's go ahead and check this index. And let's go back up and look at it just very quickly. This is the handler that gets called when the user drops something on the outline view. And what it will do is it gets the data from the pasteboard. It's going to check to see what type of data it is. If it's items, that means it's a reorder. It then looks to see if the option, the state of the key, the option key, if it's a copy operation, it's going to do a copy.

So scroll down a little further, John. And if it's a move, we'll do that. Otherwise, it goes down further. Else, if the file names is being dragged in, then we look at it again and decide it's always a copy. And we're just going to copy in that item. So let's go ahead and build and run this, John. Take a look.

So here's our outline view, and he's going to go ahead and expand that. And he's going to drag one of the items. And you'll see that when he lets go of it, it puts it inside of that one actually. And we can actually take another one on the bottom and put it inside that we can reorder and put items wherever we like. Now he's going to take an item from the desktop and drag it in.

and you'll notice that if he drags on the outside, it would have added it to the end. Or he can decide where he wants to put that item in the outline view. So it's just that simple in order to now support the fine control that you need in an outline view. Thanks, John. Slides, please.

Toolbar support. As I said, very excited about this because it sort of fills in that missing gap that we had. And we do this through a couple new classes. There's a toolbar class.

Take a look at that. So the process. How do you create a toolbar? In order to create a toolbar, you simply make it, just like you do anything else in AppleScript. You set its allowed and default identifiers. These are identifiers that say, the allowed are what possible set of toolbar items can I have in my toolbar. So, for instance, if you go to the customization palette, you'll see all of the possible choices.

The The default identifiers are the identifiers that the user sees the initial time that he starts your application. So you set those two sets of -- they're a list of strings. You make the toolbar items. So now you go through and create all the custom toolbar items that you have in your toolbar. And then you assign that toolbar to the window.

Now, what happens when the user starts working with your toolbar? So as I mentioned, the update toolbar item gets called by the system. The system will say, okay, these toolbar items need to be adjusted. The user's done something in the menu or clicked somewhere, and we need to make sure that the toolbar states are all correct. And so it will call that, and you get the opportunity to change the title, you can change the icon, change the tool tip as they move the mouse over that.

And the most important thing in this handler is that you decide whether or not that given toolbar item is enabled. And you return true if you want it enabled, false if not. And then when the user actually clicks on a toolbar item, you just respond and add this event handler to your window, and you can find out which one was clicked by just comparing its name, its identifier. There are several different ways that you can find out which one was clicked. Now, if you're really advanced, we actually can set the script object of a toolbar item.

So if that script object contains a clicked handler, we're going to call that one. So it's not, you don't necessarily have to say if name of this is that, else if name is this, else if that. You can just go ahead and define separate scripts for each item in your toolbar. And we'd like to show you how that works. So demo machine.

Okay. Now, one reason why there hasn't been support is that Interface Builder itself doesn't support toolbar creation right inside of it. So we needed to be able to do this from script. And what we're going to do is we make sure we go to the window that we want the toolbar attached to.

And we're going to go to it. Go ahead and go to the AppleScript panel. and we're going to set the Wake from Nib. That'll be the place to create it. And then there's a new toolbar category. And we're going to use the clicked and updated items. Go ahead and edit that script.

Ah, but it doesn't. We'll see. If you may be right, then I'll look really foolish. I'll really owe you twice. Okay, let's go through. And this was a document-based application, so it already had a couple of items here. And we're going to go down to the Awake from Nib. And he's going to paste that in. And we'll let him go ahead and fill that out.

And when it's finished, we'll go ahead and check the syntax on this handler and then talk about each of the items. That's very difficult to see on this monitor, so I'm going to look up here. And one more. So let's go back up to the Awake from Nebjhan.

and look at each of the pieces to this. So the object again is the window. This is what the event handler is attached to. And it's going to make them toolbar and it's going to create it with some properties. One is the name and that's just like anything we use in Studio. That's the name of the toolbar. Then it's going to create and use an identifier. Identifiers are very important to toolbars in Cocoa. Each of them have to have a unique name. And so we've got an identifier here.

And then there's some other properties that you can set. Whether or not the toolbar is resizable or can be customized. What size it starts off in. In our case, we're going to set these all to default values. And then the next line is the allowed identifiers. And this is the possible set of identifiers that we want to allow in our toolbar. You'll notice the first three is compile, run and stop. These are our toolbar items that we want to add to the toolbar.

Everything from that point on are standard identifiers. So there are such things as, what do we have there? We've got customize, flexible space, a space, a separator. Those are, we just set those in there and we'll get those support for free. The next line is the default set of identifiers. What do I want my toolbar to look like initially the first time they start their application? And so that we'll set that, in our case, we just want the compile, run and stop toolbar items. And then what we do is we'll set the default set of identifiers.

And then we'll set the default set of identifiers. And then what we do is we'll set the default set of identifiers. And then we'll set the default set of identifiers. as we create each of those toolbar items. So we have make new toolbar item. And again, with the properties, we make sure that the identifier is exactly the same as what we specified in the other lists above. If there's a misspelling or you've not quite got it right, it's not going to work correctly. So make sure that those are the same. And so we've created one for our compile, we've created one for the run, and we've created one for the stop.

And finally, now we've got all the pieces in place, we just set the toolbar item, or the toolbar property of the window. It's all done. This is even simpler than it is in Cocoa as well. And then the last thing we do is look at the last two handlers. If the user clicks, in this case we're going to only look for one click. We're going to look and see if they clicked on the compile button. And if it does, we're going to simply display a dialog.

If they click on the update toolbar item, or when this update gets called, we're going to just simply say we want them all enabled. I could have easily checked for a state. I might have been compiling, and therefore, I want to make sure the stop is enabled, but the run is disabled or change the state. This is the place to do that. So let's go ahead and build and run that.

And you'll see there's our toolbar. Very simply done. We can customize it. We can go in and look at that and add our items. and finish that up. And we can see that when we actually click on it, it adds our, calls our display dialogue and create a new window. and there you go, just that simple. Thank you, John. Let's go back to slides, please.

Okay, I mentioned terminology improvements. We are going to look at all of the broken terminology, all the terminology that says not supported. If it's defined and we can fix it, we'll fix it. If it's defined and we just can't fix it, well, it didn't work to begin with, so we'll just deprecate it and take it out of the terminology. There are a couple conflicts currently. I believe file type and file kind is a problem. We'll address that and make sure that's fixed. And we'll, of course, add any new terminology as needed.

There's my guy. I like that robot. All right. We've added some support for Automator. One of the things you'll find is that as you're putting together an Automator action, that you can quite often do everything with Cocoa Bindings. As a matter of fact, that's what we recommend. Use Cocoa Bindings. It's very simple. It takes care of the UI issues for you. But sometimes it's not enough.

For instance, we have many actions that when the action is added to Automator, it needs to go talk to another application in order to populate something like a pop-up button. So, for instance, when we bring in the new Mail Automator action, the first thing we do is we go talk to Mail and ask it for all of its accounts so that we can then populate that account pop-up for you.

So Cocoa Bindings can't quite do that unless I were to go write some Cocoa code. Well, that's not sufficient if we were trying to do it all in AppleScript. So this is where Studio comes in. It makes it very simple for you to go in. There is a wake from nib that you can attach to the view and then populate whatever you need to do. So another example.

There are several actions that change the file names in certain ways. And so we've added an example section. So as you click on the UI objects, we update that example so you can see how that is actually going to change your file names. It makes it much more obvious. So there's another great example of that.

But then we found that it was necessary at the point when you want to run or save your workflow that we find out what things have changed. Because it wasn't bound with Cocoa Bindings, which takes a lot of this for you, we have to give you an opportunity so that you can update that parameters object.

So if you saw our demos yesterday, you saw that parameters object. This is what we're doing to give you that functionality. and as we mentioned before, it works right alongside of Cocoa Bindings. It's not in competition with it. One doesn't replace the other. They can work together seamlessly. And you can mix in Cocoa as needed.

Going very fast today. This is going to be a short session, which probably makes you all very happy. So we've got the new incredibly easy-to-use data sources. We've made it even easier than we've done in the past, but at the same time, we've made it much more flexible so that you have the opportunity to decide what it is that you want to do to interact with it. We've added cool new drag-and-drop support. And actually, we forgot one demo. Yes, we did. Thank you. That's okay. I've got time to burn. Going anywhere? All right.

Let's go over here. I'll actually run this one by myself. Let's go back to the demo machine. I'm sorry, John, you should have said something. One of them we forgot to show you was the auto support for reordering. And I'm going to go ahead and fire up that demo. And we'll go into the interface builder.

I forgot this. Very cool demo. I can't believe that. So what we're going to do is go into the table view itself. I'm going to go ahead and add the Awake from Nib so that I can populate the table view. And then I'm going to actually add a handler to this checkbox so as the user checks it, it will turn on that state of allows reordering. So I'm going to go ahead and click on the clicked. And assign it to there. Save it. Edit the script. Now the interesting part is remembering what the code is for this. So I believe that we have the final one.

Because now I don't get to use my fancy-dancy demo assistant. So let's open this up in TextEdit. And we'll grab everything that's inside of this Awake from Nib. And we'll put it inside of here, so we populate the data in the Awake from Nib. And we'll go down here and we'll grab this simple line and go back up here to clicked. Check the syntax, looks good. So, that one extra Awake from Nib, good catch. And we'll run that.

And you'll see here is my application. It's up and running. And if I try to drag, it won't let me drag. So if I go down and click allows reordering, I can now reorder items without having to write any code whatsoever other than simply enabling that. So let's look at that again.

So it's just a matter of populating the table, and then you just turn on that simple property, and it's very simple. Again, this works for both table views and outline views. We make sure it works for both. So let's go back to the slides, please. My apologies, John. Sorry.

Okay, and also toolbar support. So we've shown you how easy it is to add toolbar support. Now, we showed you that there are actually on clicked and on update for the toolbar. We've actually added a couple additional pieces. You can even call Cocoa things from these toolbars. So now there's an optional parameters to a toolbar item.

One of them is target. So just as you've used in Cocoa, if you know anything of Cocoa, you can actually establish the target of that action. And then you get to define what Cocoa method gets called. And it makes it very simple to tie into other applications and take advantage of things like WebKit or something else that we might make available. And Automator absolutely loves Studio. I can't express it enough that it's a very powerful combination in order to make it very easy for you to create these actions for Automator.

Now, it seems like I've been very forgetful. I've already forgotten at least one demo. And I know that there's something else. What did I forget? There was something else. I remember-- Oh yeah, OSA Kit. You know, I thought about this and I thought, you know, WebKit has its own web, you know, or web services has its own WebKit.

I see that QuickTime now has a QT Kit, so why doesn't OSA get its own kit? So that's what we've done. We've actually taken and created a public framework so that you can take advantage of the same things that we have underlying all of our Cocoa technologies. So there's actually a public framework. It's called OSA Kit. It provides several public classes for you to use.

There's an OSA Script class. This class is a superset of abilities of the NSAppleScript class that's in Cocoa. It will allow you to do load and execute, which NSAppleScript does, but it will also let you save scripts. And it will also let you execute scripts in different ways that are provided by NSAppleScript. I will say a note that it in no way replaces NSAppleScript.

If you need to simply do the things that it provides, then we recommend that because then you don't have to link in this additional framework. But if you do have a little higher needs, we recommend that you then use the OSA Script class. We have this OSA Script view that then makes it very simple for you to edit scripts.

And we do this by providing a new palette. And so that you can actually go into Interface Builder and drag out a view and embed within your own application the ability to edit scripts. And so I'd actually want to also mention that we use this as our foundation. We use this for all of our Cocoa AppleScript uses within the AppleScript team. So it underlies the AppleScript kit itself. We use it in the script editor. Much of the functionality moved from a script editor into OSA kit itself.

It's being used in Automator. How many saw the RunScript action in use? Well, that's being driven by OSAKit. And then all the plugins we added to Xcode for Studio are driven with OSAKit. And so I'd like to give you a demo of that as well. Back up. Demo machine. So what I'm going to do is we're going to build an entire script editor in IB, no code.

And I'm going to go ahead and create a new application. And there is a new palette called OSA. Now I will mention that it's not in by default. You actually have to go to the developer extras and add that palette to your application in order for it to show up. But once you do, it stays there. So you'll see that I have two objects here and I have a window. I'm going to drag out this script view. And we'll drop it right about here and drag it over.

and then we'll drag that down a little further so we get some room to type. And then I'm going to put a few buttons. Now again, I could easily put this back into our toolbar example if we needed to, but for purposes of this, we're going to do it right here. And I'm going to do a compile and let's do another one with run. So I'll drag that over.

Now I just simply have to make a few connections by going back to the OSA palette and I drag off what's called an OSA script controller. This is the thing that knows how to talk between commands and the different views. And so I'm going to make a connection from that controller and go into the connections palette and I'm going to assign it as a script view. And then I'm going to take the compile button and I'm not going to tell the script view directly. I'm going to tell the controller that it's time to, in this case, compile and also run.

And we'll bind those together. And I'll go ahead and run this. And you'll see as I begin to type, It's also doing all the script assistant. I don't have to do anything to support this. It just happens. So that now as I bring up the... Oops, hit the right thing here. There we go. So it brings up the assistant. It'll have nice little icons to differentiate between types. Let's do finder.

Name of every window. And I'll wait for the window to populate. Well, let's see if it's not going to come up by default. Once again, window and end. So I'm going to go ahead and click on the compile button. And just that simply compiles it and I'll run. Well, in this case, nothing happened nor did I see any results. So it might be actually kind of interesting to see the results. So I'm gonna go back, choose a text view. Any old text view will work. Drag that out.

And we'll put it down here. And all I have to do in order to enable results is to make a connection, assign it to the result view. So now that when I run this and type in like current date and compile, run, you'll see that I get the result there with no work whatsoever.

But wait, it gets better. So we'll actually come in here and we'll, this time let's try recording. I'm going to put in a record button and I'm going to wire that again to my controller and we'll assign that. And let's go ahead and run this. And now if I click record and go over here and start opening windows, you'll see that the recording goes right into that view again with no code. Just that simple.

Slides, please. Now, you might ask, well, that's interesting, but why is it important? I think we found that in particularly an automator where we're trying to script a workflow, sometimes it is important to be able to edit your script in line, and particularly if you support recording, you can record from within yourself, and that might be very interesting. I think we're looking forward to some very wonderful examples of how to use this technology.

And, of course, the great benefit is that as we add new features and functionality to OSA Kit, not only will all of Apple's tools take advantage of that, but whatever you put on top of it will also get advantage of that. And so, just to quickly wrap up here, is to talk about the reference library. We did provide all of the sample demos that you saw today are available as session material wherever you get those from ADC site, I believe. So, go ahead and grab those, take a look at them, see how they work.

They're very clear in symbol. Some of it's even boilerplate. You just copy and paste it into your own applications. Then, of course, all the various other documentation. We have a great AppleScript documentation. If you go to the AppleScript site, you'll find the studio terminology reference and a building guide. There's also Cocoa and Xcode documentation to go along with that.

Who to contact? You can talk to Jason. John Montbriand for DTS needs. And I highly, highly recommend the AppleScript Studio mailing list. There are some terrific people on that list. Some of them are here today. I thank them for their support. It's really beginning to grow into a very wonderful community to help each other out. And we try to put our foot in wherever we can to help along the way. And it's wonderful. So make sure you go there. Sign up for it if you haven't already. And then the AppleScript mailing list is exactly the same. same way.