Good morning. Welcome to Session 513, System-Wide Previews with Quick Look. My name is Jean-Pierre Ciudaad, and I'm a member of the Quick Look engineering team. So what we're going to talk about today is a new technology in Leopard called Quick Look. We're going to see what Quick Look really is, we're going to see how it works, and how you can take advantage of it in your applications.

So let's start with what is Quick Look. So Quick Look is a technology that helps the users identify their documents. The way we do this is by providing thumbnails and icons of all the different document types in the system, and also by providing previews of the documents. So those previews appear in the Quick Look preview panel, and they can be pictures, they can be movies, they can be PDFs, or they can be text or HTML documents.

So Quick Look is essentially about navigation. It's not about editing documents. If the user wants to edit his document, he has to open the application that is used to edit that document and not use Quick Look. So strictly about navigation. So you're probably all familiar with Quick Look already if you've been using Leopard. Finder, starting with Leopard, has been using Quick Look extensively. In fact, prior to Leopard, Most Finder windows were displaying generic icons.

In Leopard, you started seeing thumbnails of the documents, sorry, icons of the documents, I should say. But the regular icon mode in Finder is not the only place that uses Quick Look. Quick Look is also used in CoverFlow View, which displays thumbnails, or also when you press the space bar on a document, you actually can see the Quick Look preview panel that shows you the content of the file.

Other applications in Leopard also use Quick Look. Mail, iCal, both use Quick Look to actually display previews of the attachments. In addition to that, iChat also uses Quick Look. In Leopard, we introduced iChat Theater, and iChat Theater actually uses Quick Look to obtain the content of the document and send it across the wire. So essentially there, if you provide a Quick Look plugin for your document types, you will enable your document for iChat Theater. That's all you will have to do.

And of course, we hope that for Snow Leopard, Quick Look will be in your application as well. And that's what we're going to talk about. So how does it work? Well, Quick Look is really divided into two functional parts. The first part is the producer side of Quick Look, which tells Quick Look how to read a file. The second part is the consumer side, which displays the content of the file or the thumbnail in your application. So let's look a little bit more at the producer side.

The producer side of Quick Look translates complex document types, not into French, but into a set of known formats that Quick Look knows how to display. So these formats can be HTML, PDF, text, images, or movies. The way this works is by using plugins that developers like you provide, and those plugins know how to read the file. They are loaded on demand and executed on demand. In order to write a plugin, you can just use an Xcode template that is provided in Leopard.

On the consumer side of Quick Look, you can use the consumer side to display thumbnails and icons within your application. You can also, starting in still Leopard, you can open the Quick Look preview panel and show previews of documents. The way you do this is by using the Quartz framework, and we're going to go into more details for that.

So what are your options? Your options are simple. You can either be a producer, or you can just be a consumer, or you can be both. What we would prefer is that, first and foremost, you become a producer. If you own the document types, it is important that you write a Quick Look plugin so that your icons and your thumbnails will be available everywhere in the system. It will be available system-wide everywhere that uses Quick Look.

If you want to become a consumer, you will be able to display icons and thumbnails of all document types within your application. So now to tell us more and more details how to become a Quick Look producer, I'd like to introduce Quick Look superstar, Julien Jalon. Julien Jaalon: Thank you, Jean-Pierre.

Good morning. So we'll first talk about the producer side of Quick Look, which is a very important part of Quick Look, because Quick Look's goal is really to display any kind of document. And this includes your own document. And to do that, you have to become a producer for Quick Look. And you can do that by providing a Quick Look plugin. And we'll see how to write a Quick Look plugin today. And you will see that it's quite simple.

Before going into more details, you have to understand that your plugin will be hosted in a small process that will act as a sandbox to the consumer. This means that your plugin will have to play by the process rules, which means it has to be universal. Starting with no Leopard, it has to be 64-bit, and also you won't have access to garbage collection.

So, let's see the different key points of writing a Quick Look plugin. You have basically three things to remember. The first thing is that Quick Look should be able to identify your document type. The second thing is that you have to make sure Quick Look is able to find your plugin. And the third point is, of course, to do the actual job, translate your document to something Quick Look understands.

