Re: High Level Toolkit -- is it obsolete or not?
Re: High Level Toolkit -- is it obsolete or not?
- Subject: Re: High Level Toolkit -- is it obsolete or not?
- From: Joel May <email@hidden>
- Date: Tue, 23 Feb 2010 16:30:28 -0600
Nick,
Thanks for clarifying. I've been uncomfortable with using Carbon. My guts are more settled now.
Question about NSThread seeing how GetKeys(), etc. are not thread safe: If I increase the priority of the main thread, then move the view draw cgcontext updates to a lower priority thread, is that a good idea? Will increasing the priority of the main thread reduce latency for getting the keypress and mouse inputs? Does the OS actually honor this request? Can I take the drawRect requests and pass the rectangle to the lower thread and update the view there? Is this crazy?
Non-thread safety of GetKeys() and Buttons(): If I call these in the wrong thread, can they crash the application? Or is the damage limited to erroneous results? Of course, we don't know and we should be good and not do it. But I might get desperate.
Thanks huge for your help.
Joel
On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:
>
> On Feb 22, 2010, at 12:53 PM, Joel May wrote:
>
>> I would like to create a thread (NSThread) with a bumped-up priority and poll the mouse and keyboard the same way I did in the carbon version. I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I can't find them.
>
> There aren't any. GetKeys() still works fine, though it has some annoying differences depending on the target CPU architecture. Also, you need to do this on the main thread, since neither GetKeys() nor Cocoa events are thread-safe.
>
>> The Carbon64BitGuide.pdf explains how the carbon api's have been updated for 64 bit. But I thought carbon was dead in 64 bit and Snow Leopard. What is the deal?
>
> No, Carbon is not dead. The only parts of Carbon that are dead are the drawing components of HIToolbox, along with some legacy stuff like ATSUI and FSSpec. GetKeys() is one of the survivors.
>
>> Am I safe using these api's.
>
> Yes, unless they have been deprecated. GetKeys() has not been deprecated.
>
>> Are we supposed to not use them?
>
> No, but polling is something you probably shouldn't do without a good reason.
>
>> Will they go away in 10.7?
>
> Highly unlikely.
>
>> Why do I read everywhere that carbon is dead and high level toolkit is dead?
>
> Because at least one influential news source ran an incorrect story a number of years ago that Carbon wasn't being updated for 64-bit at all, which is not true, but that hasn't stopped people from believing it.
>
>> If High Level Toolkit is ok, then why doesn't it appear in the docs. If I search the Mac OS X Reference Library, it does not get the same treatment that the cocoa api gets. The only place I see the High Level Toolkit is in the Carbon64BitGuide.pdf and the header files and some cruddy api update doc.
>
> I don't know why a lot of the Carbon documentation was taken out of Snow Leopard. I wouldn't look too far into that, though. The folder manager documentation is also MIA but functions like FSFindFolder() still works fine and are completely supported.
>
>> Is there a way to poll the state of the hardware using cocoa api's instead of the carbon api's?
>
> No. The Cocoa event system does not act until something happens. Don't be afraid of using Carbon in a Cocoa application. Sometimes it's the only way to do something.
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
>
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden