---
title: WWDC2000 Session 121
framework: wwdc
role: article
path: wwdc/wwdc2000-121
---

# WWDC2000 Session 121

## Transcript

Kind: captions Language: en ladies and gentlemen please welcome the Mac OS 10 applications technology manager David Wright thank you welcome to session 121 of carbon events one we're going to do this one more time today so could they have it this is a really exciting day today in hall to the technologies being presented are amazing and will increase your productivity tenfold this next session is about carbon events and I just want to hear it how many of you want carbon events like yesterday I just I know it's true yeah when I was working with the team to prepare for this presentation I just was like so grateful that today is here because the number one request from carbon developers has been carbon events because of the productivity code cleanup performance gain that carbon events brings to carbon applications so would you please give a big welcome to advice manager of high-level toolbox an apple software engineering group hope I'm wired up here so the carving event model is without a doubt the most significant change that we've made tuna mac OS toolbox since its inception over 15 years ago and I'm not just saying that cuz I wrote it it's actually a fact this should change the way that you think about the toolbox from just a collection of api's that you call in some hopefully correct order to a model where the toolbox does a lot of the work for you and you just tap into that event flow and override things as you like so what you're going to learn today there's a lot of the basic concepts and terminology that we use when we never whenever we talk about carbon events you'll also learn about how events flow in Mac OS 10 and you'll also learn where wait next event fits into all of this and you'll also learn that I'm right and come to this rock so what is carbon event carbon events is the event system for carbon this isn't something that we stuck on the side of weight next event and just kind of grafted it on this is the event system wait next event actually is built in terms of this new event system but of course you wouldn't you know go through all the trouble of inventing this event system just the way next event on top it's got to be something more to it and of course there is and what that is is there's a completely new way of getting events into your application this is a way where you basically install handlers on Windows controls and menus and get events directly dispatched by the toolbox and the best part is that this new event model can be mixed with the old event model meaning that app set continue to call wait next event can still take advantage of all the features that I'll be talking about throughout the presentation so why did we do this well we wanted to make it really really simple to write a carbon application in fact it's actually possible to write a carbon application in about seven to ten lines of code and we do that by providing all of the default behaviors that everybody in the world has ever had to write in order to bring up a Macintosh app we also wanted an event system that encouraged a high performance especially on Mac OS 10 and we'll go into a little bit of that as we go throughout the presentation we also have these all these nutty disparate ways of getting notifications into your into your application we have event records we have different notifications via call back we also have things like def prox for windows controls and menus and we wanted a system that would actually unify all of those into one consistent homogeneous model and as a side benefit to all of this we ended up getting a system that actually provides much better support for plugins this is a model where events can actually be dispatched directly to the wind the window that's owned by a plug-in rather than having the host application even involved in the event flow so here's a comparison of the current weight next event event model with the new carbon event model so with weight next event you know it's basically your job to do everything you pick up an event from the system and then you decide what to do it so you have to dispatch the event and you typically do this by getting say a mouse down calling something like findwindow deciding is on maybe the mouse went down on the window and based on the result of that call then doing something interesting like dragging the window so as a result you have to write all this code over and over and over and this says resulted in many people writing their own little skeleton applications or things like that just to get a simple app up and running on the carbon event side for pure carbon of in-depth the main AAP is that you would call to drive your application it's called run application event loop once you're inside there that's it your app is running and while inside there all the events are actually dispatched by the toolbox to the appropriate handlers that makes sense for the specific type of event as a result of this you don't have to write that boilerplate code we've done all the work you just do the interesting stuff in the wait next event model in order to get time to do things like link the cursor or whatever other periodic tasks your application might have you rely on something called null event when wait next event didn't have anything better to give you a hand to annul event and you would try to do something interesting with that in the carpet event model we have a concept called timers you would install timers and that's the way your application gets time in the old world the only way to actually override any aspect of what the toolbox was doing what's the patch and obviously you can't patch in mac OS 10 but what we do have is the ability to install event handlers on all of the objects that the toolbox the court and that is the way you override toolbox behavior so here's a conceptual picture of what we're talking about at the bottom we have the carbon event model on top of that we have weight next event run application event loop and on top of that fits your application and your application can call when next advantage of one application event loop but it's also going to talk to the event model directly to do things like install event handlers or timers now the first new thing to be aware of is something called the event loop you'll also hurt hear this referred to as a run loop and this isn't the event loop that's in your application this is another construct very low level in the system inside carbon and this is essentially where events arrive for your application and its main job is to take events from the lower level sources and turn them into a carbon event and put them in your event queue and this is implicitly run for you whenever you call an API like wait next event run applications event loop etc and the best part is that when you call the event loop if there are no events waiting your application blocks meaning you're not spending CPU time doing you know for no reason so I want to just cover the way events actually flow in Mac OS 10 so first some event comes in because somebody clicked the mouse so it comes in to some iokit driver in the colonel colonel just ends up handing that off to the windows server the windows server is what actually where the interesting part happens but the windows server has the knowledge necessary to determine what app this event should go to so it does that by looking at what the frontmost process is you know if it was a mouse down what window did the mouse happen to hit and depending on what the state of things talk it will finally send the event up into the applications event loop and of course the event loop just turns around creates carbon event and puts it in the event queue now the interesting thing to note in this picture is that each app has its own event queue there's not one global event queue like there was on Mac OS 9 the other interesting thing about the event loop in general is that you need to run it in order to get the events in your queue which is a little different from Mac OS 9 because the mac OS 9 all these events Kaman asynchronously they were typically posted through some interrupt handler so once you actually get the events in your application you probably want to do something with it and the way we drive an application is you can either call wait next event like you always have or you can switch to run application event loop again one application event loop is really for the pure carbon event-based step you wouldn't just drop that in I don't think it would do exactly what you wanted but those two AP is actually dispatch events of when they're whenever that when they're called so while you're inside wait next event or run an application event loop eventually gets dispatched to any handlers that you have installed provided the event makes sense for that handler if you happen to need to get an event from the event system and not have any dispatching happen there's a lower level API called receive next event so let's take a closer look at what wait next event looks like in this in this new system so obviously it still works good thing the biggest change is that when it's called like I said events get dispatched and this means that in a sense actually if it event doesn't get dispatched and handled by some handles that you might have installed in your application it actually does not get returned to wait next event and this is actually the way that i mentioned that that actually helps plugins the event will actually get dispatched at some plugin and way next events just never sees it another change from the traditional mac OS point of view is that the sleep time it's fully respected regardless of whether you're in the foreground or you're in the background typically untraditional a mac OS 9 if your app is in the background who respect your sleep time but if you're in the foreground we will just call you as often as possible with null event so this is an important distinction so you might have some scrolling animation in your about box if something to be wondering why is it running so slow a macro is 10 I thought Mike was saying with fat and the point is you're actually sleeping but you didn't know you were so the another interesting thing about weight next event is that way to expect can actually have performance implications on Mac 10 because it's very typical for an application to assume that they can get all this idle time and then just you know sleep for one pic and if we have 20 applications running and they're all sleeping for one tick we're really like using all the CPU and possibly for no for no good it might just be your updating you know pulling for modify or change or something like that here's a picture and just illustrates what happens inside wait next event what wait next event does is it actually iterates through the event queue and for each event start at the top and we peek at the event and we attempt to dispatch it if the dispatching is successful we removed from the queue we go back and get another one if the dispatching is unsuccessful then it's a candidate to actually be returned to wait next event and we usually and we do the usual you know maths test to make sure the event was actually something that the caller wanted if so we pull it out of the queue or done else we move back around now I mentioned run application event loop is the pure carbon event way to drive your application and the reason I said a little bit ago that if you if you just plop the cynic in place of weight next event it won't do what you expected that's because run application event loop once entered never exits until something in your application called squid application event loop so it's expected that you'll just call this in your app and then your app is running and the flow chart looks a little simpler we just pull an event and we dispatch it so i mentioned that timers another way to get time in order to do things like blink the cursor so they can be used to do periodic tasks like that or you can also use them as a one-shot timer so you might want something to time out in a couple of minutes best part about this is that you can actually put the timer code with the code that wants it you don't have to rely on some outside entity to be gracious enough to hand you some idle time you just say I want idle time and you'll get it a good example of that is metatext control that wants to blink the cursor it can install its own timer and it will get that time to blake the cursor in some ways this is really similar to something like a contract in power plant we might have L periodic which kind of doles out idle time the main difference of course is that we're actually doing this inside the event loop and we can do it a lot more efficiently and we will block it to the appropriate time which won't happen in something like L periodic another important distinction something I just want to clarify is that these timers run a task level these are not asynchronous to your application they're very deterministic and when they fire and they fire when you call the event loop so when you call wait next event your timers require when you call run application event loop your timers will fire and they fire serially one after the other so it's very well understood when these things are going to fire however there are also calls that will fire timers that you might not expect for example there is a there's an API called track mouse location and we're actually going to see an example of this later in and especially in the next section the track my location as replacements we're doing your standard Mouse tracking but in order to do this what it does is it actually blocks on the event loop so you might be tracking a mouse down event but timers will be firing and this might seem odd but it actually leads to some pretty cool functionality the core event type of carbon events is the event rep this is the replacement for the event record this is your new friend essentially it's opaque data type and like most of the toolbox types and you get at things inside this data type with accessors if you're familiar at all with apple event this is going to seem like a really familiar type in that every event is actually identified by a class and a kind so we might send you a an event of class mouse but the kind is mouse down we also have you can also have an arbitrary number of parameters on any event and you get at them via some symbolic name and they're actually pseudo type safe just like Apple events are we also have retain and relief semantics and if you're familiar with this from a core foundation terminology you know what I'm talking about if you have no idea what I mean it's just fancy terminology for ref counting and we do that to handle threaded cases and the best part about event reps is they're not just a one-way communication idiom they aren't just something happened they can also be used to retrieve information from some entity for example the window manager might send a hit test event to a window definition the window definition could actually take that event put in the park code and then the center of that event will get that part code once the event comes back times are much more expressive in event reps event records have x expressed in terms of ticks ticks are very very coarse-grained especially for some of the new input devices that are coming out things like you know high-resolution tablets and stuff which really want very very fine time stamping of events we actually express this time in a double so we use a floating-point a type to represent our time which might seem a little odd but the fact is doubles have very fine precision and though we're currently using nanosecond granularity for our event times if we can get down some data whatever picosecond granularity we don't have to change our data type because it still can be expressed in terms of the flow and of course events are no good unless you can do something with them so obviously you can post them to the event queue but the most important thing is that you can send them to objects and that is what the carpet event model is all about and where you send an event is an event target this is an abstract concept but what it is is it's just a place to send an event and they're normally associated with some sort of tool box objects so if you want to send an event to a window you get the windows event targets by calling yet window.event target and each target has a stack of handlers that have been installed and they're a real stack so when they get installed they get pushed on top of other handlers that might have already been installed so the topmost handler is basically who gets the event first and that handler could turn around and say I handled it or it could decide no I didn't handle it let somebody else deal with it and it does that basically by returning the right OS status result and this is the overriding idiom this is the way you override and customize the tool box just just by the mere fact that you've installed a handler means you're overriding something you're going to get an event and if you say you handled it well then it's not going to fall through to the toolbox which may do something or it made you nothing but you know you got first crack at that event and that's the important part this is a conceptual picture of an event target so here we have an event target with three handlers the one on the bottom is for the object so let's use the example of a window that object handler might be the deaf proc or the deaf proc replacement in terms of carbon event on top of that the toolbox might have installed its own handler which provides standard behaviors like dragging the window around but on top of that your application might have pushed another handler and that handler might say well you know I like all that dragwon of stuff you're doing but I really wanted to dr. the size of the screen that's where you'd actually be able to tap in and override what was going on so an event comes in it tries to go down as far as to cancer that stack of handlers and eventually yields a result either it was handled or was not handled if it wasn't handled we end up trying to send it to another target in the event system and we use our what we term as our standard containment hierarchy of the tool box to determine this and the hierarchy is largely defined by you know windows and controls and sub controls rely on control embedding for a lot of this and events are automatically sent to the innermost object possible if you click on a button the button will get to click first then the window and then it will fall through the application the application is like the catch-all for every event that we send out and this is just a picture of that payment harder hierarchy pretty standard shouldn't surprise you when we send an event out it may or may not be processed so if the toolbox gets a click we may send it out to some specific object and it may not be handled well we may decide what we kind of know what it is we're going to send out another event which has a little bit more semantic meaning so what started as a click could cascade into something really meaningful like a window moved and in general you want to listen to the higher level events rather than the lower level events because it means you didn't have to do all the code necessary to actually drag the window around so if we take a visual example of that say a click comes into an application and we send it out nobody responds to it we feel bad but we turn around and we take that and we actually say oh you know what that was on the zoom box let's tell people who's on the zoom box so we sent out another event saying the zoom box was hit and nobody responds we still feel bad but anyways we go on and we say oh we know what to do when that happens we'll just track the widget oh it was a sex we'll trap and successful tracking us whatever so let's just broadcast out to the window it needs to be zoomed and if nobody cares about that we'll just zoom the window and say hey the window was doomed now the benefit of all of this is that you can actually tap in at any one of these levels and intercept any one of these events to get the level of functionality that you want you might not care about any of this stuff maybe you don't even care that the window assume you know you want to support that feature but you don't want to deal with the you know the code necessary to drive that you know we can take care of that maybe you really have a problem with the way the tool boxes are zooming I can't imagine that but if you do you could just override that part of it it's totally up to you so we have a lot of events that we've defined we used to be limited by the size of the event mass the event mask was limited to 16 events because the event mass with 16 bits wide kind of limiting so in the carpet event model we have lots of events we went nuts so some of these events you already know you know things like mouse down you know things like window update went to activate but we also introduced a whole new set of events things like control hit process the command please or the window was moved or a zoomed or whatever I want to talk about a couple of specific events that have changed or maybe are a little better maybe I should have shown that later so the first one I talked about mouse events we now actually have multi button mouse support if the system tells us that the right mouse button was hit will tell you I mean we have no problem we just give you the information and also if you load up DP for hook up your favorite USB mouse and start moving the mouse wheel we're going to start sending you a mouse wheel events and if you actually look at the simple text example that is on DP for you'll see how to handle it it's kind of a hack but it works and the last thing is we have multi click detection so you don't act necessarily need to determine that a double click happened we'll just tell you all right now to make you set keyboard input keyboard input is actually different than it was it used to be pretty simple you get an event it had a key character and the key code and the actual character that was typed what we want to do in carbon is provide we want to provide full Unicode keyboard input so we change things a little bit now going to jump the last point which is that it's a calling wait next event you're still going to get keyboard events just like they used to nothing has changed however if you're using the new event model you need to be aware of a couple of things first there are two types of keyboard events there are the raw key events which are the ones that just basically tell you which virtual key was pressed and then those can actually build up into text input events and that happens through TSM TSM is built in this means that your app doesn't necessarily have to become TSM aware it is TSM aware if it's a carbon application automatically so the wrong key event like I said they're pretty much just a virtual key code but TSM actually does do a little bit of processing on that before it handed to you but the result of that may not be what you expect the event may not have any character information in it it may be part of a dead key sequence or it may have multiple characters in it depending on the keyboard layout and TSM just uses these and processes them and event and talk to input methods through these through in terms of these events but the most interesting low level keyboard event is the keyboard modifiers changed event with this you don't have to pull for modifiers anymore we'll just tell you that the modifier is changed it's very simple which is another reason that you don't have to pull so the actual text input event when it comes to you is one or more unicode characters and this is the result of TSM talking to any input method that may be present or up and finally it'll just give you some unit charge you actually look in car events H you'll see the text input events and what that what their names are and you'll notice that they look very similar to what the old TSM Apple events were and that's because the carbon event version of those events is the replacement for the old TSM apple event this doesn't mean that we won't send those Apple events it only means that we will only send the apple event if nobody responded to the carbon event so in that way we actually prefer the carbon event model what advantage of having a text input event like this is that you can actually unify keyboard filters and paste filters into one thing so I just always assuming that you might have more than one character coming in to your edit text field and text input is a unique problem in that we need to know where the text input goes if we have something like a mouse down pretty evident where it goes we just look at what window it happened to hit the keyboard event we with a keyboard input event we kind of need to have something tell us where the event should go and emaki was eight we had a concept of the keyboard focus for any given window and that's fine that's great we love it but we need to know which window so we have this concept of user focus which is a combination of a window and any focused control in that window if the window happens you have or we the toolbox defines this the user focus to be he currently focused control in the front most document window that's our definition of us if that window happens to have no controls or nothing has focus then it's the window in order to send an event to use a focus we have an API called get user focus target and that might be actually we return the target for e control or a window but it's really not important you just want to give the text to somebody who might care if for example you need to redirect the user focus you can do that the best example that I can provide for this is you have floating palettes in your application and you're typing in your document and then use your clicks in a floating palette and now you want the keyboard focus to go there you can use set user focus window to say that's the window that has focus now please send all text templates there and will obey that and that would be the way that you would override it normally the toolbox deals with all of this stuff and you don't need to Mac OS 8 we introduced concept of menu command which was a not a new concept but it allowed position independent way of identifying your menu items what we've done in corporate events is we've created these things called H I commands which are essentially just a wrapper around those menu commands they basically contained the command plus a little bit of extra information necessary in order to have the toolbox dispatch it properly and why is that important well we actually want to dispatch commands to the originator of the command first and then send it to user focus so let me give you an example of why we'd want to send it to the originator first best example there is a plugin a plugin might install a menu into the menu bar and it would really love to just get those events itself all it would need to do is install the menu install the menu handler on that menu and then whenever a selection was made from that menu it would actually inform the plugin first and if the plugin said I handled it that would be it and to process why we want it to go to the user focus is because usually commands and menus apply to the currently selected control or field or something like that best example is an edit text field you know cut copy and paste obviously apply to the you to focus and we've predefined a whole bunch of commands if you look in carbon events H we have things for like quit copy paste a number of things and the interesting thing is that a control can actually generate a command as well and we'll actually see an example of that very shortly so short in fact that is now so what I'd like to do is actually bring up guy bulletin who works on hltv with me to show you a little demo and he's actually over there ok so if I can switch over to the demo machine that would be helpful so as ignorance mentioned earlier in the presentation the toolbox is attempting to become a framework it's attempting to do a lot of the work that your applications used to have to do on its own and we want to make your lives easier and allow you guys to write a lot less code and just deal with the code that that gives your app the unique functionality and I want to show you a couple admittedly fairly simple examples of that the first one is a simple hello world application it's got one source file fairly short about a page page and a half of code our main does some fairly simple stuff we install a standard menu bar we create a window we install an event handler on that window we show the window and we call the run application event loop API that I'd mentioned earlier and then we quit when our event loop exits we're going to end up being done our window handler looks for two events we look for a draw content event and we look for a window closed event we do a little bit of special processing I have an APR sorry I have a routine which does my window drawing and then I have a utility function I called for my main routine called the install standard menu bar there's no event processing in this code at all i'm never calling way next event i'm never fetching events I'm never looking for clicks from the menu bar eclipsing windows or anything like that and when I run the app you get the simple app and it does a lot of the stuff that your application normally has to do on its own it tracks menus you can move the window around you can grow it you can window shade it and do all the stuff that you would expect a normal matt ghosts n application to do and you did it in about a page page a pacote so a slightly more i want to show you slightly more complex example when we're doing work on the toolbox we're doing a lot of work on user interface and you know the last several months have been spent on aqua and we have to do a lot of checking to make sure our interface is just right we need to zoom into pixels and make sure right shadowing is going on on all this stuff but for mac OS 10 we didn't have a tool to help us doing that to help us do that so last year we actually wrote a tool called magnify to do that and we thought well we're writing an app for the ground up we might as well you know test out our carbon event model and see how that's going so we decided to implement it with carbon events and it ended up being really really easy to do so once again I just have one source file it's a little bit longer than hello world probably yeah four pages of code maybe one of the main pieces of code is a timer that I'd mentioned we've got a timer that execute every so often this is this is the real meat of the application right here in this one function we have a routine which creates our window right here we have an event handler for that window which only looks for one event I believe and we have a command handler that we're going to end up installing on the application to handle a few special menu commands and finally we've got our main you know probably only 10 12 lines of real code we install them any bar we install our application handler we do some hoops so that our timer can we jump through some hoops to our timer can do some work later and then we create our window so it's not a super simple app but as you can see it really only did the work that matters to that application and when I run it we get our magnify app which simply magnifies the pixels underneath wherever the mouse happens to be and ed mentioned timers and how they fire sometimes when you may not necessarily expect but when it's still very powerful so if I happen to oh I don't know drag the window around you can see that well if the timer still firing will still updating the window it's not exactly an interesting update but if I pull down the menus the time we're still firing and still drawing into the window and a few menu commands i wired-up gets into the application magnification level and the last example I'd like to show you actually ties into interface builder interface builder is one of the new tools we're showing our Mac os10 and we've done a lot of carbon integration into interface builder it's got a way by which you can create a carbon application let's see I can select carbon application nib basis takes you through a little assistant to do those kinds of things but I've already got a project setup so I'll go ahead and open that up and this is what it would look like when you first create it it's got two interesting pieces in it it's got some source simple main dot C probably only about 20 lines of real code it simply loads the interface from a nib and creates the window which is also from a nib and calls run application event loop and the nib is what defines a little bit of interface fairly simple once again it's just a window and project earth sorry interface builder does this for you automatically it creates sort of a simple one window application interface and if I run that you get what you expect a simple one window application interface and once again we do all the standards behavior for you we track the menus we move the window we resize the window we can window shade the window and do all those things you would expect but I want to go a little one step further let's actually add some functionality to the app and at the same time cancel that and get that out of the way uh-huh that's not what I want that works okay we're back in the nib he'd mentioned that you can attach commands to controls so let's go ahead and do that I'll drag a button out of the interface builder palette and put it in the window and if I bring up the inspector for that button it's got a field by which you can associate a command ID to that control now there's a whole bunch of standard system commands that we offer and the our application event loop pays attention to these commands and does what you would expect so I can go ahead and just tell the command tell that control that hey you wish you the quick command no save my nib go back rebuild should take a second done rerun and I've got a window with a button in it and of course if I click on this button the buttons going to issue the quick command but I didn't install any special command handlers on the control or on the window or on the application to handle it so when I click it it's going to propagate up to the application object and get caught by the toolbox handler and of course it's going to quit the application and it does it all for free so if you if you take a look at a tool like interface builder and and how it takes advantage of the carbon of n AP eyes and look at the power that carpet events in the command dispatching and all the auto event handling gift to you you can see just how easy it is to make carbon applications from scratch on mac OS 10 right [Applause] so you just seen an example where you can basically bring up an interface from some data store in this case in interface builder nib and have the toolbox deal with all the user interaction in that window and then potentially just tell you about the interesting things well it seems like we kind of already had something like that and we used to call it the dialogue manager everybody's friends a dialogue manager well with all the stuff that we've been working on and carbon events the dialogue manager is effectively obsolete this doesn't mean it's not supported this doesn't mean they were taking it away from you but it does mean that you can do pretty much anything that you could have done in a dialogue with pure carbon events now we have things like interface builder support we have the ability to actually reference a controlled by a an arbitrary ID that you assign and we also will be supporting window modality without actually resorting to using modal dialogue the best example of where we're headed with that is if you check out the adopting aqua session which is tomorrow you'll actually see how some of our sheet ap is rely on this modality and sheets are completely carbon event based measures at the beginning they were trying to unify different models well one of those models is the def proc model instead of a callback based def proc what we really wanted was an event-based def proc and we have that in DP for windows and controls are completely driven through events the old def prox don't exist anymore this doesn't mean you can't create a button apart but carbon events is the native model and we're just going to keep doing more and more of this as we go forward with the toolbox and the beauty here is that you can override these events like you would anything else if you don't like the way the control draws intercept the draw and do something cooler I don't know actually if you stick around for the second session that's my plug to keep you here will actually tell you an example of some of the cool things that you can do with this stuff and while we redid this stuff in carbon events we took the opportunity to actually clean up the messages get rid of some old messages it didn't make any sense and of course the beauty of all of this is that depth rocks were really like weird it's the best example I can think of I mean for each different message you needed to learn the arcane rules of what would come through the program parameter and what you should be returning and in controls there was a thing like test new message support and all its weird stuff carbon oven current events just make that go away I also mentioned at the beginning that we wanted an API that would encourage performance specifically on Mac OS 10 and we do that in a number of ways the first is timers it is highly recommended that you use timers instead of small-time ups and wait next event and this is largely because timers are much more efficient to fire when you're already in the event loop restarting the event loop has a cost another way to help your app perform well on Mac was tenants to adopt track mouse location the second session shows an example of that and again I mentioned the beginning that this is a way to rewrite your mouth tracking loose the traditional mouse tracking loop will actually pin the CPU on Mac OS 10 you can listen to events like the modifiers changed event which is an example of an event that we're sending out now that you didn't have before so you had to resort to polling and in fact if there is anything that you know of that you have polling for on your application we absolutely want to know that we can try our bed to get an event in there instead I mean making it work that way is for all our benefits and another thing that we want to do is move to something called tracking areas this isn't in there right now unsure exactly what it will be but right now we send your application tons of mouse mood events every time the mouse who is 1 pixel you have an event which is good in some cases but in a lot of cases you don't care all you want to know is did the mouse enter our eggs at this particular region of my window because I need to update the cursor or something well tracking areas are a way to do that and hopefully they'll come online soon so with that I mean there's a lot of stuff here so much stuff that I have a second session did I mention my second session so what you should be seeing from this is that the toolbox is largely doing all the work for your name these days and we want to continue on that path we want to make it such that when you write an application for carbon the only good lines of code that you write are the kinds of the unique to your application that is what it's all about it's also important to know that learning carbon events is important in that everything we do from this point forward will be in terms of carbon events carbon events is our messaging model apartment events is our event model carbon events is our notification model and once you learn that one paradigm you've learned them all and I mentioned you get new tool box features essentially for free and the way that the way that you get that is just because we can start sending out new events and if you're really carbon events savvy you're probably not looking for them because they're liking new and stuff so we can actually send these new events implement new functionality and then when your app is ready you can actually start tapping into that functionality so we won't get into a lot of the problems that we've had in the past trying to implement functionality all our window shade behind your apps back and the best part the absolute best part is that this is a gradual adoption pad there is no need to use to even rewrite one line of code just to make your appt port however if you want to make it perform well you might have to do a couple of things beyond that you can start installing handlers on a case-by-case basis throughout your application we're not telling you to rewrite your app we don't want you to have to completely rewrite your app that's the whole point of carbon so I don't know this stuff is just cooler than cool and if you're not seeing that I don't know what to do can you tell them excited about it the other case what I'd like to do is have you check out carbon events H start looking at it the API is really refined now this is one of the few projects where I've been able to actually get time to really refine the API over and over and over again if you've actually been following carbon events you know that it's changed over time now I think we have a really really highly refined API that actually feels really good as well so please take a look check out all the events we have and let us know what other events you might need I mean sometimes a lot of these are easy we've had requests for example people want to know we want to know when the window is hidden or shown that's easy for us we just add an event and send it out and then you get that notification no need to patch another simple thing you can do is right now on your powerbook just pass max long into sleep to enter your sleep a time on wait next event and start installing timers they're really easy to adopt and of course you want lots of feedback and you can direct your feedback to toolbox at apple com or you can talk to your pal Dave right and I'd like to bring Dave right back up here so you can lead us through the roadmap and I'll take you a thang I think said so can we get all into Ed's head this stuff is cool no let's I mean just give it up it's just amazing stuff so all right so I just want to do a brief overview of the roadmap that kind of follows on to this kind of content right after this session there's the advanced session of carbon events so go ahead and get a drink and come on back tomorrow the high level toolbox team is going to be giving a session on adopting the Aqua interface so those are high-level toolbox changes to AP is that are specifically about aqua and then there'll be two other sessions one on Thursday and one on friday about generic high-level toolbox changes that affect all carbon applications so be sure to go to those sessions to get your apps carbonized as best possible at this time