Good afternoon, ladies and gentlemen. Please welcome the User Experience Technology Manager, John Galenzi. Good afternoon. Welcome to session 144. This belongs to the user experience sub-track, sort of. And the reason for that is that In all of the user experience sessions so far, we've been talking about Aqua-related things, so the look and feel of TAN, how to properly design icons, how to lay out your dialogues, these sorts of things that we talked about in the Aqua overview and some of the other sessions that have occurred so far this week.

As I said in the Aqua overview session the first day of the conference, the Macintosh is known as being friendly and easy to use. It's known as being consistent. And one of the most sort of notorious behaviors of the Macintosh is that when you... Movement of files around the file system is very easy. You can move folders of whole applications. And when you move files and documents from applications around, the Mac always knows which application created it.

When you double click it, it knows which app to launch and these sorts of things. And it never sort of forgets these types of relationships. This session is going to talk about a lot of... It's going to talk about this subject matter and we're going to talk about packages, which are new for 10. Well, they're on 9, but they're important for 10. So there's a packaging your applications, putting all of the pertinent files in one place so that users have a really great user experience of moving those things around as one unit.

And we're also going to talk about the relationship of documents to applications and so to welcome on stage, to talk about this material, I'd like to call Arno Gerdahl, who comes from the user experience engineering team at Apple. Arno Gerdahl Good afternoon, everyone. So I know this is a -- if you come to this session, you probably are wondering a lot about what we're thinking. And I hope that by the end of this session we'll have answered some of that question and that you'll feel better about this whole topic.

My name is Arno Gourdol. I work in the User Experience Department. I'm going to talk to you today about two main things. The first one is

The other thing I'm going to talk about is the double-click user experience, you know, what happens when you double-click. Again, that's more like a behavior, but that's a very important one, and Mac OS has always had a very good user experience in that regard, and obviously we're making changes in Mac OS X, which I'm going to talk about.

So, back in the old days, an application was a single file, and it was very easy. When you wanted to install the application, you just dragged it. That was it, and you had everything with it. Everything used to be in a resource fork. I don't know if you remember that. It was years ago.

With the introduction of PowerPC, the code portion got moved to the data fork. So, in the data fork, you had the code itself, and then in the resource fork, you had the resources for the application, the strings that needed to be localized, the user interface, and so on.

Today, on Mac OS X, that still works. You can still have that. You can still have your application in one single file. Data four contains the code. Resource four contains the resources. And you can have either a corb, CRRB, or PLST resource-- and I'll talk about that one in a little bit more detail in a while-- to tell the system that you're not just a classic application, but that you're a Carbon application, and that we should not try to launch you in the classic environment, but just in the regular Carbon environment. So that's the minor difference between what we may have had before and what we have in Mac OS X as far as single file applications.

The thing about single file applications, though, is that contrary to this very simple picture, where you have like just one icon and everything looks simple and all that, nowadays what you're more likely to see is something like that, where you have maybe one file for the application, sure, but you have a lot of auxiliary files next to the application, whether that be the help system, the help content, some sample code, some sample documents, or sample code if you're doing a development environment, and all sort of stuff that kind of makes it more difficult for the user to know actually what is it supposed to double click.

And also that makes the application more fragile, because it means that if they move the wrong file, the application may not launch anymore. And you know that that's the kind of experience that may happen on some other operating systems, but we really don't want that to happen on Mac OS X.

So, we're doing things to fix that, to go back to the good old simplicity that we had before. And to do that, we're introducing the concept of application bundle. Let me just tell you that, I apologize in advance that we haven't been very consistent in our terminology. You may have heard the term package and bundle and used sometimes interchangeably.

We're going to try to be more consistent from now on, we promise. So we're going to talk about application bundle to talk about the way an application is packaged. And we're going to talk about file packages to talk about documents that have a similar format. But bear with me, bundle package is still the same thing.

So, what's a bundle? It is a directory, instead of being a single file, as we had before. It is now a directory. And to know that it's a directory that actually contains an application, there are three ways that we can identify it. The first one is you can set a bit. There's a special bit in the HFS metadata that can indicate that this is a bundle folder. And that's actually the bundle bit, which had been unused. It was only used for documents until Mac OS 8.5, Mac OS 9, Mac OS 9.

But now it actually means that the entire folder is to be considered one unit, if you will, one bundle. There's also a special file that we're looking for inside the directory. And if we find it, we know that's a package. So it's a second way to do it. I'll talk about that file in more details in a little while. And finally, there's another way that this can be indicated, is by using an extension, a three-letter extension, .app. There you go.

but it's not over That can tell the system that this is also a package, even though it may not have the bundle bit set, and even though it may not have the package info filed in there. So the reason for the extension there is just in case the application gets moved around into maybe a file system that doesn't know how to deal with that, with the HFS metadata, and the bundle bit gets unset for some reason or something like that. So it's like more a safety precaution than anything else. Important thing to remember: .app is not required. You have two other ways to indicate that your application is actually an application.

