Re: High Level Toolkit -- is it obsolete or not?

[Erik Buck]

Never call -drawRect: directly.  It is a Template Methods i.e. "Don't call us; 
we'll call you."  (Note: there might be some exceptions that prove the rule.)

As of Leopard and possibly sooner, individual dirty rectangles are available 
through the - getRectsBeingDrawn:count: method if you use it within the 
implementation of -drawRect:.  Use - (void)getRectsBeingDrawn:count: for more 
detail beyond the automatically coalesced rectangle passed into -drawRect:.

- (void)getRectsBeingDrawn:(const NSRect **)rects count:(NSInteger *)count

Parameters
rects
On return, contains a list of non-overlapping rectangles defining areas to be 
drawn in. The rectangles returned inrects are in the coordinate space of the 
receiver.

count
On return, the number of rectangles in the rects list.

On Feb 26, 2010, at 9:30 AM, Joel May wrote:

> Nick,
> 
> I'm using [NSView setNeedsDisplayInRect: r] and [NSView drawRect: r], so I'm 
> not explicitly flushing and that's not goofing things up.  Beam-sync is 
> related to flushing, I think.  I don't know how to turn it on or off 
> programmatically and it does not appear in QuartzDebug -- I think it was 
> removed in Snow Leopard or the newest XCode.  It might be renamed to 
> AutoFlush drawing.
> 
> However, I've found that I was not using the right CG function:  I was using 
> CGContextDrawTiledImage() 
> and should have been using CGContextDrawImage().  In my early testing I came 
> to the mis-conclusion that CGContextDrawTiledImage() was faster.  It is 
> actually about twice as slow.  I was jumping between machines and not being 
> methodical about my testing.
> 
> I've redone speed tests and now if I don't stretch the window, the screen 
> update is fine on my new iMac.  If I do stretch to full screen,  
> CGContextDrawImage() takes about 80 ms and CGContextDrawTiledImage() takes 
> about 140ms.  
> 
> Then I turned on QuartzGL (which I had never heard of until your email, 
> thanks) with 
> HIWindowSetBackingLocation(windowRef, kHIWindowBackingLocationVideoMemory).  
> 
> Now, CGContextDrawImage() takes 4ms or less to update the entire screen.  
> This is beautiful.
> 
> I still need to test on my Tiger, PPC mac.  I'm thinking screen updates with 
> Quartz will be a problem there, but I don't know yet.  I might have to use a 
> separate executable with QuickDraw.  I use copybits in my own dirty rectangle 
> handling in Carbon code. [NSView drawRect: r] seems to coalesce all the dirty 
> rectangles into one big rectangle that also contains a lot of area that is 
> not dirty.  My old code has smaller, non-overlapping dirty rectangles updated 
> with copybits which should be more efficient.
> 
> Conclusion:
> 
> * Quartz is actually sufficiently speedy to update the screen, at least on a 
> new mac.
> * QuartzGL is great, esp when stretching the image.
> * Not sure about Tiger (no QuartzGL) or older machines yet.  Might need to 
> stay with QuickDraw/copybits.
> 
> Thanks for your help.  I would have wasted a lot of time with CoreAnimation, 
> which I don't need for this project.
> 
> Joel
> 
> 
> On Feb 23, 2010, at 5:50 PM, Nick Zitzmann wrote:
> 
>> 
>> On Feb 23, 2010, at 4:35 PM, Joel May wrote:
>> 
>>> Thanks for the info about drawing in a different thread.  I won't waste my 
>>> time and sanity.  I guess I need to figure out how to speed up the drawing 
>>> instead and keep it in the main thread.
>> 
>> How often does your app flush its changes? If it's more than 30 f/s, then 
>> you're wasting redraws, and either need to disable beam sync, or cut back on 
>> the animation. You can use Quartz Debug to find out, and control the beam 
>> sync feature.
>> 
>> Did you also try QuartzGL? It didn't work correctly in Tiger, and it's off 
>> by default in Leopard & Snow Leopard, but it ought to work on most Macs. 
>> Again, you can experiment with this using Quartz Debug.
>> 
>> Nick Zitzmann
>> 
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/erik.buck%40sbcglobal.net
> 
> This email sent to erik.b...@sbcglobal.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Joel May]

