Hello,
I'm new to this list (and OS X programming in general) but it
seemed the place to start. I hope you can help.
My employer, a small 10 person company, has an application that
was ported from OS 9 CodeWarrior C++ to OS X Carbon Xcode. I've
been tasked to transition the app from the existing QuickDraw
drawing environment to Quartz. The Apple documentation describes
the Quartz environment well enough. The documents of interest
appear to be:
"Upgrading to the Mac OS X HIToolbox"
Upgrading_HIToolbox.pdf
"Quartz Primer" QuartzPrimer.pdf
"Transitioning to Quartz 2D"
"Quartz 2D Programming Guide" drawingwithquartz2d.pdf
If you, and the rest of the list will forgive shameless self-
promotion, you might also look at:
Management believes that a simple one-to-one replacement of
QuickDraw calls with Quartz calls is sufficient. "Just encapsulate
all the QuickDraw calls in a class object, and then replace the
QuickDraw calls one at a time." However, the documentation
suggests that this is not only not desirable, but not even possible.
Quartz 2D and QuickDraw have very, very different drawing models.
You certainly can't do a call-by-call translation. Depending on what
you are drawing, you may have to do more, or less work. Can you give
us some idea of what kinds of things you are having to draw?
Most of the documentation assumes that one replaces the entire
QuickDraw and Apple Event model, with a nib-based Carbon Event
model. However, management doesn't want to take that big of a bite
all at once.
They're really separate "steps". AppleEvents is quite different from
Carbon Events and the two different event models can, and should
coexist in some applications. Carbon Events tends to operate
"inside" an application while AppleEvents are sent between applications.
As for Quartz and Carbon Events, there is no inherit dependence
between these two technologies. You can adopt them independently of
one another.
Carbon proposes that you replace your use of the old-style Control
Manager with the more-up-to-date HIView mechanism. If you do that
then Apple recommends that you replace your QuickDraw code with
Quartz because the Quartz drawing will play nicely with the HIView
compositing view mode. However, even in that case the use of the
HIView model and Quartz are not tightly coupled. You can use HIView
with QuickDraw as well.
0. Is this the right list to ask about transitioning from
QuickDraw?
Unequivocably, Yes. You will find folks on this list that can help
you convert QuickDraw code to Quartz code.
Unfortunately, this is not the right place to ask about transitioning
to Carbon Events or adopting HIView. For those tasks you would
probably be better off asking on Carbon-Dev.
1. At what level of granularity does it make sense to
replace QuickDraw calls? Each window? Each control? Each region/
path? The need to obtain and release a CGContext suggests a larger
granularity, like a window.
That depends on what you are trying to replace. If you have a custom
control, I would say work at the HIView level. If you are trying to
change an entire window and don't want to change your event model,
then you can use things like QDBeginCGContext/QDEndCGContext to
replace things at the granularity of a window's update event.
As a general rule, I would expect to use QDBeginCGContext/
QDEndCGContext a lot, unless you are planning to replace controls
with HIViews.
2. Is there any recommended order in which to attack such a
conversion?
What are you planning to do with the event model? Are you interested
in switching to Carbon Events? Are you interested in adopting
HIView? Each of these questions can have some impact on the order in
which you do your conversion.
As a first step, you might start with the "Update Event" handling and
use QDBeginCGContext/QDEndCGContext to just change the way you draw
the contents of a window.
3. Can Carbon event handlers coexist with QuickDraw
WaitNextEvent model?
Yes. WaitNextEvent is implemented under the hood using the Carbon
Event Manager. Whenever you call WaitNextEvent, the computer tries
to handle as many Carbon Events as there are event handlers.
WaitNextEvent will only return if it runs into a Carbon Event that is
unhandled, and which it can convert back into an old-style
EventRecord. I believe that WaitNextEvent will also return if its
sleep time expires. Under the WaitNextEvent model that would return
a NULL event. However, one of the first tasks for any WaitNextEvent
application that wants to play on Mac OS X as a well-behaved citizen
would be to replace the null even processing with Carbon Event timers
so that your machine can spend most of it's time blocked.
Scott
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/email@hidden