So, first point, make sure Quick Look can identify your document. And in fact, it's not specific to Quick Look. It's something that has to be done for all kind of stuff, like Spotlight, and even for opening your document with the proper application. So to do that, you have to make sure your application registers your document type to the system-wide typing database, which is Launch Services.

You do that in the application's Info.plist. What you have to declare is what we call a type identifier, which will be the reference to your document type. In your Info.plist file, you will also declare how to identify the file, what is the icon of the file, the generic icon, and stuff like that.

As a side note, it's possible to ship a Quick Look plugin standalone, without your application. So if you want to do that, you might have to declare the document type directly in the plugin. And you can do that For more information, I really recommend that you get a look at the Xcode documentation about uniform type identifiers.

OK, second point, Quick Look has to find your plugin. And to do that, you have to make sure your plugin is in a well-known place. Basically, you want to include your plugin directly in your application's bundle in contents, library, Quick Look. And this is a great way to distribute your plugin, because you don't have to care about installation. Your application is totally standalone for the user. It does not have to see that there are plugins inside it.

But if you plan to ship your plugin standalone without the application, you can install it in /library/quicklook, and Quick Look will be able to use it as a system-wide plugin. The second thing, of course, is to tell Quick Look that your plugin is handling your document type. And you do that by declaring the binding in the plugin Info.plist. So you will use the document identifier you declared in your application in your plugins Info.plist.

The third point, of course, is doing the real job, to write some code to translate your document. And to do that, it's fairly simple. The idea is, in fact, Quick Look, when the consumer asks for a preview or a thumbnail, Quick Look creates a small object that represents the request, calls some specific callback in your plugin, providing the request itself, the file URL to the document it has to thumbnail or preview, and some additional options.

And we provide a small set of API or CPI that are very, very simple. It's a quick look framework that gives you the opportunity to answer the request. So, let's go into more detail. Basically, your plugin has to do two things. Thumbnail previews. So, you have to implement two callbacks. The first one, this one, is a generate thumbnail callback.

Fairly simple. You have a handle to the request. It's a file URL to the document. And some additional options. Generally, you don't have to care about these options because Quick Look will handle them itself. But it might be useful for you to decide what to put in your thumbnail depending on the options. But generally, you don't have to care.

To answer the request, the API is fairly simple. The first idea is to provide an image, a CG image, a core graphics image. This is the first API. Or you can provide JPEG or PNG data if you have that, or any kind of ImageIO-supported image format. And if you want to, you can ask Quick Look to create a Core Graphics context so you can use all the Core Graphics API to draw your thumbnail on the fly. You create a context, use the Core Graphics API, and flash the context, and Quick Look will do all the rest.

The Generate Preview callback is pretty similar to the thumbnail callback. You have the request, the file URL, some options. Generally, you don't have to care about the options, but we never know. So the goal of the preview callback is to translate your document to some data Quick Look understands, which means HTML, movie, text, images, PDF. To do that, we have a very simple API. You just have to give Quick Look the data.

But for the sake of simplicity, we also include a very simple API so you can create a core graphics context, again, similarly to the thumbnail, so you can draw your preview on the fly. And if you plan to produce a multi-page preview, you can also create a PDF context and use begin page, end page to create several pages for your preview. So, this was a theory, but we will do a small demo just to see how simple it is. Let's switch to the demo machine, please.

Okay, we'll do a very, very simple Quick Look plugin. And since we are in a developer conference, we will do a plugin for developer kind of file. So we'll do that for Xcode projects files. So, The idea is to start with a new project, and the good thing is that we provide with Xcode a template to write a Quick Look plugin. So you don't have to care about most of the things.

So we create a new project. So the template, in fact, does almost all the work for you. It creates all the necessary files linked to the appropriate frameworks. And in fact, you have three things to complete. The first one is the Info.plist part. I would say it's paperwork. The second thing is the generate thumbnail callback.

And the third thing is the generate preview callback. So let's start with the paperwork. So this is the Info.plist. It describes a lot of things about your plugin. The first thing to do is to give your plugin an ID. So since I'm working for Apple, I will call it com.apple.qlgenerator.xcode.

And the second thing is to bind my plugin with the appropriate file type. And the type identifier for Xcode project file is com.apple.xcode.project. And you can see that there are other kind of stuff you can fill. All this stuff is quite unnecessary for you. You just keep it like this.