Nick,

I'm using [NSView setNeedsDisplayInRect: r] and [NSView drawRect: r], so I'm 
not explicitly flushing and that's not goofing things up.  Beam-sync is related 
to flushing, I think.  I don't know how to turn it on or off programmatically 
and it does not appear in QuartzDebug -- I think it was removed in Snow Leopard 
or the newest XCode.  It might be renamed to AutoFlush drawing.

However, I've found that I was not using the right CG function:  I was using 
CGContextDrawTiledImage() 
and should have been using CGContextDrawImage().  In my early testing I came to 
the mis-conclusion that CGContextDrawTiledImage() was faster.  It is actually 
about twice as slow.  I was jumping between machines and not being methodical 
about my testing.

I've redone speed tests and now if I don't stretch the window, the screen 
update is fine on my new iMac.  If I do stretch to full screen,  
CGContextDrawImage() takes about 80 ms and CGContextDrawTiledImage() takes 
about 140ms.  

Then I turned on QuartzGL (which I had never heard of until your email, thanks) 
with 
HIWindowSetBackingLocation(windowRef, kHIWindowBackingLocationVideoMemory).  

Now, CGContextDrawImage() takes 4ms or less to update the entire screen.  This 
is beautiful.

I still need to test on my Tiger, PPC mac.  I'm thinking screen updates with 
Quartz will be a problem there, but I don't know yet.  I might have to use a 
separate executable with QuickDraw.  I use copybits in my own dirty rectangle 
handling in Carbon code. [NSView drawRect: r] seems to coalesce all the dirty 
rectangles into one big rectangle that also contains a lot of area that is not 
dirty.  My old code has smaller, non-overlapping dirty rectangles updated with 
copybits which should be more efficient.

Conclusion:

* Quartz is actually sufficiently speedy to update the screen, at least on a 
new mac.
* QuartzGL is great, esp when stretching the image.
* Not sure about Tiger (no QuartzGL) or older machines yet.  Might need to stay 
with QuickDraw/copybits.

Thanks for your help.  I would have wasted a lot of time with CoreAnimation, 
which I don't need for this project.

Joel


On Feb 23, 2010, at 5:50 PM, Nick Zitzmann wrote:

> 
> On Feb 23, 2010, at 4:35 PM, Joel May wrote:
> 
>> Thanks for the info about drawing in a different thread.  I won't waste my 
>> time and sanity.  I guess I need to figure out how to speed up the drawing 
>> instead and keep it in the main thread.
> 
> How often does your app flush its changes? If it's more than 30 f/s, then 
> you're wasting redraws, and either need to disable beam sync, or cut back on 
> the animation. You can use Quartz Debug to find out, and control the beam 
> sync feature.
> 
> Did you also try QuartzGL? It didn't work correctly in Tiger, and it's off by 
> default in Leopard & Snow Leopard, but it ought to work on most Macs. Again, 
> you can experiment with this using Quartz Debug.
> 
> Nick Zitzmann
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Nick Zitzmann]

On Feb 23, 2010, at 4:35 PM, Joel May wrote:

> Thanks for the info about drawing in a different thread.  I won't waste my 
> time and sanity.  I guess I need to figure out how to speed up the drawing 
> instead and keep it in the main thread.

How often does your app flush its changes? If it's more than 30 f/s, then 
you're wasting redraws, and either need to disable beam sync, or cut back on 
the animation. You can use Quartz Debug to find out, and control the beam sync 
feature.

Did you also try QuartzGL? It didn't work correctly in Tiger, and it's off by 
default in Leopard & Snow Leopard, but it ought to work on most Macs. Again, 
you can experiment with this using Quartz Debug.

Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Joel May]

OK.  I'm agreeing with you about not doing bad stuff.

