WWDC2000 Session 148

Transcript

Kind: captions
Language: en
good morning all right Wow the home
stretch the last day well as you can see
again I was you saying this with mac OS
10 carbon the theme of this week we are
so excited about how much progress we've
made and how much progress we've made
helping you get on the platform as fast
as possible this session about carving
enhancements to the high level toolbox
is going to go further into depth about
ways that your process of carbonizing
your application is affected it's really
good stuff to know so without delay i'm
just going to bring up piquant here from
the high level toolbox team please
welcome Pete so I hope you had a chance
to check out the carbon enhancements one
session this is going to be a session
very similar in theme we've been doing
so much work on not only on aqua but on
the toolbox in general that we had to do
two sessions to fit it all in this
session will have basically the same
structure as the last session we're
going to do a big section on
architectural changes which are things
that you pretty much have to do in order
to come up on carbon and the ones that
we'll talk about in this session are the
fact that you can no longer draw
directly the window manager port there's
a small change the way control indicator
action procedures are called there are
some changes you will need to make to
control and window definitions not
anything too radical there is a change
in the way you need to instantiate
custom control window and other
definitions and then of course there are
some new dialog item lists accessors
that you'll want to use because of
dialogue opacity then we'll move on to
the stuff that you don't have to do but
the stuff that you will probably want to
do as soon as you hear about it there's
unicode support in the toolbox
everywhere we've added drag-and-drop
support for controlled and then we've
added the usual collection of new
control manager api's and then finally
we'll talk a little bit about carbon in
the toolbox not too much because there
were two hold sessions on carbon events
sessions 121 and 122 and those are
already passed but I wanted to mention
them just to emphasize the fact that if
you get a chance to pull down webcast or
videotape you definitely should
prioritize 121 and 122 because carbon
events are really important so let's
talk about the window manager port Mac
os10 is as you've heard a pre-emptive
operating system and the screen buffer
is basically a huge global shared
resource and for performance reasons we
have not yet solved the problem of
letting you draw to it in the general
case it would be a mess if we didn't
control the access to it and controlling
the access to it is actually more
difficult than it sounds so we're still
working on that issue now you may find
through experimentation that you
actually can kind of sort of draw to
what seems to be the window manager port
under DP for and hopefully that will
only happen by accident because you
don't definitely don't want to have code
that expects to draw to the window
manager port on purpose because soon
after DP for we're going to make be
making some changes that will make it
basically impossible but the news isn't
all bad we have provided a few
replacement services that cover the
common cases that most people needed to
draw to the window manager port for the
first of those cases is custom window
dragging instead of rolling your own
window dragging code we really need you
to use the drag window system call now
it's basically not only do you get live
dragging which is a nice wizzy effect
for users but if it's the excuse me drag
window is now sufficiently customizable
that you really shouldn't have any
problem figuring out how to get the
constraining and gridding and the other
custom behavior that that you need and
and this is part of the whole carbon
events thing basically we send you
carbon event
during window dragging and you can
decide what to do with them we send you
such things as the rectangle the window
would be in if if you were to not change
it and then you have the choice of
changing it or not so that you get the
little greeting effect that you need I
believe in the carbon event session
there was a demo where we showed sort of
docking behavior during window dragging
where windows were docked against the
edge of the screen and docked against
each other and I guess I should also
point out that drag window now supports
layering in the sense that the outline
that's dragged around the screw scuze me
be a window that's dragged around the
screen is uh is cliff according to the
windows that are actually in front of it
so you don't have to override drag
window just to make it look decent the
next case is grow window basically if
you use the system's grow windows
service that enables us to provide live
growing which is basically the window
content redraw as the user grows the
window so if user become if the window
becomes bigger the image in the window
can be drawn by the system more or less
interactively and of course there are
the usual ways to customize window
growing again locally based on carbon
event but there's one there's one method
you can use by overriding a window
definition method message and that is of
course the get grow image region message
and the reason we mention this even
though it's not a carbon event sort of
facility is that it's basically your
only option if you need to do this for
carbon with 102 or 103 104 I guess I
should say but the more preferred
methods are to override the
corresponding carbon event and then of
course the best method would be to
override the window size change carbon
event and the difference there is that
one of these msgs hands you a region and
one of them
hands you a rectangle so if you really
really really need to change the visual
appearance of the growing process then
you're probably going to get stuck
overriding the region version but it's
much better if you stick with the
rectangle version because I believe if
you override the region version that
that prevents us from doing the live
growing so some developers were rolling
their own dragging and and it would draw
into the window manager port and the
primary reason they were rolling their
own dragging was that the drag manager
wasn't versatile enough so what we did
was we added a funk excuse me an API to
change an arbitrary drag reference so
that you can turn off the zoom back
animation for an unsuccessful drag and
of course this API changed drag
behaviors can expand in the future for
us to add more flags that you can turn
on or off on a drag by drag basis and
basically the way you would use this
facility is you would create a drag
reference just like you would for any
other interaction with the drag manager
and turn off it it's zoom back animation
and then either add no flavors and
maintain all the state within your
application or add some flavors that
tell you what to do and mark them all
sender only flavors so that you don't
get windows in other applications
highlighting as if they're going to
accept the drag and so the way we sort
of the usage scenario that we sort of
entertained was people who need to drag
out of a window some object out of a
window and then let the user more or
less drop it in the middle of nowhere
and have something appear there where
you where there used to be nothing
so the last scenario we have a good
explanation for is is people who need to
sample the pixels on the screen and of
course you can still sample pixels right
out of your own windows because we have
a per window buffer that you see you
will you'll be sampling out of the
problem case is sampling pixels that are
outside any of your windows in order to
in order to work well with the
preemptive window manager that underlies
the carbon window manager we have a very
window centric outlook and we're working
on ways to overcome that but basically
let me thanks here ah basically we what
we think is going to happen is that
there will probably never be a
platform-independent way to peek at
pixels outside of your windows and I
guess we'll talk a little bit more about
that on the next slide but once again we
have the caveat of there are things that
work in vp for that you can discover on
your own and in this case you can create
a port and then sort of look at it to
take pics Matt handle and sample pixels
out of it that way and that's one of
those things that very soon after DP for
we're going to change that it doesn't
work anymore and then the final thing to
keep in mind of course is rather than
grabbing video ram directly you should
definitely use copy bits for a number of
reasons so the plain old drawing case is
the most general case and of course
there's not a lot of sort of semantic
opportunity for us to provide other
services when you when you consider the
problem in such a general way sometimes
developers need to draw to directly to
the screen or sometimes developers draw
directly to the screen just because they
want to take over the whole screen and
of course you can still do that but
you're going to do a little work ahead
of time in order to make that happen
basic idea is to create a window that
covers the whole screen and you can do
that your own on your own by hiding the
menu bar or you can do that by passing
quicktime or games boxes to do do it for
you and I sort of tend towards asking
quicktime or game sprockets to take care
of it for you because they also know
about things like hiding the control
strip and I imagine that eventually
they'll be wired up to hide the doc as
well so you don't have to worry about
all those extra details and then of
course the obvious alternative is to
start thinking about ways to provide the
same functionality that your application
was providing by drawing directly on the
screen in some other way and we realized
that probably involves thinking about a
little bit of a redesign but there's not
really an alternative we have to present
today to solve that problem and as I
said there may eventually be some kind
of platform dependent way to do this
right now there's not but we expect
there probably won't be a
platform-independent way we're still
looking at this problem but we're not
able to commit to anything right now so
control indicator action procedures have
changed a little bit and it all has to
do with performance you have to be the
case that the control manager would call
your control indicator action procedure
basically as fast as it could and so if
your proc needed idle time all you had
to do was wait for some of these
excessive calls and call movies task or
whatever else it was that you needed to
call at idle time and in order to
provide more blocking behavior to allow
other processes to have more processor
the control manager will now only call
your control indicator action crock when
the mouse actually moved so if you need
idle time
at this time you should install a timer
and again the carbon event session went
to detail about timers but basically a
timer is a callback that gets called at
various time by the toolbox and one of
those times is during the krona during
control drag tracking or i should say
control tracking and you can pretty much
do whatever you like inside that timer
it's not a sort of a time manager sort
of situation where you're at quasi
interrupt time so definitely look at
adopting timers in order to get I'll
time during control tracking so some of
the definition functions in the toolbox
are changing a little bit for the most
part you're probably not going to notice
a whole lot of difference we've done a
fair amount of work building
compatibility shins into the control
manager in the window manager so that
old control definitions continue to work
even though in general definitions are
carbon event-driven now you can now
write a carbon event-driven control
definition our window definition but you
don't absolutely have to and of course
you can't if you need to shift on to
carbon libs 10 for control definition to
now take an initialize message and the
initialize message one of the parameters
to the initialized message is a
collection manager collection and this
sort of replaces all the nasty
overriding that you might have had to do
in the past you can basically associate
data with tags in a collection manager
collection and then the control
definition can pull the data out of that
collection and the tags will actually
make sense instead of being the minimum
and the maximum and the rest con and
they really mean something else control
initialization messages also can return
an OS status so that if something goes
wrong during the creation of the control
the definition can actually report what
went wrong instead of just mindlessly
fail and this will allow ultimately the
application to figure out okay and not
only did something go
but here's a hint as to what went wrong
so maybe you can work around it or
present an error to the to the user and
let the user work around it the region
calculation messages for control
definitions have a long nasty history
for a number of years they were what we
would call a 32-bit dirty in that they
sort of over Road some pointer values
and set some flags in the high bit and
we used to for compatibility preserve
support for those messages in certain
cases but in carbon it just doesn't make
any sense anymore so we've gotten rid of
those control those control region
messages and what we'd like you to
respond to instead now is message called
get region which has been around for a
while and it's basically a query to you
to provide a particular region and on
the control manager decides how to
associate that region with your control
with window definitions the story is
pretty much the same we have a carbon
event-driven model for window
definitions with a compatibility shim
for old messages and there are some
changes to the old messages as well
there's also there's a window method to
get region which is pretty much works
pretty much the same we ask you for a
specific part of the window and you
returned to us a region and then we
decide how to associate that region with
the window w calc reaches is pretty much
gone away because it well it was not
only not it was not only insufficiently
versatile but basically required you to
poke around inside the window record and
since we want the window record to be
opaque even to window with definitions
that simply wasn't a workable model
anymore and then of course as I said
there's no drawing into the window
manager port you would expect if
anything went draw directly into the
window manager port it would be a window
definition but we can't even allow it
for window definitions so we've done is
we've made sure that when your window
definition is called the current pork is
already set up to something it can draw
into so you don't need to explicitly get
the window manager port you can just
assume that the port is set
correctly when you're called so even if
you don't write a custom control
definition you still often need to
instantiate them and basically we've
added some functions which allow you to
more easily create custom custom tool
box objects and they're basically
analogs between the old classic api's
and the new AAP is you're not required
to excuse me you're not required to use
the new AP is in all cases the old API
eyes are still there but for the custom
definition case you probably want to use
the new AP is one of those new API is
create custom control and basically the
purpose of these api is in general is to
give you a new way to specify where the
code for the custom custom definition
lives and as you can see the controlled
def specs record basically contains a
upp and it also contains a field which
tells us what kind of what kind of feel
to expect in the Union and in this slide
you see the the union is has only one
member so it might seem like the desk
type field is basically redundant but
we've set this up for future expansion
and I believe in the carbon events
section they talked about some of that
expansion anyway when you create a
custom control you pass to interesting
parameters one is the control desk back
i just described and the other is the
collection and you may remember i talked
about a control definitions initialized
message now takes a collection well
here's where the application creates
that collection and passes it in to
create custom control and the control
manager figures out how to make sure it
gets to the control definition so given
that we have this new control depth back
record and it's all about function
pointers and you pee pees you may be
wondering well what happens if I have a
control definition stored in a resource
or another definition for that matter
and it is definitely the case that
putting control definitions and
resources is no longer the right thing
to do however that doesn't mean you have
to throw out all of your client code
basically we have a map which maps your
old resource IDs ultimately to control
definition functions so if you have a
cntl resource for example which
specifies that control definition excuse
me that which specifies control proc ID
2064 that ultimately maps to control
definition resource ID of 129 and then
the control manager has a map that knows
to map 129 to your function are actually
to your control desk fact and I call
this a sort of a virtual resource ID
because the cntl resource stinks there's
a control definition which has a certain
which has a certain resource ID but in
fact that control different definition
doesn't exist as a resource that only
exists as a mass entry and the control
manager knows that when somebody asks
for that control definition resource ID
that should relate it back to your
control desk back which you registered
earlier so here's the function you use
to register a control definition excuse
me yes okay at the bottom of screen
let's just start with the beginning
basically when you register a control
definition you not only provide a
control desk back and a seed if or I
should say a virtual CDF resource ID but
you also provide a callback which allows
you to translate the fields that we're
in the cntl resource into either excuse
me into a collection so that the control
definition when it's initialized message
gets called it can extract parameters
from the collection in a tags format
instead of knowing about all those weird
overridden semantically confusing
parameters that used to have to deal
with and that mechanism is obviously
still needs to be there because cntl
resources are in a certain format and
they have certain fields and we can't
really
make that go away so at some level you
do know you do have to know that that
for example of the maximum and minimum
field meet really mean something else
but at least your control definition
doesn't really have to know and if you
play your cards right your client code
for the most part doesn't have to know
so yet another instance in the series of
toolbox object opacity is that dialogue
item lists are of course opaque and and
when we analyze what kind of problems
that was going to cause developers we
found hella cases where developers were
actually pulling individual items out of
a dialogue item list or inserting new
ones into a dialogue item list and so
we've got now to AP is which allow you
to do this in a controlled supportable
way and I guess the only sort of
non-obvious part of these api's is the
second dialogue item index parameter to
remove dialogue Adam you're not forced
to just remove one you can remove two or
three in the middle of the list if you
feel like it now we're getting into the
section of stuff that you may want to do
once you find out about it basically all
the toolbox objects now support Unicode
and they support it not only in the API
but also internally we still have the
Pascal string api's but basically what
they do is create a CF string graph
which is the object in core foundation
which supports unicode as well as
several other encoding internally and
then we from there on the string stays
CS string forever so if you use CF
string api's you can pretty much be
guaranteed that if you the string that
you set into a control will come back
with one hundred percent round-trip
fidelity if you use the pascal string
api's then we may or may not be forced
to do some conversion and you might lose
a little bit of fidelity so that's one
reason you might want to adopt the cs
string api's there's no
there's no sort of what's the word I'm
looking for there's no requirement that
you adopt them but over the long run
it's probably in your best interest and
I want to emphasize that internally
we're working with CF string completely
so we're not just sort of paying lip
service to the Unicode thing it's really
down into the core of the toolbox
finally I want to talk about see if
string raft semantics just a little bit
in brief corefoundation introduces this
new concept of retaining release
semantics and we of course support those
and what that means is in some cases we
will not actually make a copy of the
string from the toolbox object we may
effectively increment the ref count of
that string instead of making an actual
bike copy of it and basically you don't
need to worry too much about that except
that we wanted to bring it up to point
out that that that if in some cases will
be a performance win and you should
probably read up on CF string rafts and
retain release semantics to understand
that fully now in appearance I think in
in Mac OS 8 we introduced a new API to
deactivate a control but usually when
developers need to disable a control
they resort to highlight control which
is one another one of these functions
with overloaded semantics so now we've
introduced a function called disable an
explicit function we call disable
control and not only is there sort of a
semantic cleanup associated with this
control but it allows us to do some
things in aqua which we weren't really
able to do before basically under
platinum a disabled control looks pretty
much like a deactivated control but
under aqua they look a little bit
different and I don't know if you can
read so maybe you can the labels under
each of these button images so all
I'll just read the math so we're clear
the one on the far left is active
meaning it's basically in the front most
window and the user expects the
interactive excuse excuse me it's in a
window that the user expects to interact
with but it's disabled the second one
over from the left is active and enabled
so it's not only in a window the user
expects to interact with but that button
actually responds to clicks third one
over from the left is inactive meaning
it's probably in a background window and
it's disabled so it's sort of the most
colorless and then the one on the right
is inactive and enabled and that just
means it's in some background window but
if it were in a foreground window it
would be clickable now we've added some
contextual menu manager support to
control and basically that support is
intended to be provided by the control
definition so the control definition is
in the best position to know what
contextual menu to provide so we let it
provide one and basically the way that
the application level client code works
is you call handle control contextual
menu click and it will query the control
definition to find out whether it wants
to provide a contextual menu if it
doesn't want to provide a contextual
menu it will excuse me the control
manager will ultimately set the menu
menu displays parameter to false and
then you can test that after calling
handle control contextual menu click and
if it is false then it means if your
application knows something about that
control or the enclosing window or
something on those lines and they can
provide its own contextual menu we've
added control excuse me we gotta drag
and drop support to the control manager
we've got a few slides on this because
it's a pretty comprehensive support now
the first point here where it says bike
by default controls in that track drag
basically what that means is there are
some controls which support drag and
drop inherently and that support does
not change but you can tell an
individual control whether regardless of
whether it supports that I can drop you
can tell it whether it should or not so
it's really up to you some controls will
call set control drag tracking enabled
on themselves as they're created the
only control that does this right now is
the data browser control and I believe
there's a way to specify that it not do
that but in any case you can turn it off
and of course there are api's to enable
or disable the capability and I think
they're pretty straightforward there's a
setter and a getter and there's not
really much confusion there so the way
drag tracking works is or at least in
one of the cases is you install your
normal drag tracking handlers and while
drive tracking is occurring your
application needs to maintain state so
it knows which of the drag tracking
messages to pass to the control and of
course as the mouse enters the control
you send at the enter control message
and as as the mouse is moving around
within the control you send it the
tracking and control message and I'm
guessing you can figure out what the
leave control messages for but anyway
the port the important message here is
that your app needs to maintain the
state during drag tracking so that
controls are given the right clues to
draw the user feedback correctly and of
course when you receive or when the user
releases the mouth and the drag manager
tells you that the user is intending to
draw you basically pass the drag
reference off to the control definition
it looks at the drag reference figures
out what data it cares about and what
data it doesn't care about and then it
incorporates that information into the
control and in a way this is sort of
like calling set control data except
that you get to pass many different
flavors
perhaps many different items so it's
sort of like it's almost like a
container being shipped off to the
control and the control incorporates
whatever data it cares about now there's
a much easier way to get support for
drag and drop in your application and
basically it involves telling the
control manager for a given window just
handle tracking you don't need to
install tracking handlers you don't need
to install drop handlers everything is
taken care of for you automatically and
you give up a certain amount of control
over the process but we think the
majority case people will just simply
turn it on and forget about it and and
from then on their controls will just
work we're really proud of this API
because it is definitely the longest
function name in the entire mac OS api
[Applause]
we worked really hard to put that in
there so idle control i don't want to
sound alarming but idle controls is
pretty much obsolete with respect to the
standard controls the standard controls
now install timers and that was again
something we talked about in the carbon
event session so they don't really need
idle messages they're more or less
self-sufficient with respect to idling
the control manager still cares about
the one Idol bit so if you have custom
definitions that set that feature bit
you're still okay you'll still get your
idle messages we really want to
encourage you to adopt timers because
it's again it's a performance thing but
if for some reason you really need to
keep that Idol bit set will still honor
it the distinction is that the standard
controls simply don't set the bid
anymore so because they have you know
because they're self-sufficient with
respect to idle time they don't need to
tell a control manager to send them
explicit messages periodically for
Island if you've been to the aqua
sessions you probably saw something
resembling a demo on scroll to hear
functionality we've added basically a
quick summer is when the user clicks in
the page up or page down area of a
scroll bar or in the sort of non
indicator area of eighth of a slider
control the indicator jumps to wherever
user clicks and of course there's
various controversy associated with that
user experience and there are definitely
preferences associated with that user
experience too so if you feel you need
to stick with the old behavior that's
possible but in any case we've added
this functionality for users who want it
and it's basically one of these carbon
add rent a vent driven thing for the
most part if you want if you need to add
support for it in your control you need
to add a carbon event handler and we'll
tell you when to do the scroll to hear
saying now of course like the rest of
the carbon event support in control
definitions we have a shim for the old
messages but there are some conditions
under which we can't do the shim a
translation sort of thing the way to
stay out of the situation where we can't
support scroll to hear for your scroll
bars or sliders simplest way any way is
to instantiate the live controlling
variants oh excuse me to live scrolling
another live tracking variants another
way to do it is if you for some reason
need to have non live tracking variants
specified no action proc for those
scroll bars or sliders really what you
need to stay away from is dry gray
region upp and that's a weird historical
sort of I don't want to call it an
accident but basically it's once again
it's one of those weird overloaded
semantic cases where sometimes you
specify an action proc with a certain
prototype and sometimes you specify an
action product with another prototype
and it's really hard for the carbon
event shim to figure out which situation
you're in so basically it eliminates the
possibility that it will try to call a
function with the incorrect prototype by
simply establishing conditions under
which it won't even try to do a scroll
here so if you stay away from those
situations where it's a possibility that
you would have to specify drag rage Greg
gray region upp and basically you don't
have to worry too much about scroll here
it'll just work click activation is a
whole new facility we've added basically
click activation is a way to specify
what are
wait for a control to specify what kind
of behavior it wants when it's been
clicked on and the window is in is not
active and again an active window is
basically any window that the user
expects to interact with and there are
four cases that are control can specify
erics should say for behaviors that
control can specify for this situation I
think the names are pretty
straightforward control basically either
wants to be once the window to be
activated or not or and it wants the
control to actually be hit or not and
then you can specify all the
combinations thereof and so basically
your application when it detects a click
in an inactive window it can call get
control click activation and then find
out what to do next as a result i
believe the control which supports
getting control click activation is the
data browser control right now but in
the future there may be more controls
which actually care about this so if
you're building framework type of code
you probably want to use get control
click activation in the general case and
and not just avoid it just because you
don't use data browser so here's a chunk
of sample code that shows get control
click activation in action the first if
case is basically if the window is
active do what you always did do what
you do what you're doing now no change
is necessary but if the windows not
active then get control click activation
comes into play and that basically after
you find out what the control want you
can figure out whether you need to
select the window so if the control is
saying activate the window then you just
call select window and if the control is
saying that it wants to handle the click
then again you just call the same old
code that you've always had to handle
clicks and controlled and it should work
just fine so I've given you a long
laundry list of features we've been
adding to the toolbox and I want to go
back over some of them to
emphasize what's what's in store for you
in the next few weeks or a few months
and hopefully few days basically drawing
to the window manage report is no longer
supported it kind of doable in DP for
but don't get used to that idea because
it's going to stop being possible very
soon there's some changes to the custom
window and custom window and control
definition model there's not only
changes to the way you need to
instantiate them but also changes to the
way they need to work internally and
then of course there's the dialogue item
list accessors that we've added in order
to support dialogue opacity then there's
a unicode support pervasive in the
toolbox unicode is obviously an
important future direction there's the
carbon event support in the toolbox and
once again I want to emphasize if you
get a chance to see sessions 121 and 122
on quicktime streaming or video tape or
however it is they end up distributing
these things definitely take that chance
and then we've added a bunch of new
control manager features some to support
the Aqua user experience and some just
because they were cool
you