But you have some specific Quick Look properties here that gives Quick Look some hints on how to use your plugin. Basically, you can specify a hint about your preview size or thumbnail size. But you can also declare to Quick Look what your thread awareness is, you know, if you are more or less thread safe, if you have to run in a main thread or stuff like that. It depends on the framework you use, on your code. That's the kind of stuff you can specify to Quick Look.

So, in fact, that's all for the paperwork. What we'll do now is we will try to implement a Generate Preview callback, and you will see it's fairly simple. To do that, I will start, sorry, by... I have a small code that parses Xcode project files and translates them to the appropriate data. In fact, it might be the most difficult part because you know how to parse your documents, you know how to convert them. That's what I have here.

So I will add that to my project. Voila. And as you can see, this is a small code that uses foundation code and Objective-C. And you can do that in a Quick Look plugin. You can use foundation, AppKit, or a lot of high-level frameworks. So since we are using foundation, we will add foundation to the linked frameworks.

Okay. So what is this code? This code is very simple. It just takes the file URL to a project file and converts it to some very, very simple plain text with a list of all the files that are related to the project. So this is a very, very basic plugin I am doing here. Of course, afterwards, we can refine it and make something look much better. But that's not the purpose of my presentation here. So let's implement the generate preview callback.

So you have the request here, the file URL, the type identifier of the file, and some options. And our goal is to convert the file to plain text data in this case. So we'll use-- oh, I have to include my file first. We'll use our function. This function converts the file to plain text data, UTF-8 encoded.

And then we just have to give the answer to the request. So first part, this is the most basic API to answer a preview request. You specify the preview request itself, the translated data, the type of the translated data. In this case, it's UTF-8. Plain Text. And some additional properties. In properties, you can specify a lot of metadata for your preview, like your real preview size and some other kind of stuff.

And basically, that's all. Your preview callback is written. But the most important part is now to test it. And of course, if you remember the three key points, you will have to make sure the type is correctly registered to launch services and make sure your plugin is installed in the correct place.

But during development, it's quite annoying to do all of that. And to do all of that, each time you change some code. So that's why we provide a tool to do that, which is named QL Manage. QL Manage is really your helper to develop your plugins because it can execute your plugin directly.

And also you can bypass all the paperwork, bypass the type checking, bypass the plugin discovery. And that's what we will use now. Since it's a... It's a tool that can execute your plugin. It's a very, very good candidate for custom executable in Xcode. That's what we'll add now. You add a custom executable QLManage. And with QL Manage, you can specify a lot of different arguments. The first one is to ask QL Manage to bypass all the type checking, so you don't have to care about that during the development phase.

The second parameter is to ask QNManage to bypass the plugin discovery, so you don't have to care about installing your plugin. The third parameter is to ask QL Manage to do a preview. So the -p is asking QL Manage to do a preview. And we'll do a preview for Xcode project file, which is the reason we are writing this plugin.

And we just have to run it, build it, and run it. Oh, okay, so I forgot one thing, is that, as I mentioned, you know, your plugin has to be 64-bit now in Snow Leopard. Since it's a 64-bit machine, I have to build my plugin 64-bit. That's what I will do right now. Let's do that again. And voila. This is the basic preview of an Xcode project file. Very, very simple. Just the list of files in the project that afterwards you can really provide something much better and much nicer.

OK, this was the preview. Let's do the thumbnail. So when you have to implement your thumbnail callback, you generally face a big problem. What do I put in my thumbnail? Generally, we really, really recommend that you, in fact, just provide the content of your document, focus on the content of your document in your thumbnail. So we'll do something very, very simple. We will use the same input for the thumbnail than what we use for the preview. Just use the same text and display it in the small image or thumbnail, and that will be our Xcode project thumbnail.

So to do that, it's fairly simple. I will call the same exact function to translate my project to plain text data. I have to create a core graphics context and use the text drawing API to draw this text. It's quite tedious, you know. So that's why in Snow Leopard we are adding a very convenient function that will do all this kind of stuff for you. If you can produce a preview, it's very easy to produce a thumbnail in Snow Leopard using this function.

It might not be exactly what you want, but for a lot of people it can be really the only thing to do. If you can produce a preview, you can ask Quick Look to produce the thumbnail the same way. So that's what we'll use here. You will see that it's really, really similar to the Generate Preview Callback.