Thanks for the info about drawing in a different thread.  I won't waste my time 
and sanity.  I guess I need to figure out how to speed up the drawing instead 
and keep it in the main thread.

I've switched from QuickDraw to Quarz, and performance has actually gotten 
worse.  After reading this post:

http://www.kaourantin.net/2010/02/core-animation.html

I'm thinking about switching the quartz code to CoreAnimation.  I need to blit 
an offscreen bitmap to the screen.  I'm hoping CoreAnimation will do it faster. 
 I haven't looked at the CoreAnimation API yet.

Thanks,
Joel


On Feb 23, 2010, at 4:49 PM, Nick Zitzmann wrote:

> 
> On Feb 23, 2010, at 3:30 PM, Joel May wrote:
> 
>> 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?  
> 
> Two words: Schrödinger's Cat. :) You won't know until you observe.
> 
>> Does the OS actually honor this request?  
> 
> Yes, you can change a running thread's priority using NSThread. I've never 
> had to change a main thread's priority, though.
> 
>> Can I take the drawRect requests and pass the rectangle to the lower thread 
>> and update the view there?  
> 
> No; in all classes except for NSButton and NSProgressIndicator (and any other 
> classes that use the old, private heart-beat API), you do threaded drawing by 
> turning on concurrent drawing in the view. You can only do this in Snow 
> Leopard & later, and it's not a good idea to try this unless you know for a 
> fact that it supports thread-safe drawing. IKImageBrowserView, for example, 
> will freeze if you turn on concurrent drawing.
> 
> Also, it's been my experience that concurrent drawing is currently useless if 
> you need to flush multiple updates to multiple views at once, because 
> concurrent drawing changes flush immediately instead of at the same time as 
> everything else, which could look a little strange. I have a bug open on 
> this...
> 
>> Is this crazy?
> 
> Maybe.
> 
>> 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?
> 
> The results are most likely undefined and could change between OS releases or 
> even individual trials. I wouldn't try if the header says it's not 
> thread-safe.
> 
> Nick Zitzmann
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Joel May]

Oh yeah.  I've actually already done that with some other cocoa calls.  I 
forgot.  I have deploy sdk = 10.4 and base sdk = 10.5 (will change to 10.6). 
Thanks,
Joel


On Feb 23, 2010, at 4:30 PM, Jean-Daniel Dupas wrote:

> You don't have to build a separate version. Just test for method availability 
> at runtime:
> 
> if ([NSEvent respondsToSelector:@selector(pressedMouseButtons)])
>   return [NSEvent pressedMouseButtons];
> else
>   // do it the old way.
> 
> 
> 
> Le 23 févr. 2010 à 23:18, Joel May a écrit :
> 
>> Hey Eric,
>> 
>> This is very helpful.  I'll take a look at [NSEvent pressedMouseButtons].  I 
>> still have to support tiger and leopard, but I'll build a separate snow 
>> leopard version and #ifdef that call in there.
>> 
>> I've had the heebie-jeebies about including the Carbon framework in my 
>> application.  But I'm cool with it now.
>> 
>> Thanks,
>> Joel
>> 
>> 
>> 
>> On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:
>> 
>>> 
>>> On Feb 22, 2010, at 11:53 AM, 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.  
>>> 
>>> GetButton() [by which I think you actually mean Button()] - the Cocoa 
>>> equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
>>> GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics 
>>> equivalent (but could be wrong!). It's perfectly fine to continue using 
>>> GetKeys().
>>> 
 Am I safe using these api's. Are we supposed to not use them?
