WWDC2001 Session 131

Transcript

Kind: captions
Language: en
hello and welcome to session 131 my job
as carbon technology manager is to help
you bring your application to Mac OS 10
but of course it is critically important
to continue to support your customers
who are running Mac OS 8 and 9 and
that's what we're here to talk about
today so what is Carbon lib I'm going to
start by defining carbon as the set of
api's that you can use to write well I
should stack up excuse me o defined it
as the set of API is derived from
classic Mac OS that you can use to write
native Mac OS 10 programs Carbon lived
then is a system extension that
implements the subset of those api's
that are available on Mac OS 8 and 9 and
I say subset because although Carbon is
derived from classic Mac OS all current
and future development of Carbon api's
is targeted at Mac OS 10 so where it's
feasible and where it makes sense we
will continue to bring back some of
those api's and make them run on Mac OS
9 or 8.6 but it's important to
understand that our primary goal is to
give you the api's you need to write
killer apps for Mac OS 10 that fully
exploit that platform so it's not always
possible for us to go back and
re-engineer Mac OS 10th style ap is on
top of Mac OS 8 or 9 so why did we do
carbon that then simply to allow you to
develop for Mac OS 10 while continuing
to support your customers who are going
to wait a little bit longer to upgrade
the greatest thing about carbon is that
it provides a single source solution the
same code can be compiled and run on Mac
OS 8 9 or 10
of course you need to condition
condition Eliza and test for API
availability at runtime as you always
have because not all of these api's are
available on every single OS that carbon
supports we'll get into that a little
bit later and the second great thing
about carbon is that it can provide a
single binary solution because we
continue to support the code fragment
manager and CFM executables there are
other alternatives as well including ma
CO and we'll talk a little bit about
that later but rest assured the same
binaries that you create today for Mac
OS 8 or 9 will continue to work on Mac
OS 10 once they're carbonized that is
and this diagram simply illustrates what
is the beauty of carbon that your
application compiled as carbon app will
run on Mac OS 8 or 9 calling into carbon
lib and on Mac OS 10 calling it to the
carbon framework and other frameworks
available on Mac OS 10
there are two versions of carbon lab
currently available for download from
Apple's SDK web page Carbon live 104 and
Carbon live 131 y2 versions because
carbon live 104 is intended for use only
on Mac OS 8.1 it provides the basic set
of Carbon api's that you can use to run
on Mac OS 8 1 through Mac OS 10 these
corresponds the api's you'll find in the
universal interfaces version 3 3 2 and
with this set of api's you can create a
good carbon app that will run on all
these platforms but with carbon level
131 which is the current GM release you
provide your have available to you a
much broader set of api's the more
closely match what you'll find on Mac OS
10 and I'm going to talk a bit about
this later but the important thing to
note is that with carbon Live 131 you
must target Mac OS 8 6 and later because
many of these well all of these newer
api's cannot be brought back to Mac OS
8.1 an interesting thing about carbon of
131 is that it's self localizing it
supports all the languages you see
listed here what this means to you is
that you don't need to carry around
within your installer different versions
of Carbon live for these regions it's
when your carbon app is launched Carbon
they will examine your vers resource
look for the locale and localize
accordingly there's not much that needs
to be localized the title of the window
menu and some error strings and print
dialog types of things none of this was
necessary in carbon of 104 so that
version doesn't need to be localized at
all there will be more locales supported
in future revision of carbon
which we'll get to later so to summarize
this is the version of karbala that we
recommend you target unless you
absolutely need to support Mac OS 8.1 so
I mentioned that you can license Carbon
lib there's no fee for this it's similar
to QuickTime or many of the other
technologies that you've probably
already licensed from Apple at one point
or another you simply fill out the usual
software distribution agreement and then
there's a one-page Carbon lib addendum
the license does include Apple help 163
that's for you to install on Mac OS 8.6
because the app will help viewer app did
not start shipping until Mac OS 9 but by
moving your help into the Apple help
HTML format you can deliver your HTML
help content across all these carbon
supported platforms and we recommend
that you do that and the carbon lib 104
license includes nav services 101 which
we want you to install if you install
carbon live on a 8.1 system because it
fixes some bugs in the in version 1.0 of
nav services so this series of slides
coming up here will be familiar to those
of you who attended scott forestalls
frameworks overview session but I want
to highlight a few things so carbonate
1.04 does support development from mac
OS 8.1 to mac OS 10 we began with all of
the carbon compatible api's that already
existed in Mac OS 8.1 and then we added
the toolbox access or functions or
opaque toolbox data structures control
window and menu properties nav services
1o a set of core foundation
functionality and the first version of
the carbon printing manager this is a
solid set of api's you can definitely
write very good programs
targeting this carbon they want to force
that but when you step up to carbon with
131 running on eight six or later a
whole slew of new API is become
available to you and using these api's
you can deliver a much better user
experience to your customers first and
foremost the Carbon Event Manager this
represents the new event model for
carbon applications we strongly
encourage you to adopt the carbon events
they will make it easier to write your
Carbon applications and also can
dramatically improve performance
especially on Mac OS 10 another one I'd
like to highlight is the IB Carbon
runtime this is what allows you to use
interface builders nib files on Mac OS 8
and 9 interface builder is a as you've
probably seen in previous demos here at
the show a much easier way to design
your user interface and now with the IB
carbon runtime you can use those nib
files in your carbon Live applications
when you're running on Mac OS 9 or later
that brings in some new API is that were
added in Mac OS 9 most importantly the
HFS+ ap is for improved file management
and if you attended the carbon
performance tuning session you learned a
bit about those as well as many
performance and stability enhancements
that we brought with Mac OS 9 and 9.1 so
if you can't bring your customers to Mac
OS 10 we really encourage you to try and
bring them at least two mac OS 9.1 and
finally let's not forget why we're all
doing this when your app runs on Mac OS
10 you get acqua you get all the new
carbon api's because that's where they
originate and you get access to all the
other api's that are available to you on
Mac OS 10 quartz all of corefoundation
even BSD or cocoa api's
I'm not going to get into all the
details here it's pretty well documented
now but these are the basic steps that I
recommend you follow to get your app
carbonized one go get the carbon live
SDK read the Carbon porting guide use
carbon dater to preview the changes
you'll need to make begin adopting those
new api's and then finally Aqua Phi your
interface because if you don't your app
is not going to look very good on Mac OS
10 and that's not the reason why you're
doing carbon in the first place so let's
talk about each of these briefly the
carbon Live 131 SDK includes both the
regular and debugging version of the
carbon Live extension the debugging
version as assertions that help you in
your development efforts it also
includes stub libraries the latest
Universal interfaces folder full of
documentation with links to more on our
website a bunch of sample code and the
Apple help you are 163 which as I
mentioned you can install when you're
installing on 8 6 in the documentation
folder on the sdk you will find the
carbon porting guide props read this
document it's a hundred and fifty pages
of great information
it's got step-by-step porting
instructions lots of great advice and a
complete example of porting an
application including before and after
sample code and also a section on
adopting Carbon advance which I think
you'll find very interesting
next you should run carbon data on your
app this is the instructions for this
are in the Carbon porting guide but it's
very simple you download this tool from
our website drag your application on top
of it it spits out a text file that
contains a list of all the api's you're
importing from the system as well as
some other things like potential
accesses to low memory or resources
stored in the system heap both of which
are not supported in carbon you can look
at this file make sure you know there's
nothing secret in there mail it to us we
have a server who sees that mail
compares that list against our carbon
database and in about an hour sends you
back a formatted HTML report that looks
something like this at the top of the
report is this nifty pie chart gives you
an idea of the level of carbon
compatibility you're already at for each
API or each function that your app
imports we tell you whether it's
supported in carbon modified in carbon
not recommended in carbon or unsupported
then the remainder of the report goes on
to list specifically for every API that
is not fully supported and what that API
is its level of support and
recommendations for alternatives
alternative api's or other methods of
achieving similar functionality in
carbon if possible so use this report to
get a general idea of what you need to
do and I would encourage you during your
carbonization process that every once in
a while we take your your latest binary
drop it on carbon data and get a new
report and see how far you've come it's
a great way to gauge your progress
so then you have to get to work right
changing all kinds of stuff in your code
much of that is fairly tedious and very
simple adopting accessors for opaque
toolbox data structures changing your
upp s we don't support the generic new
routine descriptor for example you have
to use specific ones like new control
descriptor of the new control action upp
might be one example all of that is
really straightforward and pretty simple
search and replace kind of stuff there
are some api's that virtually all of you
will need to adopt if you're currently
using standard file now is the time to
stop now if Services has been around
since Mac OS 8 it's a much better UI and
it's supported on Mac OS 10 as well as
beta 9 through carbon we need you to
start a diet we need you to adopt nav
services and I'll also describe some
other benefits of that later the carbon
printing manager is necessary for anyone
who's going to print because Mac OS 10
has a very different print architecture
than Mac OS 8 and 9 and the carbon
printing manager hides that from you by
providing a high level API that supports
both platforms when you're printing on
Mac OS 8 or 9 it calls through to the
classic route manager and uses the same
classic drivers that you're already
familiar with and when you're running on
Mac OS 10 it uses Mac OS 10 s native
print drivers to deliver to output and
you don't really need to be aware of
that the API is fairly straightforward
we try to make it as simple as possible
for you to convert to the carbon
printing manager without totally
altering your print loop and finally for
help
delivering help to your customers Apple
has standardized on HTML help delivered
through the Apple help viewer so we no
longer support Apple guide or balloon
help so we encourage you to adopt the
Apple help you or api's and if you do
things like tooltips and whatnot then
you should use help tags and then the
last step you've got your app up and
running now you want to make it look
good on Mac os10 the first thing I would
advise you to do is to create a new
high-quality 128 by 128 bit icon your
icon is the first thing a user sees it
is their introduction to your
application and a beautiful
well-designed
informative icon tells the user that you
care and that you want to deliver the
best possible application next you'll
need to adopt the system appearance or
at least we highly recommend that you
adopt system appearance through things
like the appearance manager and other
api's that we've made available to you
to automatically adopt or excuse me to
automatically appear as an with an aqua
interface on Mac OS 10 or with the
Platinum interface on Mac OS 8 or 9
and also you need to follow the aqua
layout guidelines both of these steps
are much easier if you use interface
builder to design your interface and
then use the nib files resulting from
that to display this interface on Mac OS
8 and 9 or Mac OS 10 and finally we
recommend that you adopt the sheets
api's we've made these very easy for you
now because nap services and the carbon
printing manager both supports sheets so
what this means is a single set of
sheets api's will do the right thing on
Mac OS 8 9 and Mac OS 10 so when your
app is running on 8 or 9 you'll continue
to get application modal dialogues and
when you're running on 10
you'll get document modal sheets
documentation
the definitive source of API support and
carbon is the header files so always
look there first you want to know is
this particular API supported in carbon
for every function it will state right
in the headers what level of carbon
support is available after that the
carbon spec great place to look for more
information about API is not only
availability but recommendations for
unsupported api's the current
specification is the source of the
information that gets put in your Carbon
Data Report I'll talk about that in a
second I've already mentioned the Carbon
porting guide
lastly techno 2003 is sort of a mini
porting guide it's not specific to
Carbon developers but it provides a lot
of useful information for anyone moving
code from eight or nine to Mac OS 10 so
the carbon spec lists all the API is in
the universal interfaces those that are
supported as well as unsupported gives
you the inclusion status tells you what
version of Carbon lib or carbon that
they're available in and also when
applicable what version of the OS is
required to support that API and for
api's that aren't fully supported the
spec generally provides guidelines or
recommendations for alternative api's
here's a picture of the carbon spec this
page is on the memory manager you can
see that maximum sis is unsupported more
master's for example is not recommended
and we tell you there you should instead
use more master pointers and as you can
see more master pointer says Carbon
applications should use this function
instead of more masters and in all cases
for supported api's we tell you what
version of carbonate is available in and
that they're available in 8.1 and late
so again it's very useful information it
is not updated as frequently as a header
file so there's some lag and that's why
you should always look at the headers
first but the spec is generally updated
several times a year and I think over
time we're going to get in closer sync
for additional documentation I highly
recommend the learning carbon book from
O'Reilly I hope you all picked it up how
many of you got the learning cocoa book
okay
leave the room I'm having an informal
competition with my cocoa technology
manager counterpart and she's winning
right now just rather perturbing so I'd
like you all to go out and buy the
learning carbon book now there is a
carbon Tips & Tricks web page you should
bookmark this page there's a lot of
great information there created by our
developer technical support group so as
they find issues commented Carbon
developers they put a document that on
the webpage there so in fact I'll be
referring to that a few more times in
this discussion and finally the Carbon
developer homepage that always contains
pointers to the latest SDKs what's new
with carbon development things of that
nature and I recommend that you book
that bookmark that one and check back
frequently okay so that's it for the
getting started part let's dig in let's
talk about some of the things that
you're likely to encounter now as you
begin your development efforts so the
first thing you need to do to get as you
carbonize your app or when you're ready
to run as a Carbon app is create a plist
resource
this tells malko is ten that you are a
carbon application it is nothing more
than the property list the xml property
lists that you would create for a
bundled Mac os10 application that same
information simply paste it into a
resource in your
single binary application you still need
to maintain your verse open FF and all
these other resources for compatibility
with Mac OS 8 or 9 but when you're
running as a carbon app my Mac OS 10 the
plist
resource supersedes and overrules the
information in in your resources and
this is documented in tech note 2013 by
the way many people ask me about the
carb 0 resource which was the first way
that we recommended people identify
their carbon application we still
recommend that you include a carb 0
resource however you must include a
plist resource as well
it is very important that you continue
to test for API availability at runtime
as you always have when you have an
application that can run on Mac OS 8 9
or 10 it's no different than supporting
an app when you when you have had an app
that ran on 6 7 & 8
some api's are available in different OS
releases that aren't available in others
so the way to do this first and foremost
is to use Gestalt Gestalt is the best
way to test for base functionality like
is Quicktime installed and then when you
need to test for specific API s that may
not be supported across all versions a
quick time
then use a T vector test to find out if
that specific function that you need is
there if you haven't used the T vector
test before this is documented on the
tips and tricks webpage and finally do
not rely on the carbon live version to
determine whether particular API is
available because Carbon live sits on
top of Mac OS 8 or 9 and in most cases
is simply exporting the api's that are
available in the underlying OS so it's
not a reliable indicator of whether a
particular API is there for you at
runtime an example of this would be if
you said oh I'm running on a carbon of 1
3 131 the HFS+ API is must be available
to me you would be wrong because those
api's were introduced in mac OS 9 so
your Gestalt test would tell you that
right up front
accessing non-carbon api's yes you can
we don't encourage it it makes your code
less portable and more difficult to
maintain but the option is available to
you and the way you do that is using the
get shared library function to find
interface Lib and then the find symbol
function to locate the specific function
that you want to call and this again is
documented in the Tips & Tricks web page
be sure that you verify that you're not
running on Mac OS 10 because interface
live is not available there now if
you're if you're doing the proper error
checking with get shared library you'll
of course find out it won't return
interface Lib but we find that a lot of
developers forget to do that and so they
just assume that it's always going to
return with interface Lib and when it
doesn't they crash so trying to avoid
that there's a few things you need to be
aware of when you're writing an app that
can run in two very different memory
environments I'm sure you're all aware
that Mac OS 10 provides essentially
unlimited address space okay for gigs
that's a lot main thing here is don't
try and allocate all of it
it has performance implications okay
there's a finite amount of RAM in the
system and even hard disk space for
backing store may potentially be limited
and of course it's a lot slower so use
what you need and give it up when you're
done that's really all you have to do if
you're currently using free mem to find
out how much memory is available for you
to allocate you're gonna find that
that's not very useful on Mac OS 10
because it returns essentially a
meaningless value and it returns that
same value every time you call it which
is currently 20 megabytes we might
change that it doesn't matter it's just
an amount that we set to kind of allow
apps who aren't being very smart about
it
to continue to run
and another final point is if you're
using zones to manage memory right now
you should know that your grow zone
problem we call them a co s10 zones are
essentially well they're unsupported in
Mac OS 10 most of the zone functions are
simply no ops on 10i Mac OS 8 and 9 you
need to continue to do all the same
things you've always done to manage
memory there
Ram footprint so this is primarily of a
concern to apps running on 8 or 9 carbon
Lib introduces it brings in some extra
code that you're probably it wasn't
there before with the interface Lib and
so you need to adjust your memory
requirements accordingly and the amount
varies widely so we can't really give
any specific recommendations other than
retest and wreak Walla Phi with carbon
Lib you'll need to increase your stack
and your heap some amount
if you do plugins or either write
plugins or use plugins in your app you
should know that carbon apps can load
interface live based plugins no problem
that's on Mac OS 8 or 9 on Mac OS 10 of
course they can't because interface live
is not available there non-carbon apps
cannot load Carbon plugins Carbon lib
explicitly checks at launch time that
the host app is carbon and if an
interface live based plug-in tries to
load it will be refused
if you've been to the carbon events
session the carbon performance tuning
actually most of the keynotes on the
first day
you've probably heard over and over
again stop polling right polling is is
bad especially on Mac os10 not so bad on
Mac OS 9 nobody really notices but a Mac
OS 10 it really kills performance and
one of the best ways to do that is to
adopt Carbon events the Carbon Event
Manager simplifies your code because it
can handle for you your human interface
elements can drag your windows resize
draw the menu bar all these things for
you it takes that out of your event loop
and manages it for you and it can
eliminate the need for null event
processing I'll talk about that in a
second what one of the biggest areas
where we find application developers are
polling is with Mouse tracking and
there's a very simple way to stop doing
that using carbon events so if you have
code right now that uses get mouse
button still down those kinds of
functions in a tight loop you can
instead use track mouse location it
doesn't alter your loop at all it's very
simple to adopt but the difference is
that track mouse location does not
return until the mouse is moved or a
button is released that makes for a much
more efficient system and finally
we continue to support wait next event
and carbon no problem there but you
should be aware that there are some
differences in the wait next events
behavior under carbon and the primary
one is that the sleep time that you
request is what you're going to get
unless an event arrives for your app so
if you request six ticks you will not be
you'll not get control back in two ticks
with a null event okay you'll get
returned after six ticks so the
important thing here is we really
recommend that you use large sleep times
two or three months should be sufficient
for most applications and then use
carbon timers to get processing time
when you need it so I think the best
thing to say is that if you're relying
on null events right now to do idle time
processing you'll find that it's it's
not going to work reliably under carbons
so really you should adopt Carbon event
timers and it doesn't alter your event
loop you can still keep using wait next
event but just start using timers you'll
be much happier your customers will be
much happier because your app and the
rest of the system will be more
responsive and finally I'd like to put
in a little plug for application
packaging this is the preferred way to
deliver your apps especially on Mac OS
10 but you can do it on Mac OS 9 today
for an example of that look at Apple
works six one two it provides a better
user experience because it's a
drag-and-drop install it supports the
localization scheme of Mac OS 10 it
works on all file systems flat file
systems as well as HFS and a single
package can deliver more than one binary
so you can deliver a CFM executable for
Mac OS 809
and amok Oh executable executable for
Mac os10 tech note 1188 describes
packaging today on Mac OS 9 we are
working on an improved package support
in an upcoming version of carbon Lib and
I'll talk a bit more about that later
and now I would like to bring up a very
special guest
Vince Parsons of the Adobe Acrobat
engineering team to share with you his
experiences porting Acrobat to carbon
ok so mark thought it'd be a good idea
if someone who has actually been to this
process instead a few words about our
experience is what we learned the
mistakes we made and hopefully we can
teach a little bit from what we learned
and so you won't make the same mistakes
we did so I'm calling this carbon lived
from the trenches so it's kind of a
group of tips tricks in gotchas we
discovered during the development of
Acrobat Reader 5 so first why do we use
carbon lib we've got a large legacy code
base and we wanted to move that toward
10 but we didn't want to sacrifice our 9
& 8 development we also didn't want to
have two different sets of code bases in
two different binaries we wanted a
single binary that worked everywhere
with a single code base that worked
everywhere we also wanted to have an
easy way to debug the Carbon API code
that we're using even with the latest
version of Mitch works they distributed
to show the debugging on OS 9 is still
more mature so you can debug your Carbon
API is on 9 as well as 10 if you use
carbon Lib and they also provide the
debugging Carbon Lib library which gives
you lots of nice asserts when you're
using the API as incorrectly and the
other thing we got is we got a lot of
goodies that came free with carbon Lib
corefoundation ml te and carbon events
are used extensively in Acrobat core
foundation ml te are available in OS 9
but the latest Grist versions are
only delivered via carbon lip so you
wanna make sure you go that route so a
few tips so as is marks gust or several
runtime difference you have to worry
about
there's course the menu layout so quit
and preferences belong over under the
application menu not in the file and
edit or wherever preferences typically
goes and rather than just do a check on
system version of ten you should
probably use the gestalt menu manager
aqua layout bit that way it's more
dependable and you should actually avoid
vert system version checks in general
the help menus another issue to get the
help menu on nine there was an API for
it on ten to help Meany doesn't
naturally exist there's a new API with
part of carbon called HM getting help
menu that means that API will on tin
actually create the help me if it isn't
already there and will return it to an
on 8/9 as well as tell you which offset
from beginning the menu the first item
actually exists so on eight and nine
when they have the show balloons and
those sorts of items and let you know
what offset off the beginning to use
when adding your own menu items some
other issues are window attributes so
when you're creating a window with the
current new window API
there are several attributes that are
ten only and if you actually create a
window with these attributes on eight or
nine it will fail and you will just get
a null window back so there are some
Gestalt checks provided before actually
checking those attributes and just make
sure you check those attributes before
you try to assign or check that each the
Stolte bits before you assign the
attributes to the window so the create
works and the other thing is memory
management handles make little sense on
OS 10
they make great sense both handles and
tip mem handles on OS 9 you can check
the gestalt memory map sparse to know
whether you're in a sparse environment
you should use just pointers or if
you're not then you should use the
handles like you're used to under eight
and nine so most applications will call
outside of the core set of API s that
are part of carbon
it's just a fact of life and Acrobat
does it and it's actually not a big deal
for calling to the OS 10 only api's just
use the use the Cullum Akko framework
sample that's part of the SDK as a guide
it's a simple case of your loader
framework find a entry point in it and
you call it you can use this to call
directly into core graphics you can call
in to i/o kit any of the ten only api's
that are currently exported only through
mock oh you can also call stuff that
exists only an eight nine if you're
patching traps yes we still patch a trap
in Acrobat it's a big no-no but we do it
so you can still call it get your
librarian interface live or whatever is
the appropriate library for the API
you're looking for and do find symbol
and just again call the function pointer
so you can do that for dealing with
patching traps heap zones
any of the things that aren't supported
in the Carbon API so you've heard a lot
this week about drawing text and
everyone says make sure you draw text
the right way because drawing text the
old way looks really really bad on ten
so most of us still have drawstring and
draw text calls and yes it does work but
it looks bad the draw themed text box
API has been discussed a lot this
conference it works it works well it
draws anti aliased with cord graphics it
also because it takes a CF string as an
argument removes a lot of the issues of
encoding and font selection for you so
if the if the text you can just pass it
into as a CF string the OS automatically
figures out O's is Japanese oh this is
Roman and we'll pick the appropriate
font if you have the language kit
installed and will display the text
correctly and starting with carbon Lib
1.3.1
it is now available on 8 and 9 not just
on 10 so like many Adobe apps we have
plugins and we have legacy plugins that
are linked to interface Lib we have to
support them because they're in existing
technology and we found a few caveats
with dealing with plugins that you
should be made aware of first of all
when a
plug in this interface live based
creates a window with say new see window
it will not necessarily be create it in
the right layer there's a very distinct
difference between the modal and the
document and the floating and those sort
of layers with carbon live and on 10
they will pretty much always be created
the document layer so if you have a
modal dialog created from a plugin it
may end up in the wrong layer and this
is always true if you use a custom proc
ID because the system can't even try to
guess what type of window it is so to
solve this if you see that a plugins
created a window you can call set window
class on it or the forthcoming s window
group API and just move it from the
document layer to the appropriate layer
and all will be well
another thing to think about is Carbon
events now if you're moving toward
Carbon events and current events are
coming any time you call wait Nick
Saban's recalling run event loop or
there's several other ways anytime you
call into a plug-in they're all gonna
call modal dialogue they no way next
event directly they're gonna call things
which may cause your current events and
Carbon timers to be called and so just
because you're calling you to a plugin
doesn't mean you can't be ready for your
code to be called back at any time
so just be aware if you have any
reentrant c issues in your coven event
handlers or your timers make sure you
think about those before you start
dealing with the plugin issues so a few
tricks there are a whole suite of api's
as part of carbon based on CF string the
wonderful thing about these and you
sorry you can create controls windows
menus almost almost all the major UI
elements can be created with CF strings
for their titles this allows your UI
code to be completely font and encoding
agnostic again as mentioning you'd stick
in a Japanese CF string you stick in a
Roman CF string you stick in a Chinese
CF string the OS does the rest you just
pass it the string it sets the thought
for you deals with all the encoding
issues it also makes it easy if you want
to have a Roman
and a non-roman checkbox say next to
each other because just passing the
string you can have any number of fonts
in in the dialog for the various
controls and carbon takes care of it for
you if the fonts are available there are
a couple limitations there are issues
with regard to using these on OS 9nh the
menu in window titles are always going
to be the system font you can pass in
another a string with a different coding
due to limitations of the underlying OS
they will always be the system thought
and they're also limited to two and
fifty-five bytes because they are
translated into a Pascal string to go
into the existing functions that are
underneath in the real OS another thing
to think about is the create window from
nib API interface builders been talked a
lot of it in this conference you can
create your dialogues in Windows in
interface builder and then create them
in a carbon app with crate window from
nib and this works on eight point six
nine and ten it's a whole lot easier
than dealing with dialogues and diddles
and if you have existing dialogues you
can import them directly into interface
builders there's you go the file menu
say import resource it's there
it also has native support for several
the new control types so you can do your
bubble bevel buttons your round buttons
your progress bars all the types that
previously with a dialog diddle you had
to create control resources and it was
rather difficult a couple of issues with
regard to nib files is they have to be
external you cannot embed a nib file
into your application as a resource and
this again goes toward the packaging
issue and and the nib file is actually a
package itself containing a few files
and that has to sit outside of your main
executable if you want to actually use
create window from nib see the converter
nib sample on the Carbon SDK and it
gives a good description of how to load
the nib file and then create the window
from it so with all things with new
technologies there are a few gotchas
so there are several api's that are
currently marked as OS 10 only don't
assume they'll stay that way
several api's have migrated from being
10 only api's into carbon lib over time
I mean couple examples get application
text encoding a 10-1 to draw theme text
box set in 131 there's going to be more
in the future
don't make assumption that if draw theme
text box exists that you're on 10 or any
particular API if you're checking on its
existence assume that means the API
exists not what OS you're running and as
Mark said avoid the checking the carbon
version from Gestalt well it's useful in
some minor areas in most cases of
problem this is because if you ask
OS 10 it says 1.3 and you ask OS 9 it
says 1.3 they don't mean the same thing
because the versions of Carbon live in
OS 10 have not matched up as nicely as
they had hoped it's always good to use
narrow Gestalt checks if you can check
for unresolved functions with a team
vector test and if you do need to check
for carbon live versions say to get do a
workaround for a bug or some other issue
like that combine it with a system check
so that you know you're running on Mac
OS 9 and this is the carbon live version
and the only time we call on this API is
at lunch because we require carbon live
125 and later and that's the only time
we check for this API gives us a good
baseline to work from so resource chain
management
so the carbon API is added a few new API
is for us to modify the resource chain
previously we had if you want to modify
it you can either open and close or you
could modify the chain directly if you
knew the structure right now there are
new API is for inserting a resource file
detaching a resource file there's
there's several other API is dealing
with this use these wisely especially
under Carbon living as a as a plug-in -
as a as a developer who uses plugins
it's very tempting to every time we call
them into a plug-in setup the resource
chain
but everything in you need it call the
plugin and then it says the plugin
returns you pull everything out of the
resource chains they have no resource
collisions this doesn't work as well as
we'd hoped first there's an issue with
regard to it's not the most efficient
thing to do it's far more efficient to
step your resource chain in the right
order at the beginning and then do you
get resources and the collisions won't
happen if these things are aligned all
the way you want them to be also there's
a bug in nav services in Mac OS 8 six
through nine one that will cause your
resource chain to be corrupted in
certain scenarios so if you actually
modify the resource chain from a current
event handler or timer
that's called during a nav call because
nav will call what next event whilst I
legs are up it will actually corrupt the
resource chain when you return from nav
so if you do modify the resource change
from a coverin event timer or handler
make sure you don't do it during a nav
call so there are a few things that oh s
10 does for you just behind the scenes
that carbon lib doesn't and you got to
make sure you do them yourself a couple
examples create route control if you
want to use the new control embedding
architecture built into carbon you have
to create route control on OS 8 9 on
Tenace automatic on 8 9 you have to call
it explicitly or have a deal GX resource
next to your D log also idle controls on
tan again they do that for you to
animate their buttons to animate the
progress bars chasing arrows etc on OS 8
9 if you don't call idle controls
yourself
they won't animate so if you want the
chasing arrow as the progress bar to
animate correctly stick a call to idle
controls in a carbon timer and that'll
take care of it
so printing
printing is an interesting issue for
Acrobat because we do a lot of it and
moving toward the printing manager API
is on in carbon several things you want
to be aware of first the carbon printing
manager on 8/9 is really just a wrap
around the existing print manager and a
lot of the API is for getting page sizes
and things like that are just wrappers
around PR general calls so a few
mistakes we made and hopefully I can let
you avoid them is use the session api's
this the non session api's do work the
session API API has worked much better
and we did the non session first and
then rewrote our whole printing code use
the session ones also write your
printing code for 10 first not the other
way around again we made this mistake we
wrote it for 9 got it working treadle
intent
didn't work at all this is because 10 is
far pickier about the way you use the
print manager if you don't call things
in quite the right order in the right
way 10 will not like it
but it'll work fine in carbon lips so we
need to rewrite our printing code yet
again for 10 and once we get it running
on 10th it worked everywhere the biggest
thing we ran into was some driver and
compatibilities not all drivers are
fully compatible with carbon loop you'll
see this come up in several different
ways
some features will just be ignored that
are part of the print driver for example
reverse order printing in invert pages
rotation end up printing those sorts of
things they just may get totally ignored
and your user may choose do to a
printing and it comes up without that
choice other drivers will not print
color and they'll print just complete
grayscale again this is caused to
intimate abilities between carbon Lib
and the printer drivers Apple is
currently working with the driver
vendors to solve these issues so in the
long run this will not be an issue but
in the short run be very aware that this
will hit you if you are doing lots of
printing
and the most important thing be sure to
test and a lot as new versions of carbon
live come out test them as quickly as
you can main treat each new version of
carbon lived like it's a whole new
version of OS 9 because in many ways it
is the seeds do get posted in the ADC
website for selecting premiere members
when they show up get them immediately
if you've already got a shipping
application or if you're close to
shipping and test your entire products
because you can test your product far
better than Apple ever could and while
they may find some things you'll find
things that they never thought to look
at and you don't want to discover that
once you've got a app that's actually
out there and shipping that suddenly
your user gets new versity carbon lib
through software update and your app
breaks this has happened to several
third parties you don't want to happen
to you so get the that get the new seeds
and test them immediately and report
bugs the only way it's going to get
fixed is if your pork bugs and do that
through bug report at apple.com so
that's that's the biggest thing I want
to leave with you is don't let any
compatibilities affect you and that's it
for my part thank you very much and a
good luck in your carbonizing
Thank You Vince it's great presentation
you know Vince and his team contributed
immensely to improvements in carbon live
and you guys can too by filing bugs and
feature requests so I really encourage
you to do that I'm gonna stress it again
at the end where we going with carbon
lib we're going forward
I hope it's apparent to you by now that
Apple is investing heavily in carbon and
will continue to do so as I said earlier
as much as possible we will try and
bring back new carbon api's and make
them run on eight or nine that will make
your development efforts easier
obviously but it's important to
understand our focus is Mac OS 10 but we
will continue to support all the carbon
api's we've already introduced so what's
next with carbon and carbon Live karbala
1.4 it's currently seated you can
download it from the ABC website
carbon-14 includes some new api's to
more closely match what you'll find on
Mac OS 10 improved application package
support as I mentioned earlier is coming
in Mac in carbon at 1.4 and support for
more localizations Brazilian Portuguese
Korean Danish and some others give us
feedback as soon as possible we're early
in the seed stage right now so the
sooner you give us your feedback the
more likely it is that we can fix that
bug or add that feature that you really
want how do you do that bug report Apple
comm any ADC member even online members
can file bugs using our bug reporter
system they're seen they're funneled
directly into engineering and acted upon
so please use that method for
non-technical feedback you can send it
to carbon at Apple calm
I will see it others will see it and
it's also a useful feedback mechanism
for support I encourage you to sign up
for the carbon development discussion
list at lists Apple comm this is a great
place to get your questions answered as
well as share your knowledge with other
developers it's monitored by thousands
of developers and a whole bunch of Apple
engineers as well if you need one-on-one
support that's available through our
developer technical support group you
email dts at Apple comm this is fee
based support those of you who are
selected premiere members receive a
certain amount of tech support incidents
with your membership but anybody can
purchase those which brings us to the
roadmap well most of these sessions have
gone by already but I encourage you to
watch on ATC TV or on the DVDs when they
come out the session on the carbon Event
Manager remember improved performance
stop poling make your code easier Carbon
windows and menus more of the same and
the application packaging and document
binding well you learn about packages
and also how to how to use launch
services to bind your document types to
your applications on Mac OS 10 if you
have feedback that you'd like to give to
the high-level toolbox team the feedback
forum is today at 3:30 so right after
this session in room C this is me again
I am the carbon technology manager so
I'm the guy you should send your issues
and concerns to
you