And instead of using Preview Request API, we use Thumbnail Request API, and we have this very convenient Function that gets the same exact input as the preview API, but produce thumbnail instead. So you provide the data, the type of the data, And some additional properties. Here, nothing. And that's all.

Just as a reminder, one thing is that this API is very convenient, but it has a little drawback. You know, since it is using some Fairly high-level drawing API, it has to be run in the main thread. It's not a pure thread-safe function. And you can tell Quick Look your plugin is not totally thread-safe.

This is what we saw just before in the Info.plist. We'll have to tell Quick Look, okay, my plugin is great, but I have to make sure it runs in the main thread. And this is what you can specify here with the needs to be run in main thread property.

So we'll check that. And our plugin is ready. But what we'll do is test it now. Instead of -p, we'll use -t to produce a thumbnail. Okay, build and go. And we have our thumbnail now. It's pretty small, so we can change some of the property. Also, it's quite flat, so we will add some icon decoration. Dash I tells Quick Look to produce a nice icon, and we can also make the thumbnail bigger.

And voila, we have our icon for Xcode project files. So it's fairly simple. But if you look at the icon, you will tell me, well, it really looks like a plain text document file. And you will be right. And what you can do in SnowLeoPard now is to add some additional decoration to your icon. What we don't want you to do is to introduce the decoration directly in the thumbnail.

So that's why we're adding this API for you to provide additional information about your icon, but alongside the thumbnail so we can really decorate the thumbnail content and the decoration itself. So in SnowLeoPard, you can add some badging to the icon. That's what we'll do right now. It's very, very simple.

If you do remember, in the API, in the Quick Look API, there is always... last parameters in the answer API, which is the properties parameter. And the properties can specify additional information on the thumbnail or icon you are producing. And that's what we'll use now. And you can ask Quick Look. So I have some here. Very simple.

What you have to do is just to create a dictionary telling Quick Look to use a small extension badging. And use this dictionary as a thumbnail properties. And so to make sure we are not leaking, I'm Rolling the dictionary. And if we run it again, you see that you have the extension here now.

But you might want to go even further. You might want to include something more specific to your brand, like an image. And you can do that in SnowLeopard. It's really, really, really similar to the extension stuff. Instead of providing a text string, you provide an image. So let's do that. I have a small image here I want to add to my icon. And instead of providing text, we'll provide an image here.

So this is, in fact, the most difficult part of this code is to load the image itself, you know. But it's fairly simple. Afterward, it's very similar to the extension. You provide a badge image and the image itself, and you use the properties as the thumbnail properties here. Run it, and there you are. Wow, yeah, it's not very nice. You know, I'm not a designer myself, but I'm sure you can do much better than that. And that's it. You have your icon.

Thank you. So you can see it's very simple. Let's go back to the slide. So you can see it's very simple to write a Quick Look plugin. But if there is something to remember, it's simple, and you have a very convenient tool to debug and develop your plugin. And this tool is QLManage.

QLManage is really the Swiss army knife of Quick Look. It can execute your plugin directly without all the complex Quick Look engines, the process, the daemon process, the problem you have to use to go in Finder to verify that your icons are looking great. It can do a lot of stuff.

In particular, it can bypass all the paperwork, the typing, the installation. That's something you don't want to do while you are writing your code. You can do a lot of new stuff in Snow Leopard. We try to enhance this tool a lot. It can help you test your performance and do a lot of other kind of testing, like try your icons in different sizes.

And the last important thing that Quick Look, QL Manage is doing is, in fact, it can help you reset the cache. Because in Snow Leopard, for performance reasons, we're adding several levels of cache in Quick Look on the consumer side and on disk and stuff like that. You don't have to care about it.

In fact, it's very good for the user, but it might be very annoying for you developers because, of course, once we have cached something, you want to reset the cache, and QL Manage helps you do that. For more information, there is a manual included with QL Manage. Let's go take a look at that. It's very simple, you will see.

One important thing, and I know that a lot of people are doing that and it's not a good idea, QN Manage is only a debugging tool. You should not use QN Manage as a consumer to display generally the preview panel. It's really not what you want to do.