>>> 
>>> You are safe using these APIs. They are still supported. We recommend that 
>>> you use Cocoa equivalents when available - so you could use +[NSEvent 
>>> pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
>>> 
 Will they go away in 10.7?
>>> 
>>> No, because that would break many existing applications, and we place a 
>>> high priority on not breaking existing applications.
>>> 
 Why do I read everywhere that carbon is dead and high level toolkit is 
 dead?  
>>> 
>>> Because many people are misinformed. Apple no longer recommends Carbon for 
>>> new application development - Cocoa is recommended for all new development 
>>> - but Carbon is not being removed from the OS either, because that would 
>>> break existing applications. The High Level Toolbox APIs will continue to 
>>> be supported for 32-bit apps and some parts of HLTB will also still be 
>>> supported for 64-bit in cases where there is no other 64-bit equivalent.
>>> 
 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.
>>> 
>>> You'd have to ask Apple Developer Relations about that. I'm just a grunt 
>>> engineer. :)
>>> 
>>> -eric
>>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
>> 
>> This email sent to devli...@shadowlab.org
> 
> -- Jean-Daniel
> 
> 
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Nick Zitzmann]

On Feb 23, 2010, at 3:30 PM, Joel May wrote:

> 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?  

Two words: Schrödinger's Cat. :) You won't know until you observe.

> Does the OS actually honor this request?  

Yes, you can change a running thread's priority using NSThread. I've never had 
to change a main thread's priority, though.

> Can I take the drawRect requests and pass the rectangle to the lower thread 
> and update the view there?  

No; in all classes except for NSButton and NSProgressIndicator (and any other 
classes that use the old, private heart-beat API), you do threaded drawing by 
turning on concurrent drawing in the view. You can only do this in Snow Leopard 
& later, and it's not a good idea to try this unless you know for a fact that 
it supports thread-safe drawing. IKImageBrowserView, for example, will freeze 
if you turn on concurrent drawing.

Also, it's been my experience that concurrent drawing is currently useless if 
you need to flush multiple updates to multiple views at once, because 
concurrent drawing changes flush immediately instead of at the same time as 
everything else, which could look a little strange. I have a bug open on this...

> Is this crazy?

Maybe.

> 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?

The results are most likely undefined and could change between OS releases or 
even individual trials. I wouldn't try if the header says it's not thread-safe.

Nick Zitzmann


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Joel May]

Hey Ken,

I never actually used that preference before.  Dumb me.  I'm adding leopard 
docs now.

Thanks,
Joel



On Feb 23, 2010, at 6:08 AM, Ken Thomases wrote:

> On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:
> 
>> On Feb 22, 2010, at 12:53 PM, Joel May wrote:
>> 
>>> 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.
> 
> For what it's worth, there's a "legacy reference library" link at the current 
> reference library: https://developer.apple.com/legacy/mac/library/
> 
> Also, in Xcode, you can add the Leopard docset.  Preferences > Documentation 
> > click Get next to Mac OS X Leopard Core Library.  That still has the 
> documentation for a number of APIs like FSFindFolder.  There's also a legacy 
> docset in there, but I haven't bothered to look at what it contains.
> 
> Regards,
> Ken
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Jean-Daniel Dupas]

You don't have to build a separate version. Just test for method availability 
at runtime:

if ([NSEvent respondsToSelector:@selector(pressedMouseButtons)])
return [NSEvent pressedMouseButtons];
else
// do it the old way.



Le 23 févr. 2010 à 23:18, Joel May a écrit :