OK, all right. Now, there are a few bugs left in the DP4. Otherwise we would ship it. And one of them is the way-- sometimes you actually need really to put it in .app to make it understand. Another thing that we are not doing in the DP4 right now is that if your application has .app, we'll actually display it in the file system and we'll want to change that later.

So there's a few caveats with DP4 we're not quite done, but that's the direction that we want to go where you can that something is a package one of three ways you choose If you are familiar with the previous version of Mac OS X, Mac OS X Server and before, there was another format for bundles that was slightly different than what I'm going to talk about. That format is still supported. We still recognize, we still understand it, but we don't recommend you using it. So you can just, if you don't know about it, you can just forget about it. And if you are using it, you should consider using the new format now.

So what's inside this directory? We have multiple binaries for different runtime environments, multiple localizations, and all the auxiliary files that may not be that important for the user to see and that could break the app if they get moved around. What's important about all this, though, is that we want to get back to that. We want to have everything that makes an application be presented as a single icon. That's the goal. To go back to the simplicity that we had 16 years ago, even though things have changed a little bit in the meantime.

So the way we're doing this is that we're having this box with all this neat content inside of it. But it's a nice way to put everything together and to carry everything together around. And you can use it as a whole without having to dig through it. And that's what the user is going to see. That's the user experience we want to have. We want to have one icon, one application, something very simple.

That doesn't mean that you can't have any files outside of it. Maybe it makes sense to have a readme next to it or something like that. But again, nothing important should be outside of it. Now, let's see what's inside the box. We're going to open it, and I'm going to talk about all the components of what goes inside a package.

This is kind of what it looks like. I'm using this fictitious--well, actually, it's not so fictitious. It's on the CDP4 CD, but it's a sample app. It's called Sketch. And at the top you have the Sketch directory, which is what it really is. And inside of it there are a number of subdirectories, which I'm going to detail.

You'll notice that I'm using two colors on the slides. The things that are in yellow are the things that, for which the system expects the name to be what is indicated here. You can't choose it to be anything you want. The things that are in white is left up to you. So that's going to be true in this slide and the others I'm going to have after that.

So, the first thing, the thing that matters the most, I guess, is the binary, the actual executable for your application. Where it's located is inside contents, which is basically where most everything is. And inside of there, there is a directory that's called Mac OS, with no space, that contains the, that's expected to contain the binary for Mac OS X.

This binary can be either a CFM or Mac OS based binary. It doesn't matter. Both either will work. And it can contain a resource fork if you want one. In the case of CFM, you really do. Otherwise, it's not going to work so well. In the case of Mac OS, you don't have to.

In general, I know that there is some concern about that, too, about resource fork, and some confusion about what we're saying there. What we want to have is we want to have something that works really well in environments that don't support resource forks that well, like other operating systems, other volume formats, so that we can operate nicely with all those different environments.

And one way to make that easier is to not rely on the resource forks so much. It doesn't mean never use resource forks. It means if you can live without resource forks, if you can do everything we do today without resource forks, or using a different format for the resource forks, which I'm going to talk about, then that means that your application, for example, can live on a server that doesn't know anything about HFS metadata and can still work there. That means that you can use some wonderful utilities such as Tor to package your application and ship it around, or you can easily FTP it or whatever. So there are some advantages to that.

And, you know, we're encouraging you to do that. As much as possible, that's what we're trying to do on the system. The system we're trying to have everything work potentially without relying on HFS, although, of course, the system is designed to work best on HFS. So that's the binary.

You can have resources in there, but there's a better place for it, and I'll talk about it in a while. So what we recommend that you have here is just the code that's necessary to make your application do something. Next is a very important file, and I'm going to talk about it several times today. We call it the plist, or Info.plist.

Sometimes it's also called info-macos.plist. And the reason for that is because you can have either a generic version or a version that's specific to Mac OS X or a version that's specific to another runtime environment. It's basically always the same file. It's an XML file. That contains a lot of information about your application.

The system uses that to basically know everything there is to know about your application. What's your name, when were you born, what documents you know how to open, everything you know how to do, which icon should be displayed for your application, and so on. And I'll go into some detail about the content of that file in a while.

Package info is another file in there that is a very simple file. It's eight bytes and it basically contains just the type and creator, which is also information that's available in the Info.plist. It's redundant and the reason why we have it here is only for performance reasons so that we can very quickly find out what the type and creator of a package is without having to pass the XML file necessarily.

So it's an optimization, but that file is important because I talked about it earlier, the presence of this file can help us figure out that something that looks like a directory in fact should be presented as a single file, whether it's an application or an application bundle or a file package.

If you don't have a creator, for some reason your application doesn't have a creator because it's a legacy application for whatever reason, that's okay. You can still put, you know, for question mark as the creator. That will work and we'll just use the type, which in that case would be appl if you're an application.

