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