> Hey Eric,
> 
> This is very helpful.  I'll take a look at [NSEvent pressedMouseButtons].  I 
> still have to support tiger and leopard, but I'll build a separate snow 
> leopard version and #ifdef that call in there.
> 
> I've had the heebie-jeebies about including the Carbon framework in my 
> application.  But I'm cool with it now.
> 
> Thanks,
> Joel
> 
> 
> 
> On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:
> 
>> 
>> On Feb 22, 2010, at 11:53 AM, 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.  
>> 
>> GetButton() [by which I think you actually mean Button()] - the Cocoa 
>> equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
>> GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics 
>> equivalent (but could be wrong!). It's perfectly fine to continue using 
>> GetKeys().
>> 
>>> Am I safe using these api's. Are we supposed to not use them?
>> 
>> You are safe using these APIs. They are still supported. We recommend that 
>> you use Cocoa equivalents when available - so you could use +[NSEvent 
>> pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
>> 
>>> Will they go away in 10.7?
>> 
>> No, because that would break many existing applications, and we place a high 
>> priority on not breaking existing applications.
>> 
>>> Why do I read everywhere that carbon is dead and high level toolkit is 
>>> dead?  
>> 
>> Because many people are misinformed. Apple no longer recommends Carbon for 
>> new application development - Cocoa is recommended for all new development - 
>> but Carbon is not being removed from the OS either, because that would break 
>> existing applications. The High Level Toolbox APIs will continue to be 
>> supported for 32-bit apps and some parts of HLTB will also still be 
>> supported for 64-bit in cases where there is no other 64-bit equivalent.
>> 
>>> 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.
>> 
>> You'd have to ask Apple Developer Relations about that. I'm just a grunt 
>> engineer. :)
>> 
>> -eric
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
> 
> This email sent to devli...@shadowlab.org

-- Jean-Daniel




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Joel May]

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
> 
> 
> 
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Joel May]

Hey Eric,

This is very helpful.  I'll take a look at [NSEvent pressedMouseButtons].  I 
still have to support tiger and leopard, but I'll build a separate snow leopard 
version and #ifdef that call in there.

I've had the heebie-jeebies about including the Carbon framework in my 
application.  But I'm cool with it now.

Thanks,
Joel



On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:

> 
> On Feb 22, 2010, at 11:53 AM, 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.  
> 
> GetButton() [by which I think you actually mean Button()] - the Cocoa 
> equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
> GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics 
> equivalent (but could be wrong!). It's perfectly fine to continue using 
> GetKeys().
> 
>> Am I safe using these api's. Are we supposed to not use them?
> 
> You are safe using these APIs. They are still supported. We recommend that 
> you use Cocoa equivalents when available - so you could use +[NSEvent 
> pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
> 
>> Will they go away in 10.7?
> 
> No, because that would break many existing applications, and we place a high 
> priority on not breaking existing applications.
> 
>> Why do I read everywhere that carbon is dead and high level toolkit is dead? 
>>  
> 
> Because many people are misinformed. Apple no longer recommends Carbon for 
> new application development - Cocoa is recommended for all new development - 
> but Carbon is not being removed from the OS either, because that would break 
> existing applications. The High Level Toolbox APIs will continue to be 
> supported for 32-bit apps and some parts of HLTB will also still be supported 
> for 64-bit in cases where there is no other 64-bit equivalent.
> 
>> 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.
> 
> You'd have to ask Apple Developer Relations about that. I'm just a grunt 
> engineer. :)
> 
> -eric
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Kyle Sluder]

On Tue, Feb 23, 2010 at 7:23 AM, Sean McBride  wrote:
> Even that's an exaggeration.  The HIThemeDraw... APIs are not
> deprecated, and they are the only way to draw bits of standard UI
> elements.  For example, I have a custom NSCell that uses HIThemeDrawTrack
> () to draw a customised slider.  There's no other way to do that.

Though we should probably file enhancement requests to get CoreUI
pushed up to public API...

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Sean McBride]

On 2/23/10 12:19 AM, Nick Zitzmann said:

>> 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 (...)

Even that's an exaggeration.  The HIThemeDraw... APIs are not
deprecated, and they are the only way to draw bits of standard UI
elements.  For example, I have a custom NSCell that uses HIThemeDrawTrack
() to draw a customised slider.  There's no other way to do that.

That said, stay away from any deprecated Carbon API.

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Jean-Daniel Dupas]

Le 23 févr. 2010 à 13:08, Ken Thomases a écrit :

> On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:
> 
>> On Feb 22, 2010, at 12:53 PM, Joel May wrote:
>> 
>>> 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.
> 
> For what it's worth, there's a "legacy reference library" link at the current 
> reference library: https://developer.apple.com/legacy/mac/library/
> 
> Also, in Xcode, you can add the Leopard docset.  Preferences > Documentation 
> > click Get next to Mac OS X Leopard Core Library.  That still has the 
> documentation for a number of APIs like FSFindFolder.  There's also a legacy 
> docset in there, but I haven't bothered to look at what it contains.
> 