Finally, in the resources directory, we have everything else. And I'm going to show you what that is. The first thing is going to be something that all your apps are going to have, which is an icon for the application itself. The PList contains a reference, which is the name of the file that contains the icon. And you're going to look for that file inside Resources.

So here you see it displayed in white. It means the name can be whatever you want. But it will have to be the same one that's specified in the PList, of course, that we know to find it. If you have icons for your documents as well, that's where they would be as well. And the PList, again, would indicate what the name of those files are so that we know where to find them.

You can have your own stuff in there as well. If your applications support filters of some sort, export filters or graphic filters or any kind of additional data things that the user can install optionally, that kind of stuff, you can put that in there as well. You can have subdirectories. You can organize that however you want, exactly the same way that you would organize your application today if it was just in one big folder. So that's up to you. We don't impose any organization in there.

You can also have a file that's going to contain resources in the Macintosh sense of the world and Mac OS Toolbox sense of the world. If you have a file in there that has the same name as your binary, but it has .rsrc at the end, we will open that automatically for you because we'll know about it and we'll figure out that you probably want to use that file.

Before I was telling you, you know, if you want, you can have binary that doesn't contain any of the resources, it just contains the code. You can do that, have the resources in there, and when your binary gets launched, this file will be open automatically for you so that, you know, you don't really have to do anything. It works like it always did, even though the things are now living in two files.

Now, one thing that's important about resources, whether it's this particular resource file or others you may have, is that with DP4 we're introducing a new format for resources. And that format-- hang onto your seats-- it's a resource fork that lives in the data fork. So it's exactly as if you had, you know, what you would have in a resource fork, the same binary stream, if you will, except it is stored in a data fork. That's exactly how we're going to call that, resources in data fork or something like that.

But the advantage of that, the reason why we did that, is that what it means is that anybody, any OS that's out there today, any utilities or whatever, knows about those things. They can back them up, they can compress them, they can encrypt them, they can do whatever they want with them. It's just a file for them, it doesn't matter. And the resource manager now has routines that allow you to open those things and create them and manipulate them and so on.

But again, as I mentioned, if you just put that file in that location with the name of your binary and .rsrc, we'll just open it for you. Whether it's stored in a data fork, whether it's stored in a resource fork, it doesn't matter. You'll just get your resources. That's what counts for you.

The resources that are in this particular location, that are just in the resources directory, are things that should not be localized. And sometimes it happens, maybe there's a logo of your application in there, maybe there is some various data that you need to have in there for whatever reason.

But those that are in there should be things that are not localized, that will stay the same no matter what the user preferred localization is. The things that do need to get localized, however, go into a folder That's called, for example, English.lproj. Obviously, that's not the only name it can have. There are some relatively generic names that indicate the region, like English and French and Japanese.

And you can also have more specific one if you want so that you can have find level A great deal of control so that you could have, for example, the French-Canadian version versus the French version or the Belgian version or whatever. And the system will pick which one to use based on the user preference.

You don't have to do anything. As long as you provide those directories, the system will do the right thing and will pick whatever is available. So if the user said, you know, I really like to have my applications in French, and you happen to have a French localization, that's what will be used.

If you don't have one, we'll fall back according to the user preferences. And if you only have one, that's the one we will use. And again, you don't really have to do anything for that except follow this layout for your application. So that allows you to ship one application that contains multiple localization for your different markets. It's a very efficient way of doing it.

Inside this directory, there's a special file that you can have that's called localized.rsrc. And the same as the one I took before, sketch.rsrc. It can be the file that contains the resource fork with your resources in it. Or it can be a file that's your data fork that contains the resources. And just like the other file, it will be open automatically. So you'll have both the non-localized resources as well as the localized resources open by the time that your application is running. And the right ones, too, without any effort on your part.

If you have other type of data that needs to be localized, for example a help file, you can put it in there as well. And you can use some APIs to find those files and to find the right ones, to find the English one versus the French one, you know, depending on the user choices and so on. There are APIs to do that that make it really easy.

Okay, so that's kind of what's in resources. A lot of information that we're really hiding from the user because they're not interested in those details most of the time. Overall, that's what an application bundle looks like on Mac OS X. It's a directory with a lot of structure, a lot of files. Some have to be there because the system uses them. Others, they are left for you to put whatever you need to put in that folder.

When we introduced Mac OS 9, we introduced what we called app packages. We're calling them bundles now. They're the same thing. They haven't changed, just the name. And the structure is slightly different. And that might have confused you when we were talking about bundles and packages and, you know, looking at the tech notes and saying, "Hmm, it looks like this.

I look on DP3, it looks nothing like it." So what does it all mean? That's what it looks like on Mac OS 9. Or that's what we recommend that it looks like on Mac OS 9. On Mac OS 9, you have much fewer constraints about what the layout of your directory is, mostly because the system does less for you. The only constraints that you have really for Mac OS X is that you should set a bundle bit on the folder, because that's the only thing that Mac OS X recognizes.