So it's simple to write a Quick Look plugin. But in fact, you might face some problems. And in general, you might face two problems. The first one is performances. You have to make sure your plugin is as efficient as possible. In fact, some things should be extremely fast because your thumbnails will be displayed with a lot of other thumbnails, and your plugin should not harm the computer resources. We are trying to be very efficient, but if your plugin is taking too much time or taking too much resources, it might end up being very bad for the user.

So you have to find the right balance between quality and performance. And to do that, really, you might have to remove some details. You know, this is just a thumbnail. And if you are designing your file format right now, we really encourage that you include in your file format a JPEG data or PNG data with a pre-generated thumbnail. And if you do that, you won't have to pass the whole document to produce a thumbnail. You will just have to get the data directly from your file and send it back to Quick Look.

On the other hand, previews need to be fast, too. Maybe not as fast, but still fast. This is very important for the Quick Look experience. Quick Look experience is about to be quick. And the user, when the user opens the Quick Look panel, he does not want to see the loading placeholder. He really wants the preview to appear immediately. So you have to make sure your preview callback is very, very fast, too.

This means that you will also have to find the right balance between details and speed. And what we recommend, for example, if you are producing a multi-page document, a multi-page preview from your document really caps your number of pages to a small number. And in fact, with Snow Leopard, we are introducing a new API so you can provide the pages later.

The second problem you might face is design. And you saw in my demonstration that I am not a very good designer, and that generally is a problem you will see. And the very important thing to remember is just focus on the content. Thumbnail and previews is just about displaying the content. In fact, it's really only Quick Look responsibility to add the extra decoration to your thumbnails and previews.

In particular, for thumbnail, this is Quick Look that does the curled-up corner and stuff like that. So only focus on the content. Don't add any more bells and whistles inside your thumbnails. We are providing some additional APIs for you to customize your icon if you really want to, but don't do that inside your thumbnail.

The same thing applies for previews. You should not assume that your preview will only be displayed in the Quick Look preview panel. And in fact, it does not. It's operating in the cover flow. You know, you can scrub through pages. It's also used in the Finder info panel and in the column view, too. And it might be used in very different places afterwards. So don't assume anything on the context. Just focus on the content.

So let's summarize how to write a Quick Look plugin, because this is the most important thing for this part. It's very, very simple. You start from a Nixcode template, and you fill in the holes. Do the paperwork in Info.plist. Implement your callback. Then test and debug with QL Manage.

And finally-- You just have to install it in the right place. Inside your application, if you plan to include directly your plugin in your application, or if you want to have it standalone, install it in /library/quicklook. So this was the producer side of Quick Look. But there is another side of Quick Look, the consumer side. And that might be very interesting for you. And for that, I am calling Julien Robert on stage.

Thank you, Julien. So now that you've seen how to write plugins, we will switch to the other side of Quick Look, that is displaying thumbnails and previews in your application. So let's first focus on thumbnails. Thumbnails are simply static bitmap images that can come with or without icon decorations. So when they are without icon decorations, we call them flat thumbnails, and this gives the user a quick overview of the content of their documents.

Icons give you the same information about the content of the document, but also highlights the file aspect of the document. So for instance, you can see the curled corner or the glossy effect on these icons. So let's see a little bit more in details how to use these thumbnails. Flat thumbnails do scale well, so you can use them in high resolutions. So they are well-suited to be used in inspector, preview pens, But also in other fancier views like 3D views, which is an example of CoverFlow, or other views that you can imagine.

Icons are more likely to be used in views that are displaying a collection of files, like browser views and list views. Or to be used as file handles, that is when the user will want to interact with your document as a file, like clicking on it, dragging it, and stuff like that.

So let's get a bit technical now and see how you can get and display thumbnails. Well, first, you can use an API that we've introduced in LeoPard. It is a Quick Look API. So this is a very simple and synchronous API. You just give a file URL and the size, and it returns synchronously a CG image ref.

And if you want to have icons instead of thumbnails, you can add this option to the Options dictionary. So this is a synchronous call. So also we try to be as fast as we can. Some generators, some plugins may still take a while to generate the thumbnail. So don't call this on your main thread because it will be a bad user experience.