It contains everything you need when you search for "legacy" API (FSFindFolder 
is in it for instance). I'm often using it as I'm working with the C QuickTime 
API and some Carbon API too.

 If you download it, you don't need the Leopard docset. 


-- Jean-Daniel




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Ken Thomases]

On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote:

> On Feb 22, 2010, at 12:53 PM, Joel May wrote:
> 
>> 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.

For what it's worth, there's a "legacy reference library" link at the current 
reference library: https://developer.apple.com/legacy/mac/library/

Also, in Xcode, you can add the Leopard docset.  Preferences > Documentation > 
click Get next to Mac OS X Leopard Core Library.  That still has the 
documentation for a number of APIs like FSFindFolder.  There's also a legacy 
docset in there, but I haven't bothered to look at what it contains.

Regards,
Ken

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Nick Zitzmann]

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




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Seth Willits]

On Feb 22, 2010, at 11:53 AM, Joel May wrote:

> I'm porting an application from Carbon to Cocoa.

Good idea. 



> 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.

Some of the APIs are deprecated, some are not. If something is not deprecated 
and in 64-bit, then feel free to use it.

The guide you mention sums it up:

"Most APIs in Mac OS X v10.5 are available to both 32-bit and 64-bit 
applications, but some APIs commonly used by Carbon applications are not. In 
particular, the APIs used to implement a Carbon user interface are generally 
available only to 32-bit applications. If you want to create a 64-bit 
application for Mac OS X, you need to use Cocoa to implement its user 
interface."

APIs like the Carbon Event Manager are still available, but the 
interface-related APIs such as Window Manager, Menu Manager, etc are not.



> I'd like to use the cocoa equivalents of GetButton() and GetKeys() but I 
> can't find them.  

There are no equivalents of those functions in Cocoa. Even games use 
mouseDown/keyDown etc, and you know there's no one more whiny and picky than a 
gamer. :-)

If you're really having problems with delayed events, then your main thread 
must be very busy. How big of a delay are you seeing? Perhaps you should 
optimize whatever is eating all of that time (put it on a separate thread)?



> If High Level Toolkit is ok, then why doesn't it appear in the docs.

Apple is annoyingly aggressive about purging "old" documentation, and its 
search capability on its website is horrible. At any rate, assuming you mean 
the Human Interface Toolkit, the general answer to why some of it is "OK" and 
some isn't is because some of it is deprecated and some of it isn't. It's as 
simple as that. HIT is composed of several APIs. Select methods in select APIs 
are available. It's not always "all or nothing" inclusion.



I hope that helps,


--
Seth Willits



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: High Level Toolkit -- is it obsolete or not?

[Eric Schlegel]

On Feb 22, 2010, at 11:53 AM, 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. 
>  

GetButton() [by which I think you actually mean Button()] - the Cocoa 
equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics 
equivalent (but could be wrong!). It's perfectly fine to continue using 
GetKeys().

> Am I safe using these api's. Are we supposed to not use them?

You are safe using these APIs. They are still supported. We recommend that you 
use Cocoa equivalents when available - so you could use +[NSEvent 
pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.

>  Will they go away in 10.7?

No, because that would break many existing applications, and we place a high 
priority on not breaking existing applications.

>  Why do I read everywhere that carbon is dead and high level toolkit is dead? 
>  

Because many people are misinformed. Apple no longer recommends Carbon for new 
application development - Cocoa is recommended for all new development - but 
Carbon is not being removed from the OS either, because that would break 
existing applications. The High Level Toolbox APIs will continue to be 
supported for 32-bit apps and some parts of HLTB will also still be supported 
for 64-bit in cases where there is no other 64-bit equivalent.

> 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.

You'd have to ask Apple Developer Relations about that. I'm just a grunt 
engineer. :)

-eric

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com