And at the top level of this folder, you should have an alias to your application, to the binary that you want to use on Mac OS X. It might be the same one that you are using on Mac OS X if you're a Carbon application that can run in both environments. Or you can choose to have a completely different one, to have an application that's completely tailored to Mac OS X and have a completely different application running from Mac OS X. A completely different binary, I should say. But from your user point of view, it will be the same app.

This alias should be relative. That's detailed in the tech note. I'll give you the reference to the tech note so you can find more details about that. So that, again, the thing can be moved around and the alias will always point to the right binary. One thing that we're enhancing over what we have described in the tech note previously is the addition of--it's just a suggestion for 9, really. It helps make things more consistent. And that's the addition of the contents directory with the Mac OS Classic directory inside of it. And the reason for that is because it's going to mesh well with Mac OS X.

So, on 9 you could have something that looks like this. The alias, contents, Mac OS Classic, and then in there, your binary and whatever files you have. Of course, on 9 you don't get support for multiple localization. It just works like it does on 9. And if you want, if you're doing a Carbon application and you want that application to be able to run both on 9 and on 10, you can merge those two models together. So you get something like this.

On this side over there, you have Mac OS Classic that contains all the stuff that's needed for 9, your binary, help file, whatever is needed there. You have the alias that points to somewhere in there that's going to be used by Mac OS 9. On the other side, you have the Mac OS Info.plist packaging for resources that are used by 10.

What's important, though, is that at the top, you have only one item. When the user double clicks on that item, that icon that they see in the finder, whether it's on 9 or on 10, the right thing happens. Although it's going to be something completely different depending on the runtime environment, but from the user point of view, the right thing happened.

And again, they can move it around and all the pieces come together and they don't have to worry about, I don't know if I need that file, I don't know, that doesn't look right to me, and the application doesn't work anymore. Don't want that. At this point, I'm going to give you a little demo to show you what a package application bundle looks like.

If we can. Yeah! So I'm running classic, you noticed? It works, kind of. So, let's have a look at that. So I have this CD here that contains-- that's a CD that I've inserted in the machine. That's a fake thing. I just pressed that last night. But I can give you an idea of the things you can do now with Mac OS X. For one thing, you'll notice that I have a background for my app. And it's not made up of little icons that are put together. You can't select them and move them around.

It's a picture. So we can take advantage of that to make some interesting things. And then there are a few things that are at the top level of the CD, like the icon for my app, which is actually an app bundle, and goodies that contains the installer stuff and maybe additional stuff that a user might want to install, and just a README file.

So the idea is that a user just bought your app, they put the CD in, they read the README if they want to-- hopefully they will. And they just drag the app maybe. In some cases, you might not even need to have an installer. So keep the things as simple as possible.

So let's have a look inside that application here. I'm going to do a get info on it so you can have a look at what's inside. And I'm going to give you a few tricks that you might want to write down because I don't think we've actually put that in the documentation, and it is useful during your development.

In GetInfo, there are several panels that apply to this item. One of them that's particularly interesting is application files. It kind of gives you an idea of what's inside. But sometimes you really want to look inside the folder. And we used to have a button in DP3 to do that that we removed in DP4. It might come back. But in the meantime, very important, and that's where you want to write down, you want to press the Option key while you double-click on the icon there.

So, new in DP4 is a relaunch service that relaunches your apps really quickly. Let me give that another try.

So, that's the content of my package. I'm viewing it at least through here so we can disclose the thing and see what's inside it. This is a package that was designed to work both on 9 and on 10.

So at the top level here, it has an alias to the application that I want to use on 9. That application itself is in there, inside contents, Mac OS Classic. And now that's where I'm playing with fire. I'm actually going to try to launch it to show you something that's kind of cool. This, believe it or not, is actually MacDraw 0.9. Look at the date, August '84, and it still runs on Mac OS X.

So the point of this is that you can have a very different app for your Mac OS 9 version than you have on Mac OS X. Of course, if you want, of course, you can have a carbonized version that's going to work both on 9 and on 10. The other stuff that you have in here, in here I have some custom folders that are specific to my application, color palettes here. The very important Info.plist that contains all this stuff about my app. Later on I'll go into more detail what's in there. And then in there I have the binary for my Mac OS X version of my app. This happens to be a Cocoa, Java Cocoa app.

While this one obviously isn't. So we see we support multiple runtimes. That's kind of cool. The package info file that tells us about the type and creator of that thing. And then the plugin, another folder for my app. And then inside resources, a bunch of other files that my app needs to have access to. Some TIFF files that contain different pictures displayed in the user interface of this app. The localized version of resources. The nib, since it's a Cocoa app and so on.

