WWDC2004 Session 422
Transcript
Kind: captions
Language: en
[Applause]
are you ready welcome to session for 22
which actually would like to call by the
H I toolbox day of hig day other things
has been evolving inside mac OS tanner
and this week you probably learn a lot
of this evolution first like you
probably heard quick-draw is being
deprecated we talked about being ready
for like a resolution independence so
what does that mean for you as a carbon
and C C++ developer what does it means
for you as an itch I toolbox users well
that means a couple of things and first
that means that your code is going to
have to evolve as well to play great in
the next operating system of Mac OS 10
the next version of Mac OS 10 the good
news is that we have a lot of technology
that we're going to be announcing this
week here in a chai tool book and a lot
of things with HIV which we've been
doing but should really help you and we
have really pack station that you really
like in your help you move forward we're
going to start today with ghee who is
all representative from franza who's
going to be actually talking about
switching to a modern edge right tool
box and going to teach you you really
warka take your pitch have you and how
you as a developer can take advantage of
you how you going to get there and all
the features that you're going to be
able to take advantage of so I think
it's a great first step for you to
understand the foundations of where
we're going here after that please don't
miss the station but we're going to have
at three-thirty with a curved with you
Curt we're actually we know that a lot
of you guard our steel base have
dialogues and windows resources and so
we're going to take a full hour to kind
of like give you a basis and help you
switch your resources based user
interfaces to need five and then we'll
teach you as well how to kind of like
link them together using carbon event
very very cool session I think you'll
like it now getting ready for resolution
independent we're going to teach you
tomorrow we're gonna have a session but
can explain to you how to switch your
custom drawing content and how to switch
you know like in OC or using c def for
instance to use custom HIV this is a
very very very important session if you
have crystal control i really encourage
you to attend that session
so you're probably thinking well but
Mindy I'm gonna have like still to like
you know like Rev some old code that I
have it has been working yes you're
correct you're gonna have to revise the
Makino move some code if you're using
quick draw you can have to switch you
know to call graphic but what's very
very important to understand it but this
is very very good for a core user
because you user interface a new
application is going to gain in
performance and in features and this is
really where we're moving toward the
other thing will be very pleased with
the war between been doing and let's
start with Miss Judy who is going to be
taking you for the next hour with like
the new things we'll be doing with a
chive you mr. G thank you very okay so
good afternoon I hope everybody had a
great lunch get ready for a very packed
session maybe my fast speech will help
me for one's here okay so what I'm going
to cover in essence is the meaning of a
chive you and how that can help your
application and then I'm going to show
you a step-by-step example of how you
can take advantage of a pH I've you in
your application then I'm gonna have a
section on resolution independence it
got mentioned that the graphic sessions
already but i'm going to show you the
carbon story for resolution independence
and how you can start thinking about
that for your application and finally
i'm going to go through a potpourri of
various new features and a chai toolbox
for tiger so we use this word a chive
you a lot davia probably said it 15
times as he was taught in there and a
lot of people wonder what a chive you is
i mean i'm sure you've seen the typedef
and then we say adopt HIV I mean I just
need to grab one view well know what a
chive you means when we say adopt a
chive you because it means get on board
with everything we've been doing for the
last three or four years in the toolbox
a chive you is this conglomeration of
cool new features we've been adding
since since Jaguar essentially so
technically HIV you is our object
oriented view system it's based off the
control manager if you've seen the
control manager and you're familiar with
it and I know most of you are a chive
you is also going to feel very very
familiar it's so familiar and so similar
in fact that it's the same type rent
typedef a control rough is an HIV ref
it's the exact same type they are
literally typedef to one another
the header means you can use HIV reps in
control manager api's and you can use
control reps in HIV you ap is now our
object model is based of course on H I
object we've talked about that in the
past the very cool subclassing mechanism
for carbon clients and we use carbon
events as a messaging model now H I've
you also includes all the new widgets
we've added over the last few years I
like the search field and the toolbar
and things like that HIV also represents
a much more advanced drawing model where
you can take advantage of all the cool
courts features and there's some other
side perks in there H I've you gives you
much better drawing support in the sense
that the api's now makes sense when you
use them and I don't do things you're
not exactly expecting and they don't
force you to take work around now the
reason you want to adopt a chive you is
because what your customers are asking
for can really only be granted by HIV
HIV you can give you all those buzzwords
like the library sizing quartz
transparency various forms of animation
going to HIV you is also the only way to
adopt certain new toolbox features we've
added over the past couple years the
toolbar is one our text view and scroll
view which is our full featured text
editing view and carbon is another we've
got an image view we have HIV layout
mechanisms which are like Springs and
rods on steroids and all that only works
under a chive you now another reason you
should use a chai view is it just going
to make your apps faster right we did a
lot of things much more efficiently we
learn from our mistakes in the control
manager and just made it better and the
best thing about a chive you is it
actually makes your jobs a lot easier
the code you end up writing to do
something custom in your app is a lot
simpler when you use HIV to implement it
than if you have to hand roll it
yourself the old way so some of you may
be looking at your applications these
days and feeling like look it looks a
little bit like this house you know I've
kind of got a crummy lon the paint's
chipping here and there the windows are
kind of ugly the roofs maybe got a
couple weeks well one reason you might
want to adopt a chive you is because it
can allow your house to look like this
put a little work into it you know give
it some new paint clean up the lawn you
know clean up the yard and suddenly it
looks a lot better but then there's
another side perk that house is exactly
the same as it wasn't the other picture
we've added some things right there's a
new fence there there's new windows in
fact one of the windows was expanded a
little bit so H I view is going to not
just let you polish up your applique
but it's going to let you expand it and
grow it so there's five basic steps to
adopting HIV or adopting all the
technologies in HIV so let's jump right
into the first one that's using the
standard windows and controls this is
something we say every year and we need
to repeat it because it bears repeating
right there's a lot of good reasons to
do it and we know some of you still need
a little bit of a push to keep adopting
the standard windows and controls so
we've added a lot of new views over the
last few years they can do basic things
that your apps used to have to do for
themselves if you want to list view that
interacts a lot like finders lists you
go ahead and use the data browser fact
finder uses a data browser to do with
lyss you like I mentioned before we have
a text view and a scroll view of it
together can be a full-featured text
editing engine for carbon applications
but you don't have to use the scroll
view just with the text view you can use
it to scroll image views or any other
custom view you might want to make so
take a look at the controls we offer and
take a look your application and find
out what you were doing custom and see
if now there's there's some parity
between what we offer and what you do
and see if you can replace your custom
implementations with our new features
also be sure to take advantage of you
embedding or control embedding this is
something that we've had a long time Mac
OS 80 but we know a lot of people like
to use controls in a very flat hierarchy
right they have a window and they have a
bunch of controls in it and then they
try to manage the overlapping controls
themselves and try to manage the
containment themselves well a chive you
can do all of that for you so you might
as well use the built-in infrastructure
that's also going to give you a lot of
Bennett's benefits with respect to
accessibility an app that's been revs to
use a chai view is going to be mostly
accessible in addition going to a chive
you insulates you from future interface
changes that we might make the best
example of this is probably the tab on
Jaguar that have looked a lot different
than they started to on Panther and
continue to look on tiger but there were
a lot of applications that rolled their
own tab ensure they use the appearance
primitives to try to get the standard
look but because of how the appearance
needed to change in Panther those same
primitives could not draw the new look
so people that did their custom tabs on
Jaguar and got a good Jaguar look
unfortunately carry that Jaguar look
into the future into Panther and tiger
another great reason to use our standard
tabs if you use the standard tabs it's
going to get the new looks as we as we
rep the user interface that's really the
first step it's pretty straightforward
right but it's going to give you a lot
of good wins and most of you already
know how to do that and are already at
least partway through doing that in your
application so that one should be pretty
easy the next step which is probably the
most time-consuming step let's say is
taking your custom user interface in
your application and wrapping that
inside individual HIV objects the first
step as part of that process is to look
your interface and factor your custom
areas into individual subcomponents
right its standard engineering design
methodology you want to make a view
around the simplest smallest thing
possible in most cases if you do that
it's going to be a lot easier to write a
chive use around those individual small
widgets and you'll be able to reuse them
in various places as well which is cool
then using our H objects subclassing
mechanism you create a subclass of a
chive you to represent your custom
object then when your custom object is
put in the view hierarchy it will
receive carbon events to handle things
like mouse clicks keyboard events all
sorts of other users interact
interaction accessibility activation of
the activations all that stuff so you
just handle those carbon events do the
right thing we have lots of header doc
and carbon events th for all of the
control and view related events you can
look in there it tells you what you need
to do what events you want to handle for
certain situations and it's really
straightforward then if your view needs
to communicate state changes to other
parts of your application like what's
they have one a button is clicked right
you need you need to carry out some
action someplace else in your app you
can use H I commands to do that we have
convenient api's to send out a chai
command in fact the view system already
has built-in support for a chai commands
you can associate a command with a given
view it'll automatically get sent out
when the view is clicked but if you have
more complex communication needs you can
use custom carbon event carbon events to
communicate between different pieces of
your app one good example of this is our
scroll view the scroll view is based on
our scrollview carbon event protocol
which is just a set of simple carbon
events that it can use to communicate
with
scrollable canvas if you have similar
needs in your application there's no
reason you can't use carbon events to
implement them they're really flexible
really full featured you can put all
sorts of attributes in them you can cue
them you can direct dispatch them and
it's really powerful then it bears
repeating keep using view embedding you
know you might get partway through this
step and say okay while I wrap my custom
content in some views but I'm still
going to use a flat hierarchy well I
really recommend not doing that I really
recommend using a full embedding
hierarchy because it's going to make
subsequent steps a lot easier finally we
have a bit of sample code called a chai
framework it's on the developer website
we have a bunch of sample applications
based on HRM work and this is the c++
class library that manages the kind of
boring details of a chai objects
subclassing in the HIV mechanism you can
just derive a subclass from our RT view
class and it'll automatically set up the
HOF sub sub class the event dispatcher
and all that then you just override
whatever virtual method you need to and
do whatever work you need to in those
now we're going to be covering some of
these steps in more detail because I
just don't have time to talk about them
today so we're going to cover them in
two other sessions as examined session
for 21 immediately follows this and it
talks about taking an old style dialog
or some old window code and replacing it
with a nib file and it's part of that
adopting a chive you in the process
where you can and then tomorrow we have
a session entirely on writing an HIV
from the ground up to represent some
custom area in your application so I
strongly urge you to attend these
sessions to get more details on this
step so that's two of the five steps the
next is adopting the standard window
handler this is probably the most fun
step mainly because it gives you kind of
this cool bang for the buck it gives you
this cool win now the standard window
handler has been around for several
releases and essentially what this is is
it's a carbon event handler that can
automatically be put on your windows to
do all the normal event dispatching that
you use to have to do manually when you
called wait next event so you no longer
have to call wait next event see if it's
a mouse event call fine window see if
it's in your window that you're
interested in if so call find control
rather to the control if it's not a
control yeah you know that whole
rigmarole you don't have to do any of
if you turn on the standard window
handler so the standard window handler
is designed to work directly with a
chive you and what I mean by that is the
standard window handler only knows how
to deal with views it can route mouse
advanced keyboard events all that
stuff's of use but if you have
completely custom stuff in your window
and it's not represented by an HIV you
have to jump through hoops to make that
work you have to install a bunch of
carbon event handlers on your window and
deal with all that rigmarole so the
right thing really to do here is if
you're going to use the standard window
handler use HIV they work together
really really well the standard window
handler is also the most important key
to using the toolbar the toolbar
essentially put a system driven piece of
code or a system different piece of
interface in your window and the only
way that can receive events is if you
jump through some hoops to find the
right events to send to it or if you
just use a standard window handler might
as well use the standard window handler
so to get the standard window handler
for your window you need to do a few
things in interface builder which is our
preferred way of creating your windows
there's a checkbox in the window and
spectryx palette so standard handler
just check it standard handler will
automatically be turned on for your
windows but if you need to
programmatically instantiate your
windows there's an attribute the case
window standard handler attribute that
you can specify at creation time once
you've turned that on for a window the
standard handler will automatically be
in effect since your application runs it
will start servicing events which means
you can go back into your weight next
event loop and rip out all the code that
had to deal with routing events to that
one window you can just get rid of it
it's generally not necessary but the
standard handler can't do some sort of
functional things on the window that
you're going to need to respond to for
example when they closed box is clicked
a window gets sent the cave k event
window closed carbon event and by
default the window will tear down but if
you need to save changes to do something
else you want to hook into that carbon
event to handle handle it completely
there's a bunch of other carbon events
like this you can think of them as hooks
they're not strictly necessary but
they're good ways for you to hook into
the systems processing and provide
custom behavior where you need to carbon
events that H again has lots of
documentation in that
better so I urge you to take a look at
it see what sorts of other hook events
are in there and take advantage of
whatever makes sense for your
application let's step three step four
is probably the coolest because it's the
flashiest that's switching on
compositing mode and starting to draw
with quartz now this is cool because it
gives you radically better performance
and it just makes your life a heck of a
lot easier one of the ways we sped up
the HIV subsystem through compositing
mode is that we no longer draw a pixel
twice unless we absolutely have to and
what I mean by that is when a view draws
we know whether or not it's apple cake
and we know what part of it needs to be
redrawn and so we make sure to just
redraw the parts of the views that
intersect that dirty area in addition
now that we are not redrawing right when
you call various api's like that site
control value well step back for a
second so in the old control manager
every time you called an API likes that
control value the control redrew so if
you did a typical setup of a scroll bar
where you call second roll value minimum
maximum the maybe V sighs that's for
redraws of the scroll bar right there
that's a big waste of performance h I've
you eliminates that now instead of
redrawing in those AP is we mark the
appropriate areas of the scroll bar is
dirty and needing redraw later so some
time later right before you get back
into the event loop that view will
automatically be redrawn the other cool
thing compositing mode does it
eliminates the need to erase if you've
ever written a custom see def you knew
is your responsibility to call setup
control background and a race before
your control actually drew which meant
that you if you had a complex view
hierarchy of controls there was a lot of
erasing and redundant drawing of the
window background going on that's just
crummy so we eliminate that in HIV which
speeds up the drawing pipeline now of
course compositing mode means you can
use quartz really really easily which
gives you access to all the cool quartz
features and additionally the
compositing draw model is far easier to
write than the old draw model in the old
draw model every time your control
received certain messages it was your
responsibility to execute your own draw
code sometimes clip differently or who
knows how well in the compositing mode
you only draw at a very well defined
time and the K event controls our event
so suddenly your code is way simpler you
just handle the draw event and in your
other events you just handle your mouth
tracking or whatever else you need to
and you don't need to worry about weird
cross-pollination of functionality so
let me give you a quick demo of some of
the cool things compositing mode can be
for you
okay so if you hammer home a point a lot
of people made requests over time for
the ability to draw controls on top of
an arbitrary picture and this is how it
would look if you tried to do that in
non compositing mode the controls try to
erase behind themselves so they blow
away whatever picture was there ensure
there were workarounds right you could
hook into the quick-draw bottlenecks on
your port and try to patch things up but
those even broke as our views in the
toolbox started switching over to court
so this is what you ended up with which
is pretty crummy instead with
compositing mode you get something like
this obviously a lot nicer now you can
see the controls were animating and some
of them the disable button up at the top
left if you can just barely tell that
you can see the picture through it
because that button itself is partially
transparent in addition the cloud and
the Sun is somewhat transparent and as I
resize you might actually be able to see
the background moving underneath them
and stuff so one thing that David did
when he wrote this app is he just put a
little bit of animation in there right
so clearly not smoking mirrors this
stuff is clearly all live it's very fast
it's very easy to use it works really
intuitively one other thing I want to
show off with this application if you
make this really small all those views
are overlapping but they're all still
properly Z ordered and they all still
draw in the property order so you can
see in the various things going over top
of stop button and you know I can still
click on things when this is going on in
tracking still works you know I can
track on hit tennis I'm getting blocked
by other views the orders on top of this
one from hit effing there we go so now
I'm actually tracking in the other
button and that all just it works it's
very cool so not many other view systems
on this platform or otherwise can do
anything like this
so here's here's a fun little app this
is not something I'd necessarily
recommend you do but it might give you
some idea of the power of HIV you and
compositing mode so like I said before
have you every view draws in a very
well-defined place the K event
controlled draw Handler and that handler
is passed a core graphics context
reference to do its drawing with and the
view must do its drawing with that
context this means that anybody can come
along to your view intercept handling of
the K event control draw handler and
manipulate the context a little bit if
it wants to for cool reasons so what
Eric did is he / she / rode the draw
handlers on a couple of these controls
and transformed the context to scale up
and down the various widgets here now
granted there's some artwork problems
this is why I don't exactly recommend
that you do this technique but you can
see from the scroll bar and the checkbox
that you actually get kind of reasonable
results so this is kind of cool things
you can do with compositing though don't
you leave that open and fire up
transparent windows okay so ignore care
wants to show you just how cool it is
transparent windows on carbon this is
something we get requests for a lot how
do i do a splash screen with
transparency or something like that this
is an example of how you might achieve
that this is an overlay window that
inside of it has a couple views embedded
it has a view that's drawing that image
of the character from aqua teen hunger
force and there's also a push button in
that window and also this slider and
they're all together in the same window
I can move it around it's got a shadow
and everything and I did this just by
creating a custom HIV class to render
that image and then put a couple other
controls in that window as well but that
doesn't exactly meet the goal people
want to transparent window so what I did
is I wired up this alpha slider to talk
to the other view and change its alpha
value so I can do stuff like this and
it's all live it all keeps working it's
really easy to write and it's really
fast and it's all still a window in this
button I put the standard minimize
command so when I click it window goes
away just like you'd normally expect so
the stuff is really powerful and really
really easy to use it only took me about
an hour to write
okay so i can go back to slides please
okay so to turn this on there's a few
things you need to do and I want to
cover this from two different
perspectives one is from an app's
perspective as in there going to be a
client of the HIV you ap is the other is
as a views perspective and I'll cover
the views perspective later so from an
apps perspective what you need to do is
go into interface builder with your
window and turn on the compositing mode
checkbox for that window if you create
it programmatically of course we have
the K window compositing attribute that
you can set once you've done that all
drawing in that window must be done with
a chive use we will no longer send
update events to you you will not get
update events for that window out out of
weight next event so any drawing that
you're expecting to do to wait next
event isn't going to happen got to put
everything inside a chive use the other
major change you need to worry about is
the notion of frame coordinates so if
you think back to the control manager
when you want to position a button at
the bottom right hand corner of your
window and the control manager you
figured out the coordinate the top-left
coordinate for that button as it were
port relative if you find out the quick
trial court for the window you find out
the appropriate offset from the top left
at that court and use that as a button
top left it changes a little bit in HIV
mode and compositing mode now you
specify the buttons top left relative to
its parent view so it's just a little
change something we had to worry about
when we rev navigation services and
panther to start using compositing mode
but it's also something pretty easy to
to get through your head you just do it
a couple times suddenly it becomes
intuitive another change you need to
make is pretty much elimination of code
in compositing mode don't call api's
that draw right away don't call draw one
control to draw control in current port
they just don't make sense compositing
mode is all about invalidation deferring
drawing until later anytime you call
draw one control you're defeating the
purpose of a chive you and you're
slowing your application down auto-embed
control is another API you want to avoid
but that's mainly because it doesn't
make sense really in compositing mode it
uses a different notion of coordinates
and it tries to figure out heuristic
alee what the right what the proper
parent he would be it was really there
for dialogue manager compatibility so
just avoid it instead using API like HIV
you add sub you and figure out the
parent you'll usually know what the
parent is anyway just associate the
child with the parent so there's also a
few steps from a views perspective and I
want to cover
them individually so the first thing you
can do is test to see whether
compositing mode is on for that window
you don't have to do this right some
people write H I've use just to work in
compositing mode in fact that's what I
did in that last demo app I knew I was
only going to use in compositing mode so
it was really easy to write I didn't
bother testing but if you're going to
rev to compositing mode over time in one
window and then another and another over
a couple of your applications releases
you may find it useful to package your
custom content up in views that can work
in either compositing mode or non
compositing mode so if you want you can
take a look at the view zoning window
see whether the compositing mode
attribute is on and if so you can behave
one way in compositing mode in another
way in non compositing mode the next
step is to make sure you invalidate
appropriately right don't draw all those
state changes like I was talking about
we send out a handful of carbon events
when appropriate state changes occur in
various views right we tell you when of
you activate your deactivates when the
highlight part changes when it enables
or disables or when its value changes
and we also send out carbon events
anytime a views bounds change so that
you can make intelligent decisions about
invalidating exactly the portions that
need to update this is really useful for
a list like data browser when data
browser resizes it knows all the stuff
in the upper left-hand corner of itself
doesn't need to get redrawn a little
just invalidate sort of the l-shaped a
region that gets revealed and maybe a
few other bits here and there and just
those areas get repainted so when you
get one of these notification api's you
just inform the HIV subsystem what parts
of your view or dirty if the whole thing
is dirty you can just call HIV you set
needs display pass the view past troop
marks the whole thing is needing
repainting and the whole thing will get
repainted later but if you know just
some sub part needs to get redrawn you
can use an API like HIV so that needs to
play in rectangle and there's a couple
other variants of that API so you've got
more fine-grained control the next step
is to switch your view over to draw with
quartz pretty much have to draw with
quartz and compositing mode no it's not
literally true but that's really the
recommended solution and it's the only
way you're going to be able to get the
free resolution well I can't say free
the low-cost resolution independent
support which I'll talk about later but
the key here is that you only draw in a
cave
control jaw handler like I mentioned
before and that event comes with the
core graphics context rep that you're
supposed to draw with don't try to
manufacture one for the windows port it
won't be clipped right it won't
necessarily be transformed right just
use the one in the event it's there for
a reason draw with it once you've done
that you can start leveraging whatever
courts features you want you know start
taking advantage of setting the
transparency on the context use bezzie
as he's whatever you want but the key to
remember is never a race only draw you
can count on the fact that the HIV you
subsystem has painted the views behind
you already that's already taken care of
and if you want to make a view that is
aqua compliance and aqua savvy we have a
bunch of H I seem drawing primitives
which are designed to be used with core
graphics or with the core graphics
context you can take a look in a chai
toolbox / h ith for a bunch of different
ways to draw the standard button looks
with standard tabs those tabs lips and
things like that so that's step for the
next step maybe the most gratifying step
because it lets you toss out all kinds
of code from your application that's
switching to run application event loop
so over the course of time you put the
standard window handler on your various
windows you switch them over to
compositing mode and you finally just
finish the last window so now you look
at your weight next event loop and you
say well this isn't doing a whole heck
of a lot I'm tracking the menus here and
I'm calling it you process applet and
that's about it well one application of
that Luke can do that for you and allow
for more future growth as well so take
your weight next event loop toss it away
put run application event loop in its
place now one thing the weight next
event also did that a lot of you rely on
is give you periodic idle time the
problem with doing that through wait
next event is you had to sort of
centralize your notion of idle time and
your objects had to communicate with
wait next to meant you had to find the
smallest time slice that was needed by
any given object they wanted to animate
it was just big mess so instead we
recommend using carbon event timers
carbon event timers are an easy way to
get either periodic processing or like
one shot deferred processing off in the
future and it allows you to encapsulate
all of your codes with an animating view
right there in that view that view
doesn't need to know its operating under
weight next to man to run application
event loop or whatever similarly wait
next event also allows you to detect
mouse movement based on a region
well again have the same kinds of
problems your views that wanted to
communicate with wait next event had to
no wait next event was there you had to
figure out the minimal region and it was
just a big mess so instead a couple
releases ago maybe last release we gave
you tracking areas mouth tracking areas
and these tracking areas are designed to
manage a window relative Mouse region
and you get informed of enters and exits
into that region so it's a very handy
way of doing something like roll over or
cursor changes so once you switched over
to run application event loop the thing
you need to realize is that run
application event loop will not return
until it's quick and the way you quit it
is with quit application event loop so
you put that in appropriate place in
your application probably like your quit
apple event handler or something and if
you have various places in your app
where you call modal dialog or you call
wait next event in the fashion where
you're trying to simulate modality the
way you would do that now is with run
app moda loop for window you can pass
that api a window it will make the
window automatically modal and it quits
similarly to run an application event
levitas call quit eps modal loop for
window that's all five steps once you
take advantage of that you should be
able to transfer your application so it
looks something like this really make it
modern really make it great start taking
advantage of other new toolbox features
and be prepared for the future future
might be something like resolution
independence hey speak of that so
resolution independent is kind of a big
big subject so let me see if I can
explain better with a demo it's very
visual so I should do the trick
so maybe I should give a little bit of
background about resolution independent
first so that we don't really have high
DPI hardware yet we know that the
industry is moving that way over the
next couple years and we'd much rather
have applications that are going to be
ready for that hardware when it becomes
available so we don't want you waiting
to start thinking about resolution
independence until after the hardware
shows up we all know the hardware is
eventually going to show up so let's
start thinking about these topics now
start considering how you can adopt a
resolution independence in your
application all right so I've got the
back called resolution modes right now
it looks pretty normal right these are
three windows the the windows are
basically identical except for one
slight change i made to each of them in
interface builder that's how they look
now but if you launch quartz the bug and
you go up to the Tools menu there's a
new item called show user interface
resolution give you a little slider with
a multiplier on it if you change the
value on this slider it multiplies the
resolution that apps will run in so if I
move it up to 1.25 relaunch my
resolution resolution modes application
you can see that the windows got a
little bit bigger but you don't have to
stop at 1.25 I'm actually going to go
really high here so you can see it a
little bit better ok so this window
which is titled magnified see if I can
get these other windows out of the way
this magnified window has not been
modified at all in fact this
applications event basic core event
processing processing has not been
modified at all and this is the result
sure you get a bigger window but it
looks a little grainy right I don't know
if you can see it on the big screen but
the magnified text is a little blurry it
certainly looks like it's been blown up
well that's because it has been blown up
magnified mode is what you will get by
default for any non savvy window in your
application how we do this is we tell
the windows server look this is the
window that doesn't know it's in
resolution independence or that it's
under a scale factor so please blow it
up for me right your windows backing
store is still very small so when we
blow it up bigger
it kind of grainy now there are two
resolution independent savvy modes you
can set on a window first one I want to
talk about is framework scaled mode now
obviously this window looks a lot better
you can see the text in the text area is
a lot crisper the picture still looks
kind of crummy let the where are we can
I not switch oh we have bad things
happening oh we have really bad things
happening alright um oh cool all right I
gotta reboot the machine from back here
and I can't get to the front all right
well strictly speaking the demos are not
necessary so I'll just I'll just cover
more detail here I guess so magnified
mode 925 mode is the fall back case this
isn't really what you want to have your
application look like but it'll work in
a pinch it'll allow users to get
something reasonable with your
application even if your application has
not read for resolution independence
like I showed it looks kind of crummy
particularly compared to the other mode
but it doesn't take any effort on your
part now unfortunately I didn't actually
get to show this but David's going to
try to troubleshoot it so maybe I can
the next mode is application scaled mode
this mode is not the second one do I
show it is that little small one that
came up application scale mode is a mode
where you do all the work now well you
do most of the work the benefit of
application scale mode is that you can
actually use quick draw in that mode
unlike the third mode so when you
specify you want your window to work an
application scale mode you're
responsible for making all parts of that
window bigger except subcomponents of
things driven by the toolbox so if we
can get this back up i can show you what
i mean the application scaled mode
window was still at the same size as it
was when the scale factor was 10 but the
title bar was a little bit bigger well
the title bar was bigger because it's
handled by the system and we know to
apply the appropriate multiplier to it
and another thing you could have seen
there is that the text was a little bit
bigger right we know the system font
when somebody requests the system font
isn't just 13 pixels tall anymore there
times some multiplier tall so we made it
bigger but the problem was all the views
inside that window that the application
foot there were still the same size and
that's because that app had modified yet
an application that uses application
scale mode on its windows is responsible
for sizing the window content area
bigger as well and then you resize all
the views inside of it this is the price
you have to pay for using quick draw now
we really would prefer you to not use
quick draw if you can just switch over
to a chive you switch over to drawing
with courts you can take advantage of
framework scale mode the cool thing
about frameworks killed mode is you get
a really good appearance and its really
really easy to do this is the second
window that showed up there that I was
comparing the magnified window to that
was an application scale mode the only
change i made to that window relative to
the magnified mode as i went into
interface builder and change the value
in a pop-up menu to say please framework
scale this and you get all the rest for
free events still get routed right so
speaking of event routing this is
something I need to show off their that
was one application had three windows
and each of those windows was in a
different mode now we don't necessarily
know how that applications getting event
might be in a weight next event loop
might be in run application event loop
who knows maybe savvy it may not so what
we have to do is since by default we
magnify windows we need to make sure
that all global coordinates that come
through api's that get passed into api's
and come out of structures like an event
record all map to the coordinate space
that a magnified window uses so
essentially what we do is we magnify all
the coordinates that come out of those
sorts of AP is now this is still a
little bit of work in progress here and
I've got another slide that talks about
this but what we're going to try to do
is make it so that ap is that talk
specifically about a window that we know
is either an application scaled mode or
framework scale mode can be used with
coordinates that are not magnified so
we're going to do as best we can there
so really my point here is that these
coordinates may be coming back in a way
that at first films feels a little
counterintuitive to you but it'll make
sense eventually and we have a bunch of
api's that can help you convert points
from the sort of magnified sense of
global to the true pixel sense of global
okay so to turn on resolution
independence for your application start
with a window go in interface builder
there's now a little pop-up menu there
that says a scale mode I think it's got
three choices magnified app scales and
framework scale if you can't use the
Saab pop-up menu and you need to create
your windows programmatically we've got
creation attributes for those of course
once you do that your application may or
may not want to take advantage of that
knowledge inside inside your code
obviously if you're an application scale
mode you have to take advantage of that
knowledge because you're required to do
a bunch of work so you can determine a
windows scale mode at run time by
calling a chai window get scale mode
passes back whether or not the windows
running a nap scale mode or frameworks
failed mode or magnified mode and
additionally it hands back the scale
factor in case you need to do
multiplication to figure out of
appropriate size for a view but if you
want the user scale factor without a
window we also have a convenience API
for that and like I mentioned before we
have a whole bunch of coordinate
conversion api's and hid geometry H
which were originally intended for use
with resolution independence but they
actually end up being really cool
because they allow you to do things like
translate between a view and window
coordinates or a view of use coordinates
in one window with abuse coordinates in
another window which you know in rare
circumstances might prove useful but I
found a couple cool things to do with
those oh the other cool thing about
these conversion api's is up until now
the toolbox didn't have a great way like
a one-stop shopping way to take a global
coordinate and convert it to a window
coordinate most of the time I think we
recommended people convert that point to
the windows port coordinates and then
you can call QT global local to global
and stuff like that it's a little bit
nasty so now we just the set of api's
can also achieve that for you so I did
is it is a good bad bad okay all right
so first thing to realize and the demo
would have shown this as well is
resolution independence for Tiger is a
work in progress it's intended as a
developer only feature you should not
ship your applications with this stuff
turned on things could even change right
we're not done developing an engineering
internally so we could have 50 new
paradigms here in there we just don't
know yet the least ready mode is
application skilled mode right I did
magnified mode first and that was really
easy to do and then we did a framework
scale mode and that was pretty easy to
do application scale mode is taking a
lot more change throughout the toolbox
so we'll get there but it's not quite
ready for prime time on the tiger seat
but still I encourage you to try it out
you'll see very obvious visual artifacts
just blame the toolbox keep moving
forward see if you can kiss and continue
exercising the api's and developing on
it but probably the coolest thing here
is unlike previous WWE seas where we've
given you this little window of time
saying please give us your feedback like
in the next two days so we can implement
it this because it's not going to be a
user feature for tiger we actually have
a little bit window a little bit bigger
window of opportunity to hear your
feedback and this is really important
because there's a huge variety of
applications out there particularly the
ones that are going to need to use
application scale mode and I need to
hear from you what sort of things we
could do with convenience api's what
extra support you could need you know
maybe you need a few new api's to help
with you know blowing up you're blowing
up a window after you instantiate it
from a nib or something like that so
please try this stuff out start making a
little brainstorm list of things we
might be able to do for you right bugs
contact us on the mailing list I want to
hear your feedback we also have a
document referenced by rhi toolbox
release notes on your developer seed
which is carbon resolution independence
notes it takes advantage of some
knowledge that's also in a sort of
overarching resolution independence
document that's also in the release
notes so i encourage you to read both of
those it's going to go into more detail
in fact it'll cover some of the stuff I
would have been able to cover in the
demo so please check that out all right
so the rest of our time we've been doing
things that you've asked us for we pay
attention to mailing list obviously we
have Eric the Android on carbon
development list responding to messages
as soon as we can and we hear what you
asked for
and and we've done a few of those things
for tiger the first thing which i think
is the coolest is we actually now have
text notifications that you can get one
stop shopping knowledge whenever a text
in it and one of our unicode fields
changes so the matter if it was pasted
in doesn't matter if it was typed in
doesn't matter if there's in line input
who cares you just get this notification
similarly there's the textured change in
range event that's sent out so you can
have one stop filtering you can filter
the text you can change it and block it
whatever you want doesn't matter how the
text was put in there you can do it and
we send this to all of our Unicode based
edit fields right doesn't work with the
old text edit or edit text control that
everything more modern than that the
search field the combo box the H I text
view the Unicode edit field works with
all of those but there's a catch that's
not really a big catch it's probably a
little too scary to say on the feed it
doesn't quite work right for a few edge
cases so while I encourage you to try
this out please you know start switching
their applications over to it take a
look at the release notes see those
couple edge cases where we know there's
a problem and you know it'll save you
time for having to write the bug and
will say oh no we already fix this we
already know about it so just take a
look and see what those edge cases are
but doesn't that I encourage you to
adopt this as soon as possible now we
also expanded the set of HIV you ap is
our first set wasn't really complete I
mean it was functionally complete
because you could always rely on the
control manager equivalents but what we
did is we put together a whole nother
set of HIV API to sort of fill in all
those missing holes well all but one
percent of those holes but still we've
got api's like HIV setvalue HIV count
subviews so your code is a lot more
readable and in addition we took the
chance to modernize a few of the API so
that you know there were some clunky
mechanisms in the control manager side
we smooth those over and the HIV
equivalents the coolest part about this
though is that we had a big request to
give back latent state information about
our views I'm sure some of you have
switched on compositing mode and you
have an invisible window and you have a
view that you've just called HIV
setvisible true you know what's visible
it's definitely logically visible but if
you called a chai view is visible you
get back false well that's because the
compositing subsystem tells you of use
physical visibility not as logical
visibility so now we return the late
States we have a new API to deal with
the late invisibility we had to do a new
API for that one because we already had
HIV was visible which obviously just
returns the physical visibility but we
added two new HIV was active nhi view is
enabled api's which tell you the
physical enabled and active state as
well as the layton states so it should
make dealing with some of your education
is a lot better we also had a request
for more fine-grained control over
exactly which windows in your
application were supported by expose so
we have the H I window get and set
availability api's that allow you to
control whether or not a window gets are
handled by actually now I know I
mentioned tracking areas already and I'm
sure some of you were thinking yeah
right tracking here is there a big pay
and I try to use them with my H I've use
but H I've use apparent relative and
when they move i don't really know it
and then i got to try to figure it out
which means i have to install an event
handlers anyway we know we know we've
had to do with ourselves it really sucks
so what we did is we made HIV based
tracking areas exact same concept very
similar usage model except the tracking
areas are bound to a view now we know
when a view moves in a window relative
space so we can automatically adjust the
tracking area for you automatically
automatically do it automatically anyway
so we send carbon events directly to the
view whenever the mouse moves in or out
of that view so they're really easy to
use suggest you adopt these wherever you
can they're a great way of doing
rollover or mouse tracking other people
that started adopting compositing said
compositing is great until I try to
scroll view greater than quick draw
coordinate space that doesn't make any
sense it's supposed to be court space
yeah yeah I know the internals of the
control manager used to be based on
quick-draw coordinates even though we
supported this cool compositing mode and
unfortunately you know that was that was
prevalent throughout various events we
sent events to view saying tell me your
structure region well that's a quick
draw region which are regions are
inherently limited to 16 bit integer
coordinates wasn't so good so what we
did is we came up with a chai shape a
chai shape now has full integration into
the HIV subsystem you can now
communicate region type concepts in a
way that breaks the 16-bit
withdraw limit coordinates H I shape
also allows us to improve performance
throughout the HIV subsystem we don't
need to do as many translations back and
forth from quick-draw coordinates
anymore so it's a boom there we also
added a few new accessibility API s for
those of you who got a chance to see the
accessibility sessions and the boys over
sessions these should help out a lot we
have a very easy way to add extra
attributes to an existing elements like
let's say a push button you want to give
it a description you can use the set
auxiliary accessibility attribute API to
do that really easily in addition those
of you who are implementing
accessibility for your own objects but
you need to use the standard roles and
you want the standard role descriptions
we have a way that you can query the
standard role description of the system
uses we also have a way that you can
easily override the accessibility
hierarchy provided by an object this is
kind of an educator that most of you
won't need to use it but if you do run
into one of those situations we have an
API that can help out and finally one
thing we realized when we were working
with finder to provide accessibility
information for their list view is that
you know data browser is really great
but and data browsers accessibility
implementation is really good too but we
need to interject some extra info in
there right what is just a row in one
application might need to be called
something else in my application so I
want to be able to customize what data
browser provides so we have a set of API
is that allow you to modify the
information sent out or pass into data
browser for any given element pretty
cool take a look at control definition
CH for that and in fact let's see that
was this morning right so if you want
more details on this see if you can
travel back in time a few hours and
check out session for 24 we covered a
lot of accessibility information there
one thing we did to the toolbar to kind
of expand the possibilities for what you
can do is allow for per window enabling
and disabling of toolbar items as well
as selection of toolbar items so what I
mean is you can have two windows that
use the same toolbar object you know
they both binder the same toolbar but
you want let's say you want the delete
button in the toolbar to be enabled in
one window but not in the other well up
to now there wasn't really a way to do
that
what you ended up having to do is create
two different toolbar instances for each
one for each window and that was kind of
a pain so we built in per window
selection enabling and disabling support
now the cool thing is that the toolbar
can manage the selection for you
automatically all you need to do is have
your toolbar delegate respond with
carbon event that says hey tell me the
selected selectable items if you respond
to that the toolbar can manage it for
you automatically it'll just track the
selection change the selection send out
a carbon event when that selection
changes happen but you can listen to if
you need to there's lots of other stuff
that I just don't have time to cover
today though with my my demos crashed I
could probably talk about stuff let's
see see what I can do here H I object
archiving I don't think this is actually
turned on is that true yeah
unfortunately there is a runtime problem
we couldn't actually turn this on but
essentially what H I object archiving is
the way to take nehi object which means
a window or our control and say hey
flatten yourself out to a stream i want
to write you someplace and it grabs all
the information from those views and you
can hook into this this is achieved
through new carbon events they get sent
to views and windows or nehi object
really and you can hook in and provide
your own data into this flattened stream
so you can store it out wherever you
need to we also expanded the hotkey
api's let's see some cool stuff for the
combo box ah yeah the combo box we asked
we were asked by you guys for better
control over when the list is shown in
hidden unit want to programmatically
invoke it and not just have a user click
on it so we gave you that there's an
easy way to make the list show up the
search field we were seeing places in
the interface where people wanted a
search field with an icon on both sides
of the search field but they didn't want
that left icon to actually bring down a
menu they just wanted it to act like a
button so you can do that now in a
search field we added a bunch of new
menu glist to the menu manager so you
can support those if you want to Eric
did a ton of work in carbon to kind of
give us a lot better integration between
carbon and Coco windows if you've ever
tried to integrate them yourself or use
system services that did the integration
for you like a like the color panel or
something like that you notice that some
time there were some activation problems
and it wasn't clear which text field
focus well we did a bunch of work in
that realm to clean it up and we did it
by using proper window levels so there
are some things we changed with respect
to window levels we I think we always
used to use window level 0 and now we
actually use the proper window level so
we can interact with the coco windows
better we cover this in the H I toolbox
release notes in detail urging take a
look at it just in case there's any
compatibility concerns there but see if
there's any of this new functionality
you can take advantage of with the new
API as we offered we also sent out a
couple new carbon events as sheets open
and close i believe severide sheets open
and close I'm looking for Eric Idle Sam
okay oh don't worry so like I said a
chai toolbox release notes are the key
it goes into more detail about
everything I've talked about already
already as well as the stuff on this
slides and even more but there's three
other things I want to talk about these
are sort of compatibility concern these
are changes we made a tiger that may
affect your ways and through our
application in ways that you don't
exactly anticipate right now the first
change was to support resolution
independent I don't know he can remember
but the machine before it crashed had a
bigger menu bar when I increase the
scale factor well that was achieved by
switching the menu manager over to using
a compositing window for the menu bar
now since it's a regular old compositing
window this window is going to show up
in the window list so if you're calling
a P eyes like get window lists or get
front window of class the all classes
constant you're going to get the menu
bar window so you've got to be prepared
to expect that but better yet don't use
either of those API so you don't prefer
those anyway what you really want to use
is active non floating window that
generally gives you the frontmost
document window which is what you want
nine times out of ten anyway another
change we made is we brought the user
pain control sort of up into the HIV
space so at least it can be used as a
grouping view but that required a few
changes one of the changes we have to
make is we no longer store it's private
as I say private private that stuff
internal to Apple instance data in the
controls data handle we found a few
applications out there that access that
data or at least query it and we had to
do some weird workaround to make those
applications continue to work so don't
ever access the private data
some control in fact don't ever access
the private data of any control you're
not in charge of writing it's a bad idea
and don't even direct it now the third
change which is something we haven't
made yet but it's something we're going
to do by the time Tiger ships there are
some api's like event avail still down
and wait math wait mouse up that
currently flush window buffers meaning
you could do some drawing in a window
and then you could call event avail and
that drawing will be flushed to the
screen right away that's kind of
convenient but it killed performance in
many ways a lot of people use event
avail are still down it's part of a very
tight track mouth tracking loop and so
any painting that happens is either a
visual inconvenience because they didn't
want it to happen or it just slowed down
that tracking live which is kind of
crummy so by the time Tiger ships we're
going to make changes to those three AP
is such that they no longer
automatically flush window buffers with
the big parentheses which is only for
applications linked on tiger and later
right so if you built your application
on Panther and you run it on tiger those
three api's are still going to flush the
way they always have only if you link on
tiger and then run on tiger will those
api's change behavior so if you find
some situations where suddenly wait my
window is not drawing i'm expecting it's
your all what's going on it's probably
because of this change was to see if you
rebuilt for tiger and you know surely
that's going to be what's going on so if
you really depend on this behavior what
i suggest doing it's fine those tracking
links where you depend on the behavior
and make manual calls to QT flush port
buffer something like that and that will
get the flushing behavior back but maybe
a better solution is to stop doing your
own tracking loops in those places where
it is a tracking loop and instead switch
to an api like traffic track mouse
location location excuse me which does
flush because it's documented to flush
so what I want you guys to go do now let
me get up right now because i need to do
tend the next session install the feed
take a look at the toolbox release notes
start looking at the new things we've
added start playing with HIV you if you
haven't already try switching on
compositing mode and the standard
handlers for some of your windows you
may actually find out that it's a lot
easier to adopt this stuff than you may
have thought then take a look at the
resolution independence release notes
there's a lot of cool info in there
they're really fun to play with I mean
even if you don't start developing for
it right away turn it on when
application see what looks good see what
doesn't look good and start making with
some things you might need from us from
the toolbox and then you know maybe
start fiddling with it in your app and
you know see if you can't make it work
it might actually end up being easier
than you thought particularly if you've
adopted a chive you also start looking
at supporting accessibility you know if
you're if you're supporting a chive you
it's just a tiny additional little step
to support accessibility if you're in
there and you're modifying your nibs hey
you know by all by all means when we get
support and I be for adding extra
attributes to widgets sorry extra
accessibility attributes to widgets
start selling that information in there
it's only going to do good and then take
a look at all the other Tiger features
that we've added and see what you can do
to make your application look great so
we've got a bunch of information out
there on the web and in the release
notes the top item here this upgrading
to the macro shi toolbox is one of the
featured articles on the developer apple
com website it's really really good it's
a great article covers all kinds of
aspects of H I do HIV UNH I tool box a
little bit of older documentation is
introducing HIV takes you through some
of the basics if you need a little
refresher course go check that out we
have the reference material for a chai
shape it's going to be critical to start
using a chai shape once you become a
chive you because it's going to break
various quick trial limitations and
finally the release notes that I say
release enough enough so now I'd like to
bring Xavi a backup and the rest of the
toolbox crew we can go through some
shooting
you