You have also another solution that is using the ImageBrowser from ImageKit. So the ImageBrowser is a view that draws images, but can also be used to browse files and display thumbnails. So to have thumbnails in the Image browser, you should use the Quick Look path representation type. And for more information, I invite you to watch the ImageKit session.

So this is actually a good solution for you. This may be a good solution for you. For several reasons. Well, first, for performance reason, because we worked hard with the ImageKit people to have a very efficient way to get thumbnails. And also for you, it's very easy. It's a very easy solution. So we will see that later. So now that we've seen how to get thumbnails and icons, we'll see how to get and display previews.

So previews are more accurate representation of your documents. They are richer and more dynamic. So users can see several pages of your documents. It can have sound. It can scrub in movies, stuff like that. And previews are available through the Preview Panel. So I suppose you've seen the badge. The Preview Panel APIs are new in Snow Leap Part.

So how do you actually use a preview panel? Well, first, you have to import quarts and link against quarts. And the preview panel is available as a singleton, a shared preview panel. Then the first thing you want to do is to open and close it. So the preview panel is just a regular NS panel. So you just use NS Window APIs to open and close it. And you may additionally want to open it directly in full screen, so we have other APIs to do that, that are the same as you can find on NSView.

So then, when you have the preview panel open, you want to fill it with contents. So the preview panel is using a data source model that is quite standard and similar to what you would find in the image browser, for instance, but also in table views and other collection views. So you just return the number of items you want to display in the preview panel, and then you return the item for the specified index. So we will see later what is an item.

Additionally, you can implement some delegate methods to add polish to your Quick Look experience. For example, the zooming effect is quite important because it gives a good feedback to the user. And also you can provide us with an image to make a crossfade to the preview panel to have an even smoother transition.

What are these items? Well, they can simply be NSURLs or, and that's more interesting, they can be your own objects, providing they implement the actual preview item protocol. So say you already have items on your model that represent files, and you want to display them in the Preview panel. So just by making sure they implement this protocol, you can directly give your items to the preview panel. So the advantage is that in all callbacks, you would get your item, so it may be easier for you to retrieve the requested information.

An important aspect of the preview panel is that its content depends on its context. So, for example, if the main window is changing, The preview panel has to reflect the new selected item in the new main window. So the rule is that the Preview Panel always displays the selected item in the main window.

So how does it work? When we see that the responder chain is changing, we first try to find a controller that is willing to control the preview panel. So we do that by walking through the responder chain. And we select the first object that responds yes to this method. Typically, this would be your window controller.

So then once we have this controller, we tell it that it will begin to control the preview panel. So it receives this method, and that's where it's supposed to set up the preview panel, like setting the delegate, the data source, and call reload data on it. And then, when the ownership of the preview panel is given to another object, we tell the previous controller that it no longer has control on the preview panel. So we send this method. So you should be aware that you can do, you can call some stuff on the preview panel only between the begin and end calls, and you are not allowed to do anything not between these two calls.

So let's see a bit more. Let's see how Event Handling is working on the Preview panel. Well, first we have standard shortcuts to open the Quick Look panel. So it's Command-Y. And additionally, if it fits well in your application, you can use the space bar to toggle the preview panel. Also, you can add the Option key to go directly to full screen.

So once your preview panel is open, it's a key window, so events are routed directly to it, and obviously your view underneath is not getting any events. So if you want to still be able to handle events by yourself, you can implement this delegate method. So typically we use that to be able to navigate in your view while the preview panel is open. So what you do is just implement this and return yes if you handled the event, and no if you want the preview panel to handle it by itself.

Use this mechanism and don't give key to your main window because that's not the way to do it. So we'll see a little bit more in details. So we'll first see how to use the image browser to display thumbnails, and then we'll see how to use the preview panel, so how to open and close it, track the selection, and add the zoom effect. So can we switch to the demo machine, please? So here I have a very simple application, TotalWinLaunch. And it just displays a collection of files in a window using the image browser from ImageKit, so I can zoom.

So it's very easy with ImageKit to display a collection of files, but we just have icons, so it's kind of boring. So the first thing we want to do is to have thumbnails instead of icons. So in my items that I use in the data source for the image browser, I'm just changing the image representation type to use Quick Look. I run it again, and boom, I have all my thumbnails. So as you can see, we can zoom and still have beautiful thumbnails. So when you write your plugin, keep in mind that the thumbnails may be displayed at quite high resolutions.