So you can go in there, move things around, do whatever you want with it. Of course, you don't want to encourage your users to do that, but sometimes they may need to actually have access to that and we'll give them access. But that should really be the backdoor version of configuration of your app.

I've mentioned that we also support multiple localization. So the way that this works is that in the system preferences, There is one of the elements of system preferences, international. And international, you have a list of languages. And the user can order that however they want. If they want to have French first, they can have French first, then English, German, whatever.

What that will do is that that will have a direct effect. When they double click on their app, the system will use that list to figure out in which order to look for languages. So here if I have put French first, the first thing the system will look for would be the French localization. Open that and use that. So that's where those things are controlled. OK. I'll come back to this mission later.

There is a session later on this afternoon that will talk in more detail about that. In particular, it will talk about the APIs that you have that give you access to the content of those things so that you can go in there and ask for files so it looks in the right directory and so on. This afternoon's session, 1:57, all A1, 5:00 PM. If you're interested in that and what kind of APIs are available to get access to that, go to that session. Okay, now I'm going to move on to another topic. Talked about how to package your app together.

And now I'm going to talk about what happens when you double-click on documents. So that's what we call doc binding. What it means is the binding of an application to a document. In other words, that's the double-click user experience. That's a very important part of the Mac OS experience, and that's something that we really care about a lot.

So I'm going to give you five easy rules to follow for document binding. And if you follow them, nobody gets hurt and everything's cool. First one: all the app have to have a .app, and it cannot contain any spaces, because spaces are evil for Unix. You can only use /space, right? Hey, that's the first one. Come on, I have four more. All the apps must live inside /bin/app. Otherwise, we don't know about those apps, and they just won't run.

Did someone upload there? All files must have a three-letter extension. Because if they don't, we just don't know what to do with them. There is no creator and type. That's something of the past. We're moving forward toward three-letter extension. No more creator and type. They're evil. And finally, hey, I'm just a misenter here. And finally, to install an app, it's very easy.

That's actually what they do on some other operating systems. So, for those of you who are believing everything you read in rumor sites, But don't. That's not quite how it works. What we want to do in Mac OS X with regard to dark binding is to preserve the ease-of-use of Mac OS 9. We're very conscious of that, and obviously that's something that we want to preserve moving forward with Mac OS X.

But that's not where we want to stop. We don't want to do something that's just as good as Mac OS 9. There are a bunch of other things that we want to take into consideration. The first one is we want to play nice with others. What I mean by that is that we want to interoperate really well with other operating systems because we realize that we don't have 100% market share yet.

We're working on it. So there are other operating systems out there, and it's important that files that get created on our operating system, or that your applications, if they're stored on remote servers and so on, work. And don't get in the way of the administrator of the servers and so on. If you know some administrators of those types of servers today, you know that they don't always like when they have Mac users that get on the servers, because we tend to leave crud all around.

So we want to behave better in that regard. Also, with regard to different volume formats, HFS is a great volume format. It's very modern. It has multiple forks, extensive metadata, all sort of very nice features that we want to preserve. And that's why HFS is the main volume format for Mac OS X. But at the same time-- we want to be able to live in an environment where there are other volume formats that may not be as smart as HFS is.

So we want to fit in in this wonderful universe of We also want to work in an environment that's much more networked than it used to be. Each user can log in. We want them to be able to have their different preferences, not to share them necessarily. And that requires to make some changes, which I'll go into more detail. And finally, even though the Mac OS 9 user experience for double-clicking is great, we think that there are some improvements that can be made, in particular for more advanced users.

Think that for novice users, it works great. It always does mostly what you expect, except when it tells you that it can't find this app and that app, and that you have to use ResetIt to change the type in creator. Aside from those minor details, it's pretty good. But we want to make it better, in particular for more advanced users.

In other words, we want it to make easier to use and more powerful at the same time. And that's not easy. Let me tell you, that's not easy. That's what we're trying to do with Mac OS X in general, but this is particularly an area where the ease of use is very important, and adding new features also is long overdue.

How does it work? How does document binding work? A very important concept in document binding is the concept of the document type. which didn't really exist in Mac OS 9 before. You had the file type, but the file type doesn't tell you anything about other ways that you can represent what the format of this document is. One way is the file type. That's definitely true. But there might be other ways. For example, extensions, which are used on other operating systems, on the internet more frequently.

And in some cases, just the content of the file, maybe there's a header that contains a signature or something like that, can tell you some information about what this file format is. So we've abstracted that by having this concept of a document type. And that's just a string, arbitrary length, that defines that. You define those strings inside your information plist. I'll show an example in a while, what it looks like. But for each type of document that you know about, basically, you'll have an entry. And this entry will be indexed by that document type string.

Other info: the type and creator that can be used to identify the type of document. Again, this is specific to HFS, stored in the HFS metadata. We support that if it's there, you know, if you have an HFS volume format and your document has a type and creator, of course we're going to use that. But we also want to work when it's not there. So it's optional because HFS might not always be around where your documents are stored.

Okay, so file extension is something new to Mac OS. Mac OS never had the concept of file extensions per se, and we're introducing that and trying to have some nice support for it. The definition of a file extension on Mac OS X is it's something at the end of a file name that's up to 32 characters in length after a dot. Some things to keep in mind about extensions is that they are not localized, so you don't have to worry about having different versions of the extension for different localization and all that. That's not the case. That's not intended to be localized. They are not case sensitive either.

And the characters that you can use in extension is actually fairly reduced. You can use A to Z, 0 to 9, and the characters $%, _, and ~. And if there are any other characters that you really, really want to use for some reason, let us know about it. But I think that with this, we're covering enough. And the reason why we're limiting the character set is because by doing that, the users still have the freedom to use anything that's not dead, basically.

An example of that is that we have also another limitation that if an extension has only one or two Digits in it. We don't consider it to be an extension. And why do we do that? Well, because we want to allow you to have something like surfpaint 1.0 and not have us confused and say, ".o?" What kind of extension is that? I wonder if there's an application that can open .o? So .0 is not an extension.

.0.revb is not an extension either. Can you tell me why? It has spaces in it, exactly. To be continued dot dot dot is not an extension either for a number of reasons because dot is not a valid character and depending on how you parse it you might actually consider that it's empty. Some valid extensions, on the other hand, are the always popular xvnd.386, foo.c, well that's an extension that you might have heard of and used before.

And Doug.SurfPant. And Doug.SurfPant. I can't say the case, but you see the difference, right? They're the same. They're the same extensions. Like I said, the case doesn't matter as far as extensions are concerned. And that's another example that shows you that if you want, you can have--it's not just three characters anymore. It's up to 32. So you can use your entire application name if it makes sense.

Of course, if you already have some extensions that are defined for your document types, because your application is cross-platform, for example, and you had to deal with those issues before, use the same thing that you have on those other platforms. The whole point of this is to make interoperability easier. So don't have extensions that are Mac OS X specific, because that would be kind of missing the point. If you want something that's Mac OS X specific, use type and creator. Don't use extensions.

Okay. This is something that we're going to try to implement as soon as possible, but it's not yet in DAP4. And that's a hint. And I want to talk to you about that because that's something that I think it's important that you're aware of and think about it, because we could do some interesting stuff with that.

A hint is basically it's a sequence of bytes in the first K, the first 1024 bytes of a document. That can help us identify what the document is. That's also referred to as a magic cookie in Unix. That's one of the good things of Unix, see? There are some.

And that's also something that's used sometimes. Not all popular document formats have that, but very frequently they do. For example, Acrobat PDF files, the first four bytes of an Acrobat PDF file are always percent PDF. So if you just look at those four bytes, you have a PDF file, even if you have no extension and the typing creator has been lost for some reason.

So putting all this together, if you have a document that's just called image.jpg without any type in creator-- maybe that's something that you just downloaded. Maybe it's an MP3 from Metallica or something. Well, we can still tell from the extension that the type is JPEG file. If you have the type, we're going to use that.

And even if there is no extension, even if it's just called image, again the same thing, we're going to know that it's a JPEG file. And finally, if it has just the name image, no extension, and no type in creator, by looking at the proper byte sequence at the beginning of the file, which for JPEGs happens to be FFD8, FFE0, we're going to know still that it's a JPEG file.

What's important is that in those three cases, no matter how, the end result is the same. We know that it is a JPEG file. And once we have that information, we go on to the next step, which is going to be to find the application to use to open that thing.

The way this works on Mac OS 9 is that there's the infamous desktop database that needs to be rebuilt every so often. It's a per volume database, which was a problem for us, because we wanted something that would follow the user rather than work differently depending on where you log on.

And one machine does something and another does something completely different. So we wanted something that had more customization that was more per user. And also, there were other serious limitations. It was very difficult to extend, to add any sort of information beyond what it already knew. It was already trained, but what it's holding. And it only knows about type and creator and the extensions and all that.

So basically, the desktop database will continue to be used by Mac OS 9 and Classic. The Mac OS X Finder still maintains it. So if you copy an application that has-- A Mac OS 9 application, for example, between two volumes, Mac OS X Finder will do the same thing that the Mac OS 9 Finder did, which is to update the desktop database appropriately so that they're all synchronized.

But it's only used as a fallback when there is no other information. The preferred mechanism that we use now is a registration mechanism, which is not that different from the desktop database, which means that before we know about an application, we have to run into it. There are a few well-known locations, which is basically where we are going to recommend users that they store their apps. And that's not going to be /bin/app.

And they're not going to have to put them there. They can really put them anywhere they want. But there's few well-known locations. We'll go in there and we'll look to see if there are any new applications that have been installed, anything that has changed. And we'll use that kind of as a basis. We'll start with that as a starting point. So it's the applications folder. And in DP4, there are several applications folder, probably too many applications folder. We'll clean that up eventually. But we'll still look in those places where we have those applications folder.