So next thing we want to do is to add support for the preview panel. So let's do that. So we have some manual attempts that are hooked to these methods. So the first thing we want to do is to toggle the preview panel. I just uncommended. And also we want to add support for the spacebar.

So I just uncomment that too. So what it does, it's very simple. Just open the Preview Panel if it's not visible, or close it if it is. So let's run now. And if I use-- Open the Quick Look panel. So it opens, but obviously it's empty because we didn't set any data source. The next thing we want to do is implement the controller method that we've seen.

So here, so I am in my document. So it's in the responder chain, and we obviously accept to be controlling the preview panel. In the Begin Preview Panel Control method, we set ourselves as the delegate and the data source of the preview panel, and then we tell the preview panel to reload its data. And in the end call, we just make sure to remove ourselves from the delegate and data source.

So next, what we want to do is implement the data source. This is a very simple data source. So first, we retrieve the selected items as an array. So these are the same items that we use in the data source for the image browser, but we made sure to implement the True Health Preview Item Protocol. So we just return the number of items in this array, and then return the item in the specified index.

So if I run now-- And press the space bar. You can see that the preview panel is correctly displaying the selected item. So one interesting thing to see is that if I have two windows, And with two different items, selected items in the windows, if I switch between the two windows, you can see the preview panel correctly reflects the change.

But we are still missing some things, like if I'm in the same window and I change the selection, the preview panel does not update its content. So that's the next thing we want to do. So you have to tell the preview panel to reload its data when the selection is changing in your view. So in our example, we use this delegate method from the ImageBrowser. So the first thing we want to do is to check that we are the current controller for the preview panel. And then we just call reload data on it.

So if I run the application again, make that a little smaller. And if I change the selection, so the preview panel correctly displays the selected item. But we are not totally done yet, because as you see, we have no transition. And also, when the Preview panel is open, if I try to use the arrow keys, Well, nothing happens.

So we will fix these using delegate methods. So this first delegate method is to have a zooming effect. So it's pretty simple. First thing you want to do is to get the frame using the image browser APIs. When you have the frame, you have to convert it to screen coordinates and return that.

And the other method simply forwards the keyed-down events to the image browser. So if I run it again, we can see we have a nice zoom effect. If I use the arrow keys, this time it works correctly. And the new selected item is correctly previewed. So we are done with our little demo. We can go back to the slides.

So to recap what you need to do to add support for the preview panel. Well, the first thing, obviously, you want to import and link again the Quartz framework. Then you need to add calls to open and close the preview panel using the standard shortcuts that we have. Then you need to implement the controller methods and the data source.

Also, don't forget to tell the preview panel to reload its data when the selection is changing in your view. And additionally, but it's highly recommended, you can implement some delegate methods to add polish to your Quick Look experience. So to conclude this presentation, I will call Jean-Pierre on stage. Thank you, Julien.

So the first, Julien showed you how to write a Quick Look plugin, and the second, Julien showed you how to use Quick Look in your application. It's important that you write a Quick Look plugin so that your documents can be beautiful everywhere. In the Finder, in Mail, in iCal, and in all the applications that are going to be using Quick Look in the future.

Please polish your thumbnails. They need to look absolutely fantastic. Also focus on performance. You want to make sure that they are generated really, really, really fast. Now, we also want you to use Quick Look in your application, of course, so that you can show all types of documents within your application with nice thumbnails and nice previews.

So where to get help? You can find documentation. Our current documentation online is Leopard documentation. We are working on updating it for Snow Leopard. Our header files also contain quite a bit of information. We have a public mailing list. So remember, this is a public mailing list, so you should only be asking questions about the Leopard API.

You're welcome to ask us questions, and we'll answer as soon as we can. You can also attend the Spotlight and Quick Look Lab. We will all be there answering your questions. This is tomorrow at 5:00 p.m. You can watch the ImageKit session, session 735, if you want to learn more about the ImageKit image browser.

And if you have any other type of questions, you can contact our sharing technologies evangelist, Matt Drench. And of course, you can find us during the conference and come and talk to us. We'll be tomorrow night at the little party at the Yerba Buena Garden, and we'll be around the show during the week. Thank you for coming, and have fun with Quick Look.