If for some reason an application has not been registered yet, launching it will do that, and sometimes just looking at it will do that. The point is, even though there is this registration step that's necessary, very often you won't even see it. Worst case, what can happen is you double-click on the document and it needs an application we've never seen before.

We're going to ask you, you know, I don't know about this document, where's the app for that? You're going to find the app, and that will be it. We'll remember from now on, you know, oh yeah, that app, okay, fine. And as a side effect, we'll probably register all the apps that were next to it too, because we'll figure out, hmm, maybe there are some other interesting stuff in there.

OK, when we run into an application, we try to learn as much as possible about it. We remember where it lives. And we look inside the P list to extract all the information in there, such as what is the signature of the application, the bundle name, its version number, creation date, et cetera.

And we're going to use subsequently that information to find back which application we're supposed to launch. So that, for example, unlike-- which is another limitation of desktop database today-- it's basically the last application that got registered that wins. And the registration in the desktop database is non-trivial. So that means that if you have a version of Photoshop 4 and Photoshop 5 on the same disk, you double-click on something on the Photoshop document, and sometimes one version will launch, sometimes another version will launch. And you never know which one. So, because we have now all this additional information, such as the version number and creation date and so on, that allows us to give preference to more recent versions over older versions, for example.

The application signature, if you're a Carbon developer, you may be familiar with that already. It's a four-character code. I will remind you that there are some invalid ones that you're not supposed to use, which are 0, four question marks, and four spaces. If for some reason you don't have a signature, which can happen, maybe you're a Cocoa app who never had a signature and, you know, Use four question marks when you don't know what to use. We encourage you to register your app signature and to get one. At the end of the talk, I have a URL that you can go to to do that. So if you don't have a signature, it's really easy to get and it can be useful to have.

There are two ways that the bundle information, the binding information, can be specified. One is the way that it's always been done, using a BNDL resource and all its related resources, to indicate which file types you know about, what the icons for those file types are supposed to be.

And that's pretty much all you can specify using a BNDL. It's rather limited. We still support that if you're a Carbon application or a classic application. We'll find out that information, register that, and we'll live with it. But if you do that, that means that you have no way of telling us, oh, by the way, those PDF files, OK, sure they can have the signature PDF space. But I also know how to deal with them if you find a file that has the extension .pdf that you download from the internet or whatever.

So with the BNDL resource, you can't tell us all that. With the PList, you can. And the way you use the PList-- so again, you have two choices, depending on how your application is packaged-- if your package is a single file-- As your application might be today on Mac OS 9, then you just add a PL/ST resource that contains the same content that an Info.plist would. Otherwise, you can just have the Info.plist file in there.

That's what's inside the Info.plist file. It has a number of keys. It's an XML file, as I mentioned before. The number of keys and different values. You have some things such as the name, the identifier, which is used to unique--so that we have a unique identifier for your application, other information, signature, version, get info string, et cetera.

And then, for each type of documents that you know about, you specify what the type name is, the icon file to use, what the valid extensions for that type are. There might be more than one. Think about HTML and HTML, for example. The OS types and the role.

And the role is kind of something interesting. You can specify whether your app actually doesn't know how to handle this type of documents but just knows about them, can provide an icon, for example, or whether you can actually view them or just edit them or print them or provide runtime services.

So there are different--again, those are hints that you can provide us that can help us choose which application is best given what the user wants to do. And at this point, I'm going to show you-- What a P-List looks like. I'm going to try to do that quickly. I'm going to use a... BBEdit for that.

Why not? So I'm going to go inside the directory of my app here, so I find app, contents, and I'm going to have to say, oh, I want any file in there. And that's my plist here. Let me make the text a little bigger. So, as you see, they don't lie, it's an XML file. I've added some comments too, because you can have comments in there. If you don't have to for your app, you're free to do whatever you want there.

You can have some comments and you have the different keys. So the bundle name, for example. This one is actually an important one because that's the key that we use to know what to put in the top left of the menu here. So that's what we call the short name of the application. So user visible name. The identifier, the type and creator, and so on.

And on and on and on. And so here you have the list of all the documents that this application knows how to deal with. That's kind of what it looks like. And then there's a little bit more that I'm going to talk about in a minute. I have a few more slides to go through, and I'd like to have some time for Q&A, so I'm going to go a little faster. Fasten your seat belts.

All right. So here, very quickly, a few examples about how it would work. Let's say that you have a document created by a Carbon and Classic app, type in creator, and the user did not do any customization. Just a quick word about that. It will be possible for a user to either globally say, I want all my HTML files to always open with Dreamweaver, no matter who they were created with. That will be an option. That's not in DP4 yet, but we'll have that by the time we ship, hopefully.

So that's one way that a user can override something. And you can also do that on a file by file basis, where you could say, this file, I created it in Dreamweaver, but from now on, I want it to open in Explorer. And you can do that without using ResetIt and changing the creator and all that stuff. So, if there is none of that, no user customization, you double-click on it, we'll look for the most recent application with a given creator, and we'll use that. It's exactly the behavior that you would have today in Mac OS 9. That's kind of like the vanilla case.

Very simple. If you download a file from the internet, and this file has no type in creator, and let's say it ends in .pdf, and again, it knows special user settings, we will look, see which applications know-- well, first we'll find out .pdf, what type is that. We'll find out it's Acrobat PDF documents. And then again, we'll use the most recent app that knows how to deal with those type of documents.

Now, here's a case where the user has specified an override. They said that there is no type in creator, the extension is .html, but the user has said, I want all my HTML files to open with Internet Explorer, in general, except for this one that should open with Dreamweaver.

Follow me there? So it's kind of like you have several levels of OverEye that the user can provide is definitely more for advanced users, but it's an important feature for some of our customers. And in that case, when you double-click on it, Dreamweaver will open it. Pretty simple.

A few words about installation. Now that we have this box with all the stuff in it, well, how do you put stuff in it? You have to open the box? Not necessarily. In the P-List, there are a few additional keys that you can provide that can be very useful. Those keys can provide us information about what items can be installed optionally in your application, where those items are supposed to be installed in your application, and where we can find them, too.

So, for example, you can specify a source for where those files are supposed to come from, and a list of those files. And for each of those files, going to specify what the name of the item is. You can specify a description that's optional. You can specify where on the CD, for example, this file is to be found, where it's supposed to be installed, and whether the item should be just copied over or whether an installer should be run, which is the case you say that the action should be open and we just launch the installer for that item. Let me show you what it looks like.

So if I go back to my plist, some other information I have in there is the installation information. So that's the key I was talking about, the bundle installer key info. Here I specify where the source of the files I want to install is. In this case, it's a volume that's called surfpand. That's going to be my installer CD. And then I have a list of items. Here, for example, I have a list of color palettes in my fictitious application that users can install.

This is the path on the CD where those items are stored. And this is where they go inside my bundle. So no matter where the application is, that's where they're installed. And now the specific items in this color palette category that describes the different items. And here I've been very simple, just given the file name for all the items. You could also specify a description and so on. And optionally, some other keys such as whether the item should just be copied over, opened, that's what I was talking about earlier.

If you want, you can make it very simple, which is what I did here, and just specify the minimum, which is just the file name. Here I have the same thing for another category, which is plugins. Exactly the same kind of information there. So once you have all that, let me show you what you can do with it. I'm going to quit Mac Draw. And let's see.

So I earlier installed that, and all it means is I just dragged it over. Really not that complicated. I'm going to go back to the application files panel that I showed you earlier. And in this pop-up are different categories of things. One of them is a list of localizations.

So, for example, the user could decide to install just English, if that's what they want, or just one localization. And if there are others that are available, at a later time they can just click the install button to add them to their application or to remove them if they don't want them anymore.

So that's a default category that's always there. And those are the two others that I've added, that I've shown you in the plist: the color palettes and the plugins. Those are the files that I specified in my P-list, and that's what gets displayed here. And you see here on the status column, it tells you whether the item is already installed or not. If it's not installed, you can just select it. I have The CD in the computer, which is right there. Let me go back to my app.

And if I just click here and click install, it's going to look on the CD. It has copied it. It was fast because it's a small file. And voila. The same way you can remove something if you don't want it there anymore. So, same thing with plugins. So that gives the user some very easy way to do some very limited installation.

That doesn't mean that you don't need an installer anymore. You might still want one. But at least for some very simple things, it allows the user to do some installation without having to worry about messing up something because they get access to the content of the directory directly.

So, a few things for you to do. Define a type, but also think about extension for your documents. Again, we want to play nice with all the file system and operating systems out there. You should consider having a unique signature for your application. I'm sorry. Well, that's true for your application, but also for your document format. If it's an existing document format, you may not have this option. But if it's a new one, really think about it.

Register a signature for your app. That's the URL I was talking about. You can go there to register a signature and make sure it doesn't conflict with someone else. And finally, really seriously consider using a plist, either as a single file or even better, as an application package. I hope I've showed you the advantages that we can have to end it, you know, if we all work together on improving the user experience, if you use application packages and Info.plist to tell us more about your application. Basically, that's what it's all about.

If you are still thirsty for more information, here are a few resources: Tech Note 1118 describes the Mac OS 9 packages, which are called bundles now. That's the URL where you can find it. And on the DP4 CD at this path, there's a system overview that goes into what I've talked about, and you can go back to see what the keys are and so on. So it goes into more detail. But that's, again, on your DP4 CD. And at this point, I'd like to ask-- I'm basically done with what I had to tell you today. Thank you for your attention.