From ozone at algorithm.com.au Wed Jul 2 22:03:25 2008
From: ozone at algorithm.com.au (=?ISO-8859-1?Q?Andr=E9_Pang?=)
Date: Wed Jul 2 22:48:09 2008
Subject: Cocoa methods that return CF objects
Message-ID: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
Hi, two questions:
1. What's the generally accepted memory management convention for
Cocoa methods that return Core Foundation objects? I presumed that it
would have been "the caller is responsible for sending CFRelease() to
the returned object", but then I saw that some methods, e.g. -
[NSBitmapImageRep CGImage], return autoreleased CF objects. That
leads me to the second question...
2. Is it _always_ fine to send -autorelease to Core Foundation
objects? Writing [(id)coreFoundationObject autorelease] to avoid
compiler warnings feels kinda weird, though admittedly the new-skool
[NSMakeCollectable(coreFoundationObject) autorelease] looks a little
better...
Thanks,
Andre.
--
% Andre Pang : trust.in.love.to.save
From cmhofman at gmail.com Thu Jul 3 02:11:11 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Thu Jul 3 02:11:34 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
Message-ID:
On 3 Jul 2008, at 7:03 AM, Andr? Pang wrote:
> Hi, two questions:
>
> 1. What's the generally accepted memory management convention for
> Cocoa methods that return Core Foundation objects? I presumed that
> it would have been "the caller is responsible for sending
> CFRelease() to the returned object", but then I saw that some
> methods, e.g. -[NSBitmapImageRep CGImage], return autoreleased CF
> objects. That leads me to the second question...
>
The rules are the same as for Cocoa objects, . It's not relevant what object is returned, but rather the Cocoa
method that is used to get it.
> 2. Is it _always_ fine to send -autorelease to Core Foundation
> objects? Writing [(id)coreFoundationObject autorelease] to avoid
> compiler warnings feels kinda weird, though admittedly the new-skool
> [NSMakeCollectable(coreFoundationObject) autorelease] looks a little
> better...
>
> Thanks,
> Andre.
>
>
> --
> % Andre Pang : trust.in.love.to.save
AFAIK, CFType (= CoreFoundation "root class") is toll free bridged to
NSObject. This means that you can send any valid NSObject method to a
CoreFoundation object, and v.v. pass any Cocoa object to a
CoreFoundation function that accepts a CFType (s.a. CFRetain(),
CFRelease()).
However I am not 100%, and I've never been able to find this in the
docs. I believe this is an omission in the docs. E.g. I am 100% sure
that I can use generic CFType methods s.a. CFRetain/CFRelease with a
Cocoa object (and that's used a lot in Cocoa+Carbon code, including
lots of sample code), while I've never seen an explicit reference in
the docs to this fact. I think I will file a documentation bug. And I
would appreciate if someone who does know could pass a reference to
relevant documentation, or confirm my statement.
Christiaan
From bill at cheeseman.name Thu Jul 3 04:48:20 2008
From: bill at cheeseman.name (Bill Cheeseman)
Date: Thu Jul 3 05:01:19 2008
Subject: [ANN] PreFab Event Taps Testbench 1.1
Message-ID:
I've posted PreFab Event Taps Testbench 1.1 at
. This is a free utility for
software developers. Use it to explore what your applications can do with
Quartz event taps. In addition, you should find it to be a useful tool to
test drivers for hardware input devices such as trackballs and tablets, to
test virtual software input devices including assistive applications for
persons with disabilities, and to test remote control software.
These are the new features that I like the most:
1. It now includes complete support for tablet proximity and pointer events.
(I've only tested this on a high-end professional Wacom tablet. I'd be
interested in feedback from users of Wacom consumer tablets, and non-Wacom
tablets.)
2. It includes a new Current Event window where you can examine the most
recent event in real time in an easy-to-read layout showing all available
event information at a glance. The old Events window is still available as
the Event History window, showing a configurable number of recent events in
text format.
3. It allows users to make Event Taps Testbench a trusted accessibility
process without turning on global access for assistive devices. I'll add
this feature to UI Browser and UI Actions in due course.
4. It enables users to turn on global access for assistive devices, if
desired, without opening System Preferences.
5. There were altogether too many bugs in 1.0. I think I've fixed all of
them. ;)
The most important new feature is that the PFEventTaps framework is now
installed separately as a shared framework in /Library/Frameworks, where it
can be used (under license) by any developer. The framework wraps Apple's
Quartz event taps C API, including many transparent workarounds for Apple
bugs. It's an Objective-C 2.0 universal binary supporting 32-bit and 64-bit
architectures and retain/release and garbage collection memory management.
It enables a Cocoa application to respond to both local and remote user
input events from a keyboard, mouse, scroll wheel or tablet using Cocoa
delegate methods Will Post Event, Should Post Event, May Post Modified Event
For Event, and Did Post Event, regardless of the application at which the
events were targeted. It also helps you build remote control applications,
assistive applications for persons with disabilities, and other tools that
modify user input events on the fly before they are posted to their target.
I'm using this as an opportunity to try an experiment in commercialization
of Objective-C frameworks. The PFEventTaps framework may be licensed without
charge for distribution with a free software product. A flat one-time
per-product license fee of $250 is required to distribute the framework with
a product for which you request or require payment, such as donationware,
shareware and commercial software. Source code is available for a separate
fee. Different terms apply to large or established commercial software
developers.
I'll be interested in hearing what people think of this approach. It seems
to me that developers of Mac frameworks and similar code should be able to
share in any income that they help other developers to generate. As the Mac
platform grows, I believe this will encourage more and better software for
all of us. At the same time, I think developers of free software should be
able to use my frameworks without charge, to the same end. So the framework
is installed, with headers, in /Library/Frameworks, where everybody can see
it. The headers include copyright notices and information about how to
obtain a distribution license, and the distribution license form is embedded
in the framework and available for download from our Web site.
--
Bill Cheeseman - bill@cheeseman.name
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
From jim.correia at pobox.com Thu Jul 3 06:30:48 2008
From: jim.correia at pobox.com (Jim Correia)
Date: Thu Jul 3 06:30:54 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
Message-ID: <2FCA7C52-C967-4A8B-B500-EFE345F5DEA8@pobox.com>
On Jul 3, 2008, at 5:11 AM, Christiaan Hofman wrote:
> AFAIK, CFType (= CoreFoundation "root class") is toll free bridged
> to NSObject. This means that you can send any valid NSObject method
> to a CoreFoundation object, and v.v. pass any Cocoa object to a
> CoreFoundation function that accepts a CFType (s.a. CFRetain(),
> CFRelease()).
>
> However I am not 100%, and I've never been able to find this in the
> docs. I believe this is an omission in the docs. E.g. I am 100% sure
> that I can use generic CFType methods s.a. CFRetain/CFRelease with a
> Cocoa object (and that's used a lot in Cocoa+Carbon code, including
> lots of sample code), while I've never seen an explicit reference in
> the docs to this fact. I think I will file a documentation bug. And
> I would appreciate if someone who does know could pass a reference
> to relevant documentation, or confirm my statement.
When building an Obj-C application with classic memory management, -
retain/CFRetain are equivalent, as are -release/-autorelease/CFRelease.
In a GC application, they are not equivalent. (In fact, -release/-
autorelease are no-ops, while CFRelease is not.)
Jim
From mmalc-lists at mmalc.com Thu Jul 3 23:44:57 2008
From: mmalc-lists at mmalc.com (mmalc Crawford)
Date: Thu Jul 3 23:45:05 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
Message-ID: <85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
On Jul 3, 2008, at 2:11 AM, Christiaan Hofman wrote:
> AFAIK, CFType (= CoreFoundation "root class") is toll free bridged
> to NSObject. This means that you can send any valid NSObject method
> to a CoreFoundation object, and v.v. pass any Cocoa object to a
> CoreFoundation function that accepts a CFType (s.a. CFRetain(),
> CFRelease()).
> However I am not 100%, and I've never been able to find this in the
> docs. I believe this is an omission in the docs.
>
mmalc
From cmhofman at gmail.com Fri Jul 4 02:09:03 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Fri Jul 4 02:09:18 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
Message-ID: <2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
On 4 Jul 2008, at 8:44 AM, mmalc Crawford wrote:
>
> On Jul 3, 2008, at 2:11 AM, Christiaan Hofman wrote:
>
>> AFAIK, CFType (= CoreFoundation "root class") is toll free bridged
>> to NSObject. This means that you can send any valid NSObject method
>> to a CoreFoundation object, and v.v. pass any Cocoa object to a
>> CoreFoundation function that accepts a CFType (s.a. CFRetain(),
>> CFRelease()).
>> However I am not 100%, and I've never been able to find this in the
>> docs. I believe this is an omission in the docs.
>>
> >
>
> mmalc
Yes, but also this document does tell me the relevant bit of what I'd
want to know. I am pretty sure it's incomplete, as I'm sure any
function accepting CFType (and that's more than CFRelease and
CFRetain) can accept also any Cocoa object (NSObject). Otherwise the
standard collection callbacks would break and, if I'm not mistaken,
those are used by Cocoa's collection classes.
Christiaan
From gotow at stclairsoft.com Fri Jul 4 08:12:57 2008
From: gotow at stclairsoft.com (Jon Gotow)
Date: Fri Jul 4 08:19:46 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
Message-ID:
At 11:09 AM +0200 7/4/08, Christiaan Hofman wrote:
>Yes, but also this document does tell me the relevant bit of what
>I'd want to know. I am pretty sure it's incomplete, as I'm sure any
>function accepting CFType (and that's more than CFRelease and
>CFRetain) can accept also any Cocoa object (NSObject). Otherwise the
>standard collection callbacks would break and, if I'm not mistaken,
>those are used by Cocoa's collection classes.
In general, most of these classes are "toll-free bridged" - ie. they
may be substituted for one another, and release/CFRelease are
interchangeable (except when GC is on). There are a few, however,
that aren't interchangeable, such as NSBundle/CFBundle (see
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSBundle_Class/Reference/Reference.html).
I believe the basics, such as retain/release will still work on the
*Bundle classes, but I don't assume I can truly treat a CFType as an
NSObject unless the docs say that they're "toll-free bridged", in
Apple's terminology.
- Jon
--
________________________________________________________________________
Jon Gotow gotow@stclairsoft.com
St. Clair Software http://www.stclairsoft.com/
Fax (540)552-5898 ftp://ftp.stclairsoft.com/
From cmhofman at gmail.com Fri Jul 4 09:42:35 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Fri Jul 4 09:42:42 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
Message-ID: <1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
On 4 Jul 2008, at 5:12 PM, Jon Gotow wrote:
> At 11:09 AM +0200 7/4/08, Christiaan Hofman wrote:
>> Yes, but also this document does tell me the relevant bit of what
>> I'd want to know. I am pretty sure it's incomplete, as I'm sure any
>> function accepting CFType (and that's more than CFRelease and
>> CFRetain) can accept also any Cocoa object (NSObject). Otherwise
>> the standard collection callbacks would break and, if I'm not
>> mistaken, those are used by Cocoa's collection classes.
>
> In general, most of these classes are "toll-free bridged" - ie. they
> may be substituted for one another, and release/CFRelease are
> interchangeable (except when GC is on). There are a few, however,
> that aren't interchangeable, such as NSBundle/CFBundle (see http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSBundle_Class/Reference/Reference.html)
> . I believe the basics, such as retain/release will still work on
> the *Bundle classes, but I don't assume I can truly treat a CFType
> as an NSObject unless the docs say that they're "toll-free bridged",
> in Apple's terminology.
>
> - Jon
I think you misunderstand. I'm not asking which specific *subclasses*
are toll-free bridged, that's indeed answered in the link provided by
mmalc. My quetsion is whether a *generic* NSObject is toll-free
bridged to a *generic* CFType. In other words: can I pass *any* Cocoa
object (NSObject or subclass instance) to a CF function accepting a
CFType and v.v. can I send Cocoa instance methods defined for NSObject
to *any* CFTypeRef? I already know for sure that I can apply CFRelease/
CFRetain on any Cocoa object. But what about the rest of CFType
declared in ?And what about everything in and ?
Christiaan
From garywade at desisoftsystems.com Fri Jul 4 10:01:08 2008
From: garywade at desisoftsystems.com (Gary L. Wade)
Date: Fri Jul 4 10:13:44 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au> <85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com> <2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
Message-ID: <486E5754.3050304@desisoftsystems.com>
I seriously doubt such a scheme would always work, but there's a number
of CFType-based APIs in, I believe, CFBase.h, that should provide some
basic information about a general-purpose CFType-object, so try those on
your NSObject objects and see what they do. In the meantime, I'd
suggest writing a bug for documentation clarification for this
particular need. And, if you do find the generic toll-free bridging
works, make sure you test every new version of Mac OS X, especially the
seeds that come out. Only you can say if this would be worth it, but
that's what you'll have to do to prevent any surprises showing up on
your customers' doorsteps.
Christiaan Hofman wrote:
>
> On 4 Jul 2008, at 5:12 PM, Jon Gotow wrote:
>
>> At 11:09 AM +0200 7/4/08, Christiaan Hofman wrote:
>>> Yes, but also this document does tell me the relevant bit of what I'd
>>> want to know. I am pretty sure it's incomplete, as I'm sure any
>>> function accepting CFType (and that's more than CFRelease and
>>> CFRetain) can accept also any Cocoa object (NSObject). Otherwise the
>>> standard collection callbacks would break and, if I'm not mistaken,
>>> those are used by Cocoa's collection classes.
>>
>> In general, most of these classes are "toll-free bridged" - ie. they
>> may be substituted for one another, and release/CFRelease are
>> interchangeable (except when GC is on). There are a few, however,
>> that aren't interchangeable, such as NSBundle/CFBundle (see
>> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSBundle_Class/Reference/Reference.html).
>> I believe the basics, such as retain/release will still work on the
>> *Bundle classes, but I don't assume I can truly treat a CFType as an
>> NSObject unless the docs say that they're "toll-free bridged", in
>> Apple's terminology.
>>
>> - Jon
>
> I think you misunderstand. I'm not asking which specific *subclasses*
> are toll-free bridged, that's indeed answered in the link provided by
> mmalc. My quetsion is whether a *generic* NSObject is toll-free bridged
> to a *generic* CFType. In other words: can I pass *any* Cocoa object
> (NSObject or subclass instance) to a CF function accepting a CFType and
> v.v. can I send Cocoa instance methods defined for NSObject to *any*
> CFTypeRef? I already know for sure that I can apply CFRelease/CFRetain
> on any Cocoa object. But what about the rest of CFType declared in
> ?And
> what about everything in
>
> and
> ?
>
>
> Christiaan
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
From cmhofman at gmail.com Fri Jul 4 11:01:05 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Fri Jul 4 11:01:31 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <486E5754.3050304@desisoftsystems.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au> <85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com> <2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
Message-ID: <84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
I know, and my question is hals indeed about these functions in
CFBase.h (they're what I linked to). I am pretty sure that testing
will tell you it will work. But what I'm asking for is confirmation
from the docs. It's pretty important if you want to use CF callbacks
in collections (which in fact is used in sample code, it';s just not
documented that this sample code would even be valid). And I already
filed a bug report.
Christiaan
On 4 Jul 2008, at 7:01 PM, Gary L. Wade wrote:
> I seriously doubt such a scheme would always work,
Why? I'd say the opposite, as the existing docs, mailing lists, and
sample code strongly suggest it. E.g. there's sample code using CF
collections for Cocoa objects, and CF callbacks use more of CFBase.h
than just CFRelease/CFRetain (the only ones that are documented to
work AFAICS).
> but there's a number of CFType-based APIs in, I believe, CFBase.h,
> that should provide some basic information about a general-purpose
> CFType-object, so try those on your NSObject objects and see what
> they do.
Yes, that's one of the links I gave (it's described in the CFType doc).
> In the meantime, I'd suggest writing a bug for documentation
> clarification for this particular need.
I did already do that.
> And, if you do find the generic toll-free bridging works, make sure
> you test every new version of Mac OS X, especially the seeds that
> come out. Only you can say if this would be worth it, but that's
> what you'll have to do to prevent any surprises showing up on your
> customers' doorsteps.
And I shouldn't have to. I'd say it's a pretty basic and important
part of toll-free bridging. It would make CF collections pretty much
useless for use in toll-free bridging.
Christiaan
>
> Christiaan Hofman wrote:
>> On 4 Jul 2008, at 5:12 PM, Jon Gotow wrote:
>>> At 11:09 AM +0200 7/4/08, Christiaan Hofman wrote:
>>>> Yes, but also this document does tell me the relevant bit of what
>>>> I'd want to know. I am pretty sure it's incomplete, as I'm sure
>>>> any function accepting CFType (and that's more than CFRelease and
>>>> CFRetain) can accept also any Cocoa object (NSObject). Otherwise
>>>> the standard collection callbacks would break and, if I'm not
>>>> mistaken, those are used by Cocoa's collection classes.
>>>
>>> In general, most of these classes are "toll-free bridged" - ie.
>>> they may be substituted for one another, and release/CFRelease are
>>> interchangeable (except when GC is on). There are a few, however,
>>> that aren't interchangeable, such as NSBundle/CFBundle (see http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSBundle_Class/Reference/Reference.html)
>>> . I believe the basics, such as retain/release will still work on
>>> the *Bundle classes, but I don't assume I can truly treat a CFType
>>> as an NSObject unless the docs say that they're "toll-free
>>> bridged", in Apple's terminology.
>>>
>>> - Jon
>> I think you misunderstand. I'm not asking which specific
>> *subclasses* are toll-free bridged, that's indeed answered in the
>> link provided by mmalc. My quetsion is whether a *generic* NSObject
>> is toll-free bridged to a *generic* CFType. In other words: can I
>> pass *any* Cocoa object (NSObject or subclass instance) to a CF
>> function accepting a CFType and v.v. can I send Cocoa instance
>> methods defined for NSObject to *any* CFTypeRef? I already know for
>> sure that I can apply CFRelease/CFRetain on any Cocoa object. But
>> what about the rest of CFType declared in > >?And what about everything in > > and > >? Christiaan
>> _______________________________________________
>> MacOSX-dev mailing list
>> MacOSX-dev@omnigroup.com
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
From garywade at desisoftsystems.com Fri Jul 4 17:26:17 2008
From: garywade at desisoftsystems.com (Gary L. Wade)
Date: Fri Jul 4 17:26:26 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au> <85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com> <2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
Message-ID: <486EBFA9.6010704@desisoftsystems.com>
Christiaan Hofman wrote:
>> And, if you do find the generic toll-free bridging works, make sure
>> you test every new version of Mac OS X, especially the seeds that come
>> out. Only you can say if this would be worth it, but that's what
>> you'll have to do to prevent any surprises showing up on your
>> customers' doorsteps.
>
> And I shouldn't have to. I'd say it's a pretty basic and important part
> of toll-free bridging. It would make CF collections pretty much useless
> for use in toll-free bridging.
>
Without confirmation from Apple, you're pretty much stuck with empirical
testing whether you believe you should or should not have to do it.
What value is returned when you call CFGetTypeID for an object
subclassed from NSObject or even an object of type NSObject?
From jjalon at gmail.com Fri Jul 4 17:49:37 2008
From: jjalon at gmail.com (Julien Jalon)
Date: Fri Jul 4 17:49:50 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <486EBFA9.6010704@desisoftsystems.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
Message-ID: <019A69FA-1498-4C28-9652-C7CC0392817C@gmail.com>
Any CFType instance is toll free bridged to an instance of some
NSObject subclass and any NSObject or subclass instance can be used as
a CFType instance. This is part of Core Foundation design concepts.
While the documentation could be clearer on this subject.
--
Julien
Sent from my iPhone
Le 5 juil. 08 ? 02:26, "Gary L. Wade" a
?crit :
> Christiaan Hofman wrote:
>>> And, if you do find the generic toll-free bridging works, make
>>> sure you test every new version of Mac OS X, especially the seeds
>>> that come out. Only you can say if this would be worth it, but
>>> that's what you'll have to do to prevent any surprises showing up
>>> on your customers' doorsteps.
>> And I shouldn't have to. I'd say it's a pretty basic and important
>> part of toll-free bridging. It would make CF collections pretty
>> much useless for use in toll-free bridging.
>
> Without confirmation from Apple, you're pretty much stuck with
> empirical testing whether you believe you should or should not have
> to do it. What value is returned when you call CFGetTypeID for an
> object subclassed from NSObject or even an object of type NSObject?
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
From jim.correia at pobox.com Fri Jul 4 19:15:27 2008
From: jim.correia at pobox.com (Jim Correia)
Date: Fri Jul 4 19:15:30 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <486EBFA9.6010704@desisoftsystems.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
Message-ID:
On Jul 4, 2008, at 8:26 PM, Gary L. Wade wrote:
> Without confirmation from Apple, you're pretty much stuck with
> empirical testing whether you believe you should or should not have
> to do it. What value is returned when you call CFGetTypeID for an
> object subclassed from NSObject or even an object of type NSObject?
Well, there are actually 2 questions to ask/answer here.
What is the documented behavior/contract? (This we can rely upon from
release to release of the OS/frameworks.)
What does CF do?
When the documentation is lacking (is it, in this case?), the answer
can be found by reading the CF Lite source code. CFGetTypeID will
return whatever is returned by -_cfTypeID when the input is an Obj-C
object.
Jim
From gotow at stclairsoft.com Fri Jul 4 19:44:25 2008
From: gotow at stclairsoft.com (Jon Gotow)
Date: Fri Jul 4 19:44:36 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <019A69FA-1498-4C28-9652-C7CC0392817C@gmail.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
<019A69FA-1498-4C28-9652-C7CC0392817C@gmail.com>
Message-ID:
At 2:49 AM +0200 7/5/08, Julien Jalon wrote:
>Any CFType instance is toll free bridged to an instance of some
>NSObject subclass and any NSObject or subclass instance can be used
>as a CFType instance. This is part of Core Foundation design
>concepts. While the documentation could be clearer on this subject.
This applies to _any_ CFType instance? I've been "playing it safe"
by only assuming that objects explicitly documented as being
toll-free bridged were safe to treat as both a CFType or NSObject
subclass (that was what I was saying in my first reply - if a class
is documented as being toll-free bridged, the implication is that
-release and CFRelease will both work without issue, but I don't
assume that if there are distinct, non-miscible implementations, like
with NSBundle and CFBundle).
- Jon
--
________________________________________________________________________
Jon Gotow gotow@stclairsoft.com
St. Clair Software http://www.stclairsoft.com/
Fax (540)552-5898 ftp://ftp.stclairsoft.com/
From jjalon at gmail.com Sat Jul 5 02:35:42 2008
From: jjalon at gmail.com (Julien Jalon)
Date: Sat Jul 5 02:35:54 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
<019A69FA-1498-4C28-9652-C7CC0392817C@gmail.com>
Message-ID: <8BA8099B-0D24-4928-8744-7B9BB5EECCBC@gmail.com>
Yes: *any*
They might not be bridged to a "well known" class but any CFType
instance can be used as an ObjC object (and more precisely as an
NSObject subclass)
Implementation-wise, try [(id)aCFobject class] on whatever instance
you have. You will get some NSCFXXX (NSCFString, NSCFArray, etc.)
class and if there is no obvious bridged class (eg. CFBundle,
CGContext and most of CG objects, QLThumbnailRequest, etc.), you will
get the very generic NSCFType class (of course, all of this is an
implementation detail you should not have to care about)
--
Julien
Sent from my iPhone
Le 5 juil. 08 ? 04:44, Jon Gotow a ?crit :
> At 2:49 AM +0200 7/5/08, Julien Jalon wrote:
>> Any CFType instance is toll free bridged to an instance of some
>> NSObject subclass and any NSObject or subclass instance can be used
>> as a CFType instance. This is part of Core Foundation design
>> concepts. While the documentation could be clearer on this subject.
>
> This applies to _any_ CFType instance? I've been "playing it safe"
> by only assuming that objects explicitly documented as being toll-
> free bridged were safe to treat as both a CFType or NSObject
> subclass (that was what I was saying in my first reply - if a class
> is documented as being toll-free bridged, the implication is that -
> release and CFRelease will both work without issue, but I don't
> assume that if there are distinct, non-miscible implementations,
> like with NSBundle and CFBundle).
>
> - Jon
>
> --
> ________________________________________________________________________
> Jon Gotow gotow@stclairsoft.com
> St. Clair Software http://www.stclairsoft.com/
> Fax (540)552-5898 ftp://ftp.stclairsoft.com/
From kusterer at gmail.com Sat Jul 5 02:37:42 2008
From: kusterer at gmail.com (Uli Kusterer)
Date: Sat Jul 5 02:37:52 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
Message-ID:
On 04.07.2008, at 17:12, Jon Gotow wrote:
> developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/
> NSBundle_Class/Reference/Reference.html). I believe the basics, such
> as retain/release will still work on the *Bundle classes, but I
> don't assume I can truly treat a CFType as an NSObject unless the
> docs say that they're "toll-free bridged", in Apple's terminology.
For what it's worth, CFType and NSObject aren't in the same
hierarchy. You'll see that if you define a category on NSObject; it
won't fire for a CFType (which actually shows up as NSCFType in
NSClassFromString). So I guess they're more like parallel class
hierarchies (kinda like NSProxy is not an NSObject), but I guess one
could say that CFType implements the NSObject protocol.
At least I think so. I remember painstakingly swizzling so I can log
retain/release calls, only to find that CFRetain() on a CFArrayRef
didn't trigger my override, and I think the above was the reason I
determined back then.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
From cmhofman at gmail.com Sat Jul 5 02:44:23 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Sat Jul 5 02:44:31 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
Message-ID: <70E15F0D-6554-42B6-84ED-ADFFE834E4ED@gmail.com>
On 5 Jul 2008, at 4:15 AM, Jim Correia wrote:
> On Jul 4, 2008, at 8:26 PM, Gary L. Wade wrote:
>
>> Without confirmation from Apple, you're pretty much stuck with
>> empirical testing whether you believe you should or should not have
>> to do it. What value is returned when you call CFGetTypeID for an
>> object subclassed from NSObject or even an object of type NSObject?
>
> Well, there are actually 2 questions to ask/answer here.
>
> What is the documented behavior/contract? (This we can rely upon
> from release to release of the OS/frameworks.)
>
Well, I think that's clear: according to the documentation, you can
only use toll-free bridging for explicitly toll-free bridged
subclasses, not for generic CFTypes/NSObjects. The only exception I
know is CFRetain and CFRelease, which are (now) mentioned as being
safe for any Cocoa object. However this is (explicitly) mentioned in
the wrong place and in the wrong context (the GC docs rather the Cocoa
+Carbon docs, and in an example). Moreover, I believe this is only
included in the Leopard docs, I had never seen it mentioned in the
earlier docs. So can we rely on it on Tiger? I have seen several
mailing list messages from Apple engineers to certify that they were
safe way back. Moreover, as I said, the fact that they are is pretty
essential for Cocoa+Carbon.
> What does CF do?
>
> When the documentation is lacking (is it, in this case?),
For sure. It certainly is not there in the place where it should be. I
asked if it was somewhere else, and until now nobody has provided a
link that affirms the minimum of what I'm pretty sure is supported
(based on mailing lists). Also, it's an important fact that should be
mentioned *explicitly* in the Carbon-Cocoa guide, not mentioned in
passing in an example (and more fully). So, yes, the documentation is
lacking.
> the answer can be found by reading the CF Lite source code.
> CFGetTypeID will return whatever is returned by -_cfTypeID when the
> input is an Obj-C object.
>
> Jim
In fact it returns 1 for me for any Cocoa object that's not explicitly
toll-free bridged.
Christiaan
From cmhofman at gmail.com Sat Jul 5 02:55:12 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Sat Jul 5 02:55:26 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
Message-ID: <0B18541C-E91A-490D-94A4-1A1505CCAED5@gmail.com>
On 5 Jul 2008, at 11:37 AM, Uli Kusterer wrote:
> On 04.07.2008, at 17:12, Jon Gotow wrote:
>> developer.apple.com/documentation/Cocoa/Reference/Foundation/
>> Classes/NSBundle_Class/Reference/Reference.html). I believe the
>> basics, such as retain/release will still work on the *Bundle
>> classes, but I don't assume I can truly treat a CFType as an
>> NSObject unless the docs say that they're "toll-free bridged", in
>> Apple's terminology.
>
>
> For what it's worth, CFType and NSObject aren't in the same
> hierarchy. You'll see that if you define a category on NSObject; it
> won't fire for a CFType (which actually shows up as NSCFType in
> NSClassFromString). So I guess they're more like parallel class
> hierarchies (kinda like NSProxy is not an NSObject), but I guess one
> could say that CFType implements the NSObject protocol.
>
> At least I think so. I remember painstakingly swizzling so I can log
> retain/release calls, only to find that CFRetain() on a CFArrayRef
> didn't trigger my override, and I think the above was the reason I
> determined back then.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
Thanks, Uli, that's useful information. At least we now know my
hypothesis was partially incorrect. So I guess the current hypothesis
is that CFType is toll-free bridged to id (as far as one can
call that toll-free bridging, but it should be clear what I mean). I
think that would make perfect sense. To test it, I tried
[(id)CFBundleGetMainBundle() conformsToProtocol:@protocol(NSObject)],
and it returns YES, so that seems to confirm this hypothesis.
Christiaan
From jjalon at gmail.com Sat Jul 5 03:31:56 2008
From: jjalon at gmail.com (Julien Jalon)
Date: Sat Jul 5 03:31:59 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
Message-ID:
Yes, they are in the same hierarchy. NSCFType is a subclass of NSObject.
retain method is commonly overriden by many subclasses and NSCFType does
that (to call CFRetain/CFRelease) which explains why your attempt to catch
retain/release at NSObject level here will fail for many of its subclasses.
Also, CFRetain/CFRelease on any "pure" CFType objects won't trigger any objc
method dispatch.
You can try yourself:
CFBundleRef bundle = CFBundleGetMainBundle();
NSLog(@"%@'s superclass is %@", [(id)bundle class], [(id)bundle
superclass]);
outputs:
*2008-07-05 12:27:32.643 CFBridging[16171:10b] NSCFType's superclass is
NSObject*
You can also break on CFRetain and try: [(id)bundle retain] or break
on objc_msgSend and try CFRetain :-)
--
Julien
On Sat, Jul 5, 2008 at 11:37 AM, Uli Kusterer wrote:
> On 04.07.2008, at 17:12, Jon Gotow wrote:
>
>> developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSBundle_Class/Reference/Reference.html).
>> I believe the basics, such as retain/release will still work on the *Bundle
>> classes, but I don't assume I can truly treat a CFType as an NSObject unless
>> the docs say that they're "toll-free bridged", in Apple's terminology.
>>
>
>
> For what it's worth, CFType and NSObject aren't in the same hierarchy.
> You'll see that if you define a category on NSObject; it won't fire for a
> CFType (which actually shows up as NSCFType in NSClassFromString). So I
> guess they're more like parallel class hierarchies (kinda like NSProxy is
> not an NSObject), but I guess one could say that CFType implements the
> NSObject protocol.
>
> At least I think so. I remember painstakingly swizzling so I can log
> retain/release calls, only to find that CFRetain() on a CFArrayRef didn't
> trigger my override, and I think the above was the reason I determined back
> then.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
>
>
>
>
>
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
From jim.correia at pobox.com Sat Jul 5 07:19:16 2008
From: jim.correia at pobox.com (Jim Correia)
Date: Sat Jul 5 07:19:20 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
Message-ID: <59F6370E-1023-4D78-8B31-E2EE36B102A9@pobox.com>
On Jul 5, 2008, at 5:37 AM, Uli Kusterer wrote:
> At least I think so. I remember painstakingly swizzling so I can log
> retain/release calls, only to find that CFRetain() on a CFArrayRef
> didn't trigger my override, and I think the above was the reason I
> determined back then.
In its current implementation, CFRetain will send -retain to the
object if the argument is an obj-c object, otherwise do the CF retain
count dance.
Jim
From jim.correia at pobox.com Sat Jul 5 07:19:19 2008
From: jim.correia at pobox.com (Jim Correia)
Date: Sat Jul 5 07:19:22 2008
Subject: Cocoa methods that return CF objects
In-Reply-To:
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
<019A69FA-1498-4C28-9652-C7CC0392817C@gmail.com>
Message-ID: <8143921F-1BB0-4FE0-BE78-5288A026A97B@pobox.com>
On Jul 4, 2008, at 10:44 PM, Jon Gotow wrote:
> At 2:49 AM +0200 7/5/08, Julien Jalon wrote:
>> Any CFType instance is toll free bridged to an instance of some
>> NSObject subclass and any NSObject or subclass instance can be used
>> as a CFType instance. This is part of Core Foundation design
>> concepts. While the documentation could be clearer on this subject.
>
> This applies to _any_ CFType instance? I've been "playing it safe"
> by only assuming that objects explicitly documented as being toll-
> free bridged were safe to treat as both a CFType or NSObject
> subclass (that was what I was saying in my first reply - if a class
> is documented as being toll-free bridged, the implication is that -
> release and CFRelease will both work without issue, but I don't
> assume that if there are distinct, non-miscible implementations,
> like with NSBundle and CFBundle).
CFRetain/CFRelease *must* work correctly with any NSObject for toll-
free bridging of collections to work.
Consider you are passed an NSMutableArray to which you are going to
add objects. Is it really an NSMutableArray, or is a a
CFMutableArrayRef that someone has cast to an NSMutableArray because
of toll-free bridging? You don't know, and you shouldn't have to care;
you just add objects to it.
So the default callback block used by the implementation needs to
retain/release the objects as appropriate, and due to the above, it
needs to be able to handle both CFTypeRefs and NSObjects.
Jim
From cmhofman at gmail.com Sat Jul 5 07:53:04 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Sat Jul 5 07:53:11 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <8143921F-1BB0-4FE0-BE78-5288A026A97B@pobox.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<1CA873DB-D48D-4EED-BDC5-E36166E48F35@gmail.com>
<486E5754.3050304@desisoftsystems.com>
<84520945-A195-4C86-8BEB-F19AF615D380@gmail.com>
<486EBFA9.6010704@desisoftsystems.com>
<019A69FA-1498-4C28-9652-C7CC0392817C@gmail.com>
<8143921F-1BB0-4FE0-BE78-5288A026A97B@pobox.com>
Message-ID: <09C36AC2-ED3E-405A-84C2-793A768A1A48@gmail.com>
On 5 Jul 2008, at 4:19 PM, Jim Correia wrote:
> On Jul 4, 2008, at 10:44 PM, Jon Gotow wrote:
>
>> At 2:49 AM +0200 7/5/08, Julien Jalon wrote:
>>> Any CFType instance is toll free bridged to an instance of some
>>> NSObject subclass and any NSObject or subclass instance can be
>>> used as a CFType instance. This is part of Core Foundation design
>>> concepts. While the documentation could be clearer on this subject.
>>
>> This applies to _any_ CFType instance? I've been "playing it safe"
>> by only assuming that objects explicitly documented as being toll-
>> free bridged were safe to treat as both a CFType or NSObject
>> subclass (that was what I was saying in my first reply - if a class
>> is documented as being toll-free bridged, the implication is that -
>> release and CFRelease will both work without issue, but I don't
>> assume that if there are distinct, non-miscible implementations,
>> like with NSBundle and CFBundle).
>
> CFRetain/CFRelease *must* work correctly with any NSObject for toll-
> free bridging of collections to work.
>
Indeed, that's what I've been saying several times now, and why I
think this is not just an academic question, but an essential part of
info if you want to use Carbon+Cocoa.
> Consider you are passed an NSMutableArray to which you are going to
> add objects. Is it really an NSMutableArray, or is a a
> CFMutableArrayRef that someone
...and that someone could be Foundation in its implementation of -
[NSMutableArray init] (implementation detail, I don't really care)...
> has cast to an NSMutableArray because of toll-free bridging? You
> don't know, and you shouldn't have to care; you just add objects to
> it.
>
> So the default callback block used by the implementation needs to
> retain/release the objects as appropriate, and due to the above, it
> needs to be able to handle both CFTypeRefs and NSObjects.
>
> Jim
And IMHO that should also imply that *any* function in CFBase.h
accepts Cocoa objects, considering that the default callbacks for CF
collections use almost all of it, not just CFRetain/CFRelease (e.g.
CFHash, CFEqual, CFCopyDescription, ..., and it doesn't make any sense
to draw the line somewhere in between).
And v.v., if Cocoa correctly identifies a generic CFTypeRef as an
NSCFType and NSCFType is a subclass of NSObject (which both are true
according to simple tests, at least on 10.5.x but probably on all of
10.x.x), then CFType and NSObject are indeed toll-free bridged. QED.
Christiaan
From kusterer at gmail.com Sat Jul 5 09:03:27 2008
From: kusterer at gmail.com (Uli Kusterer)
Date: Sat Jul 5 09:03:34 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <59F6370E-1023-4D78-8B31-E2EE36B102A9@pobox.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<59F6370E-1023-4D78-8B31-E2EE36B102A9@pobox.com>
Message-ID: <721B029D-3E21-48BA-B2CA-3E878B785B6B@gmail.com>
On 05.07.2008, at 16:19, Jim Correia wrote:
> On Jul 5, 2008, at 5:37 AM, Uli Kusterer wrote:
>
>> At least I think so. I remember painstakingly swizzling so I can
>> log retain/release calls, only to find that CFRetain() on a
>> CFArrayRef didn't trigger my override, and I think the above was
>> the reason I determined back then.
>
> In its current implementation, CFRetain will send -retain to the
> object if the argument is an obj-c object, otherwise do the CF
> retain count dance.
OK, I stand corrected, that matches with observed behaviour. Trouble
is just, I really wanted to override retain/release, breakpoints
weren't really enough... and I wasn't able to find a way to tell
CFRetain/CFRelease to call me when they do their work. Tried lots of
things, custom allocators etc., but there seems to be some information
missing in the retain callbacks and similar.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
From mattejames at gmail.com Sat Jul 5 19:30:28 2008
From: mattejames at gmail.com (Matt James)
Date: Sat Jul 5 19:30:31 2008
Subject: Hotkeys
Message-ID: <27cd4a440807051930n54d81405n3e3327baedbe2695@mail.gmail.com>
Hi Everyone,
I was hoping someone could shed some light on hotkeys for me. I've done
some Googling and found a great
articleon
hotkey registration using Carbon's RegisterEventHotKey(). However, a
few
questions remain.
1) Given the age of the article, I didn't know if there was a more
attractive, non-Carbon way to get this effect using more recent APIs (note:
I'm cool with Leopard-only code).
2) It is mentioned in the article that modifier keys are required, however,
the Apple documentationsuggests
that this only applied to 10.2 and prior -- you can pass in "0" for
your second parameter into RegisterEventHotKey() without causing an error.
3) Can a mouse event participate in being a hotkey? Ie, can my hotkey be:
"mouse-down+cmd+T" or something like that?
Thanks for any help!
--
Matt James
http://www.macyenta.com
From cmhofman at gmail.com Sun Jul 6 06:51:02 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Sun Jul 6 06:51:09 2008
Subject: GC and CF collections
Message-ID:
The recent thread on GC and CF raised some questions for me about
using GC with CF collections. I sometimes use GC collections because I
want to support custom callbacks (e.g. non-retained, or I don't want
to copy keys, or I want to store non-object pointers). Now I wonder if
my use is correct in GC. The docs say that it is "supported
correctly", but quite frankly I don't know what is considered correct.
One situation is if I just want to retain the objects, in which case I
usually make use of the standard kCFType...Callbacks. However those
use CFRetain/CFRelease AFAIK. So it seems to me that they would
basically make the objects I store uncollectable. Is that correct? If
so, should I use some custom callbacks using -retain/-release? Or are
the CFType...Callbacks now able to enable proper garbage collection?
Another use is a static CFMutableDictionaryRef to track simulated
ivars. This means that I register pairs of an object and a simulated
ivar, using the object as key and the simulated ivar as value. The
keyCallbacks for the dictionary are trivial, because otherwise the
object used as key will never be deallocated (and this is the main
reason I'm using CFMutableDictionary). This works great with managed
memory.
However I wonder now if this can work with GC. Is the garbage
collector able to clean up the object, even if it is referenced as a
key by the CFMytableDictionary? Also, should I explicitly need to add
the __strong keyword when I declare the static CFMutableDictionaryRef,
or is that always implied for collections?
thanks,
Christiaan
From jim.correia at pobox.com Sun Jul 6 07:23:41 2008
From: jim.correia at pobox.com (Jim Correia)
Date: Sun Jul 6 07:23:45 2008
Subject: GC and CF collections
In-Reply-To:
References:
Message-ID: <02EB5531-D019-46B2-8885-B7611D2EB23C@pobox.com>
On Jul 6, 2008, at 9:51 AM, Christiaan Hofman wrote:
> One situation is if I just want to retain the objects, in which case
> I usually make use of the standard kCFType...Callbacks. However
> those use CFRetain/CFRelease AFAIK. So it seems to me that they
> would basically make the objects I store uncollectable. Is that
> correct? If so, should I use some custom callbacks using -retain/-
> release? Or are the CFType...Callbacks now able to enable proper
> garbage collection?
As long as the collection has a reference to the object it is not
collectable. This is the usual use case (where you'd use the standard
callbacks) and works correctly. If you have more complex needs, you
need a different solution.
> Another use is a static CFMutableDictionaryRef to track simulated
> ivars. This means that I register pairs of an object and a simulated
> ivar, using the object as key and the simulated ivar as value. The
> keyCallbacks for the dictionary are trivial, because otherwise the
> object used as key will never be deallocated (and this is the main
> reason I'm using CFMutableDictionary). This works great with managed
> memory.
>
> However I wonder now if this can work with GC. Is the garbage
> collector able to clean up the object, even if it is referenced as a
> key by the CFMytableDictionary?
You should consider migrating your special needs code which uses CF
collections with custom callbacks to NSMapTable and NSPointerArray in
your GC-savvy code. It has options for strong or weak objects or keys,
and does the correct thing with respect to GC and write barriers.
Jim
From cmhofman at gmail.com Sun Jul 6 12:33:45 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Sun Jul 6 12:33:54 2008
Subject: GC and CF collections
In-Reply-To: <02EB5531-D019-46B2-8885-B7611D2EB23C@pobox.com>
References:
<02EB5531-D019-46B2-8885-B7611D2EB23C@pobox.com>
Message-ID: <19DFBA8C-34F8-4E5F-9C13-1A6A13BAB322@gmail.com>
On 6 Jul 2008, at 4:23 PM, Jim Correia wrote:
> On Jul 6, 2008, at 9:51 AM, Christiaan Hofman wrote:
>
>> One situation is if I just want to retain the objects, in which
>> case I usually make use of the standard kCFType...Callbacks.
>> However those use CFRetain/CFRelease AFAIK. So it seems to me that
>> they would basically make the objects I store uncollectable. Is
>> that correct? If so, should I use some custom callbacks using -
>> retain/-release? Or are the CFType...Callbacks now able to enable
>> proper garbage collection?
>
> As long as the collection has a reference to the object it is not
> collectable.
How can this be true, considering that NS collections are implemented
as CF collections?
> This is the usual use case (where you'd use the standard callbacks)
> and works correctly. If you have more complex needs, you need a
> different solution.
So does this imply that NS collections definitely don't use
kCFType...Callbacks behind the scene? And can I avoid it by using
custom callbacks? Or does this apply to *any* callbacks?
It doesn't really make sense to me.
>
>> Another use is a static CFMutableDictionaryRef to track simulated
>> ivars. This means that I register pairs of an object and a
>> simulated ivar, using the object as key and the simulated ivar as
>> value. The keyCallbacks for the dictionary are trivial, because
>> otherwise the object used as key will never be deallocated (and
>> this is the main reason I'm using CFMutableDictionary). This works
>> great with managed memory.
>>
>> However I wonder now if this can work with GC. Is the garbage
>> collector able to clean up the object, even if it is referenced as
>> a key by the CFMytableDictionary?
>
> You should consider migrating your special needs code which uses CF
> collections with custom callbacks to NSMapTable and NSPointerArray
> in your GC-savvy code. It has options for strong or weak objects or
> keys, and does the correct thing with respect to GC and write
> barriers.
>
> Jim
But that's Leopard only. What if I want to allow the same code to
build for Tiger as well (using different build settings)?
Christiaan
From gweston at mac.com Sun Jul 6 13:14:43 2008
From: gweston at mac.com (Gregory Weston)
Date: Sun Jul 6 13:14:49 2008
Subject: Hotkeys
In-Reply-To: <20080706185804.48A6E21A729@forums.omnigroup.com>
References: <20080706185804.48A6E21A729@forums.omnigroup.com>
Message-ID: <288FFF83-00BC-4C67-955A-A398DAB142B3@mac.com>
Matt James wrote:
> 1) Given the age of the article, I didn't know if there was a more
> attractive, non-Carbon way to get this effect using more recent
> APIs (note:
> I'm cool with Leopard-only code).
Nope. Still Carbon. Unless someone's written a wrapper but it's
really not difficult enough a task that I've bothered to look.
> 2) It is mentioned in the article that modifier keys are required,
> however,
> the Apple documentation Carbon/Reference/Carbon_Event_Manager_Ref/Reference/
> reference.html#//apple_ref/c/func/RegisterEventHotKey>suggests
> that this only applied to 10.2 and prior -- you can pass in "0" for
> your second parameter into RegisterEventHotKey() without causing an
> error.
Yep. To my chagrin the *second* time I used this technique, I ended
up (briefly) eating every press of the 'a' key.
> 3) Can a mouse event participate in being a hotkey? Ie, can my
> hotkey be:
> "mouse-down+cmd+T" or something like that?
Not really. You can fake it by establishing a cmd-t handler and then
looking for the mouse to also be down before actually processing the
key, but I wouldn't rely on that technique.
From sstevenson at mac.com Sun Jul 6 13:35:36 2008
From: sstevenson at mac.com (Scott Stevenson)
Date: Sun Jul 6 13:36:26 2008
Subject: GC and CF collections
In-Reply-To: <19DFBA8C-34F8-4E5F-9C13-1A6A13BAB322@gmail.com>
References:
<02EB5531-D019-46B2-8885-B7611D2EB23C@pobox.com>
<19DFBA8C-34F8-4E5F-9C13-1A6A13BAB322@gmail.com>
Message-ID:
On Jul 6, 2008, at 12:33 PM, Christiaan Hofman wrote:
> But that's Leopard only. What if I want to allow the same code to
> build for Tiger as well (using different build settings)?
If you need to support both Tiger and Leopard, you might as well avoid
garbage collection entirely. Once you can move to Leopard exclusively,
you can use NSMapTable for weak references.
Just saying this because I think it simplifies things. There's
probably not much benefit in supporting both CG and non-CG builds
unless your project is a framework.
- Scott
From cmhofman at gmail.com Sun Jul 6 13:46:17 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Sun Jul 6 13:46:23 2008
Subject: GC and CF collections
In-Reply-To:
References:
<02EB5531-D019-46B2-8885-B7611D2EB23C@pobox.com>
<19DFBA8C-34F8-4E5F-9C13-1A6A13BAB322@gmail.com>
Message-ID: <751FDCD0-3164-4EF3-9438-6ECAA35C6CED@gmail.com>
On 6 Jul 2008, at 10:35 PM, Scott Stevenson wrote:
>
> On Jul 6, 2008, at 12:33 PM, Christiaan Hofman wrote:
>
>> But that's Leopard only. What if I want to allow the same code to
>> build for Tiger as well (using different build settings)?
>
> If you need to support both Tiger and Leopard, you might as well
> avoid garbage collection entirely. Once you can move to Leopard
> exclusively, you can use NSMapTable for weak references.
>
> Just saying this because I think it simplifies things. There's
> probably not much benefit in supporting both CG and non-CG builds
> unless your project is a framework.
>
> - Scott
And that's exactly what I'm thinking of.
Christiaan
From mattejames at gmail.com Sun Jul 6 17:04:15 2008
From: mattejames at gmail.com (Matt James)
Date: Sun Jul 6 17:04:29 2008
Subject: Hotkeys
In-Reply-To: <288FFF83-00BC-4C67-955A-A398DAB142B3@mac.com>
References: <20080706185804.48A6E21A729@forums.omnigroup.com>
<288FFF83-00BC-4C67-955A-A398DAB142B3@mac.com>
Message-ID: <852DD1CA-637B-416D-9961-6F85E8AC2187@gmail.com>
Gregory Weston wrote:
> Matt James wrote:
>
>> 2) It is mentioned in the article that modifier keys are required,
>> however,
>> the Apple documentation> >suggests
>> that this only applied to 10.2 and prior -- you can pass in "0" for
>> your second parameter into RegisterEventHotKey() without causing an
>> error.
>
> Yep. To my chagrin the *second* time I used this technique, I ended
> up (briefly) eating every press of the 'a' key.
Interesting, because in the article it had said that Apple
specifically wanted to avoid the ability to make key-loggers which is
why they required a modifier key. I'm happy to know that this isn't
the case (if only for the fact that it makes my job easier).
>> 3) Can a mouse event participate in being a hotkey? Ie, can my
>> hotkey be:
>> "mouse-down+cmd+T" or something like that?
>
> Not really. You can fake it by establishing a cmd-t handler and then
> looking for the mouse to also be down before actually processing the
> key, but I wouldn't rely on that technique.
Why wouldn't you recommend doing that? Is efficiency the only concern?
Thanks for your help!
-
Matt James
http://www.macyenta.com
From mattejames at gmail.com Sun Jul 6 17:23:11 2008
From: mattejames at gmail.com (Matt James)
Date: Sun Jul 6 17:23:14 2008
Subject: Hotkeys
In-Reply-To: <9F1963B7-C537-4703-9A14-9D5BC25241F5@mac.com>
References: <20080706185804.48A6E21A729@forums.omnigroup.com>
<288FFF83-00BC-4C67-955A-A398DAB142B3@mac.com>
<852DD1CA-637B-416D-9961-6F85E8AC2187@gmail.com>
<9F1963B7-C537-4703-9A14-9D5BC25241F5@mac.com>
Message-ID: <27cd4a440807061723j114bbc4fg5b235a899ad82bd1@mail.gmail.com>
On Sun, Jul 6, 2008 at 8:18 PM, Gregory Weston wrote:
> On Jul 6, 2008, at 8:04 PM, Matt James wrote:
>
> 3) Can a mouse event participate in being a hotkey? Ie, can my hotkey be:
>>>> "mouse-down+cmd+T" or something like that?
>>>>
>>>
>>> Not really. You can fake it by establishing a cmd-t handler and then
>>> looking for the mouse to also be down before actually processing the key,
>>> but I wouldn't rely on that technique.
>>>
>>
>> Why wouldn't you recommend doing that? Is efficiency the only concern?
>>
>
> I wouldn't rely on it because it's not reliable. As far as I know there's
> no way to identify that the mouse *was down* when the other elements of the
> combination were pressed. Only that it's down right now. So you have to hope
> that your code gets invoked quickly enough that the user hasn't released the
> button yet. And it *probably* will. But you're going to frustrate your users
> on the rare times that it doesn't; they'll start considering your software
> unreliable and will start looking for alternatives.
>
I see. Yeah, that makes total sense. Crappy that it doesn't work though.
:(
--
Matt James
http://www.macyenta.com
From cmhofman at gmail.com Mon Jul 7 03:11:30 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Mon Jul 7 03:11:46 2008
Subject: Cocoa methods that return CF objects
In-Reply-To: <721B029D-3E21-48BA-B2CA-3E878B785B6B@gmail.com>
References: <6C43DFED-CA3C-41D4-B1B7-DC3C2DCE59DE@algorithm.com.au>
<85C42398-D4CD-4748-A608-00258DCC2C2A@mmalc.com>
<2FF743A6-D78C-4524-B71F-426E22D68439@gmail.com>
<59F6370E-1023-4D78-8B31-E2EE36B102A9@pobox.com>
<721B029D-3E21-48BA-B2CA-3E878B785B6B@gmail.com>
Message-ID: <6C3EAB15-0967-4F85-9C71-B876D47F1709@gmail.com>
On 5 Jul 2008, at 6:03 PM, Uli Kusterer wrote:
> On 05.07.2008, at 16:19, Jim Correia wrote:
>> On Jul 5, 2008, at 5:37 AM, Uli Kusterer wrote:
>>
>>> At least I think so. I remember painstakingly swizzling so I can
>>> log retain/release calls, only to find that CFRetain() on a
>>> CFArrayRef didn't trigger my override, and I think the above was
>>> the reason I determined back then.
>>
>> In its current implementation, CFRetain will send -retain to the
>> object if the argument is an obj-c object, otherwise do the CF
>> retain count dance.
>
>
> OK, I stand corrected, that matches with observed behaviour. Trouble
> is just, I really wanted to override retain/release, breakpoints
> weren't really enough... and I wasn't able to find a way to tell
> CFRetain/CFRelease to call me when they do their work. Tried lots of
> things, custom allocators etc., but there seems to be some
> information missing in the retain callbacks and similar.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
> http://www.zathras.de
I don't think there is a way to do this. When a method is overridden
without calling super, you can make any override or swizzle any method
you want in the root class, but it makes no difference. The only thing
you could do is plug into the basic method dispatch mechanism. There
was a thread on this not so long ago. However this probably may also
be ignored for toll-free bridged objects. Also note that in many cases
where you would expect CFRetain to be called, in fact it's not used,
rather the underlying memory management functions are used directly
(e.g. in standard kCFType... CF collection callbacks, as I just
discovered, as well as CFMakeCollectable()).
Christiaan
From cmhofman at gmail.com Mon Jul 7 14:17:28 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Mon Jul 7 14:17:36 2008
Subject: GC and CF collections
In-Reply-To: <751FDCD0-3164-4EF3-9438-6ECAA35C6CED@gmail.com>
References:
<02EB5531-D019-46B2-8885-B7611D2EB23C@pobox.com>
<19DFBA8C-34F8-4E5F-9C13-1A6A13BAB322@gmail.com>
<751FDCD0-3164-4EF3-9438-6ECAA35C6CED@gmail.com>
Message-ID: <20166d560807071417w6ddcb955pd7ba745903337efd@mail.gmail.com>
I've decided to do different things depending on compiler settings and
NSAppKitVersionNumber. In particular, use NSMapTable in a GC environment.
However I don't know how NSMapTableZeroingWeakMemory behaves in non-GC
environment. In particular: are objects automatically removed when they're
cleaned up, or does this only happen with GC?
Christiaan
On Sun, Jul 6, 2008 at 10:46 PM, Christiaan Hofman
wrote:
>
> On 6 Jul 2008, at 10:35 PM, Scott Stevenson wrote:
>
>
>> On Jul 6, 2008, at 12:33 PM, Christiaan Hofman wrote:
>>
>> But that's Leopard only. What if I want to allow the same code to build
>>> for Tiger as well (using different build settings)?
>>>
>>
>> If you need to support both Tiger and Leopard, you might as well avoid
>> garbage collection entirely. Once you can move to Leopard exclusively, you
>> can use NSMapTable for weak references.
>>
>> Just saying this because I think it simplifies things. There's probably
>> not much benefit in supporting both CG and non-CG builds unless your project
>> is a framework.
>>
>> - Scott
>>
>
> And that's exactly what I'm thinking of.
>
> Christiaan
>
>
From cmhofman at gmail.com Tue Jul 8 02:24:13 2008
From: cmhofman at gmail.com (Christiaan Hofman)
Date: Tue Jul 8 02:24:20 2008
Subject: GC and malloced NSData
Message-ID: <3D82D97C-78A9-40DD-ABB0-8FB083D99CDD@gmail.com>
I've got another question about GC support. The docs say that stuff in
the malloc zone is not the garbage collectable. However, objects like
NSData and NSString have initializers to take over possession of
malloced bytes like -initWithDataNoCopy:length:, and obj-c objects
generally are collectable. So it would seem to me very well possible
that those obj-c objects should be able to clean up the data in -
finalize, no matter where it is. So now I wonder if code like below is
GC safe. I could not find anything in the docs either way.
char *bytes = (char *)NSZoneMalloc(NSDefaultMallocZone(), sizeof(char)
* size);
get_data_using_some_c_lib_function(name, buffer, size);
NSData *data = [NSData dataWithBytesNoCopy:buffer length:size];
Thanks,
Christiaan
From brianarthur at nc.rr.com Thu Jul 10 08:59:04 2008
From: brianarthur at nc.rr.com (Anthony B Arthur)
Date: Thu Jul 10 09:24:07 2008
Subject: App Store submission
Message-ID:
Can anyone send me the link that explains the process for submitting
iPhone software for review. I was reading the docs on how to create
a digital signature and it referenced something called a Program
Portal, but I see nothing like that at the dev center site. I hope I
am not violating NDA here, this is not about the SDK, just looking
for some info. Any help would be great.
Thanks,
-b
From robertcerny at mac.com Thu Jul 10 10:02:13 2008
From: robertcerny at mac.com (Robert Cerny)
Date: Thu Jul 10 10:02:19 2008
Subject: App Store submission
In-Reply-To:
References:
Message-ID:
On 10.7.2008, at 17:59, Anthony B Arthur wrote:
> Can anyone send me the link that explains the process for submitting
> iPhone software for review. I was reading the docs on how to create
> a digital signature and it referenced something called a Program
> Portal, but I see nothing like that at the dev center site. I hope
> I am not violating NDA here, this is not about the SDK, just looking
> for some info. Any help would be great.
>
> Thanks,
>
> -b
Hello,
I believe submissions are closed atm.
Robert
From shawnce at gmail.com Thu Jul 10 10:04:00 2008
From: shawnce at gmail.com (Shawn Erickson)
Date: Thu Jul 10 10:04:03 2008
Subject: App Store submission
In-Reply-To:
References:
Message-ID:
On Thu, Jul 10, 2008 at 8:59 AM, Anthony B Arthur wrote:
> Can anyone send me the link that explains the process for submitting iPhone
> software for review. I was reading the docs on how to create a digital
> signature and it referenced something called a Program Portal, but I see
> nothing like that at the dev center site. I hope I am not violating NDA
> here, this is not about the SDK, just looking for some info. Any help would
> be great.
If you are in the paid iPhone developer program I believe you get the
information / access you need. If you haven't been accepted into the
paid program then you likely cannot get at that information.
-Shawn
From florent.lacheroy at alwancolor.com Fri Jul 11 02:27:27 2008
From: florent.lacheroy at alwancolor.com (Florent Lacheroy)
Date: Fri Jul 11 02:31:55 2008
Subject: Photoshop Plugin and Cocoa
Message-ID:
Hi,
I am completely new to Photoshop Plugin development.
I have already developed the core functionalities of my plugin using C+
+ but now I'd like to integrate a Cocoa interface.
Is it possible to use cocoa nib? How can I load a nib into my plugin?
Is it better if I put my existing code into cocoa class?
If someone has a skeleton of what such code should be, that would be
great.
Thank you,
Regards,
Florent.
From slittle at free.fr Fri Jul 11 07:25:20 2008
From: slittle at free.fr (Scott Little)
Date: Fri Jul 11 07:31:00 2008
Subject: Photoshop Plugin and Cocoa
In-Reply-To:
References:
Message-ID:
Florent,
Craig Hockenberry post a message about this very subject on his blog
(furbo.org). See here:
http://furbo.org/2008/07/08/plug-ins-the-cocoa-way/
Scott
--
"Planning is bad for the brain!"
Charles Fenn
--
Scott Little
slittle@free.fr
--
sadly no music right now: iTunes is Paused
On 11/07/2008, at 11:27, Florent Lacheroy wrote:
> Hi,
>
> I am completely new to Photoshop Plugin development.
> I have already developed the core functionalities of my plugin using
> C++ but now I'd like to integrate a Cocoa interface.
> Is it possible to use cocoa nib? How can I load a nib into my plugin?
> Is it better if I put my existing code into cocoa class?
>
> If someone has a skeleton of what such code should be, that would be
> great.
>
> Thank you,
>
> Regards,
>
> Florent.
>
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
From jswitte at bloomington.in.us Fri Jul 11 17:44:29 2008
From: jswitte at bloomington.in.us (Jim Witte)
Date: Fri Jul 11 17:44:38 2008
Subject: How inefficient is validateMenuItem?
Message-ID: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
I'm reading through Hillegass's Cocoa Programming and am up to the
bit about menu updating using validateMenuItem. It seems that using
validateMenuItem for something that is not likely to change EVERY
single time the menu is opened would be rather inefficient as opposed
to simply pulling the Carbon MenuRef from the NSMenu somehow, and
then using a Carbon function to disable the item. It might even be
inefficient for ANY item, no matter how often it's called, and it
also (in some circumstances) takes the 'menu item disable logic' away
from the place where the menu item is actually disabled in the code -
if that makes any sense (I do something that causes the item to have
no meaning in one place, but don't tell the system to disable it
until in the validateMenuItem, which is in a completely different
place perhaps).
Plus, since the same validateMenuItem routine is called for each
menu (and possibly more than one menu if you've set it up that way) -
if there are several items that need to be checked, it's not clear
how efficient the menu-item check code is going to be (a giganitic
switch statment on menuItemNumber of whatever.. And if @selector()
has to convert the NSString *at runtime* to a selector code.. Forget
it)
If an individual NSMenuItem could be connected to a specific
validateMenuItem routine, this might decrease the 'mutliple item
switch' overhead (although it increases code size, and if routines
are found at runtime, then..)
What are the general practices for when to use validateMenuItem
and when to just use the Carbon functions or.. are there other ways
to disable items?
Thanks,
Jim Witte
From joar at joar.com Fri Jul 11 18:01:39 2008
From: joar at joar.com (j o a r)
Date: Fri Jul 11 18:01:42 2008
Subject: How inefficient is validateMenuItem?
In-Reply-To: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
References: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
Message-ID:
On Jul 11, 2008, at 5:44 PM, Jim Witte wrote:
> I'm reading through Hillegass's Cocoa Programming and am up to the
> bit about menu updating using validateMenuItem. It seems that using
> validateMenuItem for something that is not likely to change EVERY
> single time the menu is opened would be rather inefficient as
> opposed to simply pulling the Carbon MenuRef from the NSMenu
> somehow, and then using a Carbon function to disable the item.
Don't fall into the premature optimization trap! Menu item validation
is called only very rarely (from a fast moving CPUs point of view) and
is typically not a performance problem.
> It might even be inefficient for ANY item, no matter how often it's
> called, and it also (in some circumstances) takes the 'menu item
> disable logic' away from the place where the menu item is actually
> disabled in the code - if that makes any sense (I do something that
> causes the item to have no meaning in one place, but don't tell the
> system to disable it until in the validateMenuItem, which is in a
> completely different place perhaps).
I don't agree that the Cocoa menu item validation architecture
encourages or forces you to move the knowledge of how to validate a
particular menu item away from where it conceptually belongs.
> Plus, since the same validateMenuItem routine is called for each
> menu (and possibly more than one menu if you've set it up that way)
> - if there are several items that need to be checked, it's not clear
> how efficient the menu-item check code is going to be (a giganitic
> switch statment on menuItemNumber of whatever.. And if @selector()
> has to convert the NSString *at runtime* to a selector code..
> Forget it)
>
> If an individual NSMenuItem could be connected to a specific
> validateMenuItem routine, this might decrease the 'mutliple item
> switch' overhead (although it increases code size, and if routines
> are found at runtime, then..)
Again, if you were to benchmark a bunch of actual Cocoa applications
you would find that this isn't the problem you seem to think that it
is. If there is a performance problem here, it's not in the menu item
validation architecture itself, it's in the implementation of the
validation code for one or more individual menu items - And that's
typically easy to fix.
> What are the general practices for when to use validateMenuItem and
> when to just use the Carbon functions or.. are there other ways to
> disable items?
The general practice is to just use the standard NSMenuValidation
Protocol.
j o a r
From jim.correia at pobox.com Fri Jul 11 18:09:25 2008
From: jim.correia at pobox.com (Jim Correia)
Date: Fri Jul 11 18:09:29 2008
Subject: How inefficient is validateMenuItem?
In-Reply-To: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
References: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
Message-ID: <01D5709B-DEF4-4AAE-BEBB-0EDB92B9240A@pobox.com>
On Jul 11, 2008, at 8:44 PM, Jim Witte wrote:
> I'm reading through Hillegass's Cocoa Programming and am up to the
> bit about menu updating using validateMenuItem. It seems that using
> validateMenuItem for something that is not likely to change EVERY
> single time the menu is opened would be rather inefficient as
> opposed to simply pulling the Carbon MenuRef from the NSMenu
> somehow, and then using a Carbon function to disable the item.
First of all, seems and might aren't words that you should really be
using when talking about code performance.
First, as you are writing code you should optimize for developer time
and maintainability. Then *measure* the code, and fix performance
problems that affect real world usages of your application.
If you decide that auto enabling of menu items is a performance drag
in a specific part of your app (or even globally), you can turn it off
per menu with -[NSMenu setAutoenablesItems: NO] and manually enabled/
disable the menu items. No need to resort to SPI and deal with
implementation details (that an NSMenu is backed by a MenuRef) that
you may later regret.
> It might even be inefficient for ANY item, no matter how often it's
> called, and it also (in some circumstances) takes the 'menu item
> disable logic' away from the place where the menu item is actually
> disabled in the code - if that makes any sense (I do something that
> causes the item to have no meaning in one place, but don't tell the
> system to disable it until in the validateMenuItem, which is in a
> completely different place perhaps).
I'm not sure why this is a concern. When reacting to a change in your
view code, you can always set an iVar to indicate whether or not a
particular action is enabled. Then the kit asks you "is this item
enabled?" you just reply with your cached flag.
In some ways this is cleaner than reacting to a state change and
physically disabling a menu item. Instead, your are toggling the
logical state for whether an action is allowed (whose physical
manifestation may be a menu item in today's code, but some other
widget, like a toolbar button, tomorrow.)
Jim
From varscsak at smarthealth.com Fri Jul 11 19:10:35 2008
From: varscsak at smarthealth.com (Lon Varscsak)
Date: Fri Jul 11 19:10:39 2008
Subject: How inefficient is validateMenuItem?
In-Reply-To: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
References: <1D002B65-EC07-4E72-AB2B-655006092813@bloomington.in.us>
Message-ID: <84cfc0470807111910l5213add2sf8b41921a1f2d4ed@mail.gmail.com>
I would agree with what most of the others have said as well...with one
exception. I've done this before where you have to lookup a value in a
database (server, not local storage) and while it's very fast, it can make
your menu navigation sluggish. Prefetching and/or caching eliminates those
problems.
But for the average run of the mill validateMenuItem: logic, I wouldn't
worry about it.
Lon
On Fri, Jul 11, 2008 at 5:44 PM, Jim Witte
wrote:
> I'm reading through Hillegass's Cocoa Programming and am up to the bit
> about menu updating using validateMenuItem. It seems that using
> validateMenuItem for something that is not likely to change EVERY single
> time the menu is opened would be rather inefficient as opposed to simply
> pulling the Carbon MenuRef from the NSMenu somehow, and then using a Carbon
> function to disable the item. It might even be inefficient for ANY item, no
> matter how often it's called, and it also (in some circumstances) takes the
> 'menu item disable logic' away from the place where the menu item is
> actually disabled in the code - if that makes any sense (I do something that
> causes the item to have no meaning in one place, but don't tell the system
> to disable it until in the validateMenuItem, which is in a completely
> different place perhaps).
>
> Plus, since the same validateMenuItem routine is called for each menu (and
> possibly more than one menu if you've set it up that way) - if there are
> several items that need to be checked, it's not clear how efficient the
> menu-item check code is going to be (a giganitic switch statment on
> menuItemNumber of whatever.. And if @selector() has to convert the NSString
> *at runtime* to a selector code.. Forget it)
>
> If an individual NSMenuItem could be connected to a specific
> validateMenuItem routine, this might decrease the 'mutliple item switch'
> overhead (although it increases code size, and if routines are found at
> runtime, then..)
>
> What are the general practices for when to use validateMenuItem and when
> to just use the Carbon functions or.. are there other ways to disable
> items?
>
> Thanks,
> Jim Witte
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
From applenutter at gmail.com Fri Jul 11 23:27:31 2008
From: applenutter at gmail.com (Apple Nutter)
Date: Fri Jul 11 23:27:34 2008
Subject: Anyone else noticing increased CPU utilisation after 10.5.4 for
Python programs?
Message-ID: <51d549bf0807112327s44edf048r34caec464c9145b6@mail.gmail.com>
I noticed a huge, average 70% additional CPU utilisation for all my Python
programs under OS X 10.5.4 compared with OS X 10.5.3 and am a bit alarmed.
The programs have not changed, just the OS X version.
Programs make use of OpenGL.
As a side note, they also use much more CPU and tend to perform more poorly
in relation to animation smoothness under the new Intel Core 2 Duo equipped
Macs (with the nVidia 8600 series graphics chip) than they do under the old
PowerPC G4 and ATI RV280 graphics chipset equipped Macs. Even with the same
OS X 10.5.4 installed on all systems.
Very disheartening if you work in Python.
From kusterer at gmail.com Sat Jul 12 17:59:21 2008
From: kusterer at gmail.com (Uli Kusterer)
Date: Sat Jul 12 17:59:27 2008
Subject: App Store submission
In-Reply-To:
References:
Message-ID: <5B1A814E-74A3-4C9E-A974-5F7165BAE65A@gmail.com>
On 10.07.2008, at 19:04, Shawn Erickson wrote:
> If you are in the paid iPhone developer program I believe you get the
> information / access you need. If you haven't been accepted into the
> paid program then you likely cannot get at that information.
Just one note: The link is kinda in an un-obvious place in the upper
right, if you have access.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
From sstevenson at mac.com Sat Jul 12 19:28:40 2008
From: sstevenson at mac.com (Scott Stevenson)
Date: Sat Jul 12 19:30:12 2008
Subject: Anyone else noticing increased CPU utilisation after 10.5.4 for
Python programs?
In-Reply-To: <51d549bf0807112327s44edf048r34caec464c9145b6@mail.gmail.com>
References: <51d549bf0807112327s44edf048r34caec464c9145b6@mail.gmail.com>
Message-ID: <1FA3BC20-0EC5-41C7-9CD0-D213C75CEAC6@mac.com>
On Jul 11, 2008, at 11:27 PM, Apple Nutter wrote:
> I noticed a huge, average 70% additional CPU utilisation for all my
> Python
> programs under OS X 10.5.4 compared with OS X 10.5.3 and am a bit
> alarmed.
Please file a bug if you haven't already.
https://bugreport.apple.com/
- Scott
From rob at menumachine.com Wed Jul 16 19:17:10 2008
From: rob at menumachine.com (Rob Keniger)
Date: Wed Jul 16 19:17:16 2008
Subject: DTS response time
Message-ID: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
Hi all,
To those of you who have used an Apple Developer technical support
incident:
- how long did the response take?
- was your question answered?
I sent a technical support request on June 18 and it was eventually
responded to on June 28 but only after I sent two emails (25 June and
27 June) enquiring about the status of the problem.
The response I got was not helpful and requested more info from me. I
then spent most of a day preparing a sample project to demonstrate the
problem and sent it to Apple on June 29.
On the 10th of July after receiving no response, I sent another
message ask about the status of the problem. It's a week later and
still no response.
I am willing to cut Apple a little bit of slack due to all the iPhone
hoohah but I consider their response to my technical question totally
unacceptable. An entire month has now gone by and all I have to show
for it is a request for more information. Which I provided.
DTS questions are charged at $195 and for that price I bloody well
expect decent service. Yes, I'm not happy.
If there is anybody on this list who knows somebody I should contact
to try and resolve this please let me know.
--
Rob Keniger
From rob at menumachine.com Wed Jul 16 19:41:18 2008
From: rob at menumachine.com (Rob Keniger)
Date: Wed Jul 16 19:41:23 2008
Subject: DTS response time
In-Reply-To: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
References: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
Message-ID: <9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
On 17/07/2008, at 12:17 PM, Rob Keniger wrote:
> If there is anybody on this list who knows somebody I should contact
> to try and resolve this please let me know.
Oh yeah, and if anyone at Apple is listening, my incident number is
49886723.
--
Rob Keniger
From toddransom at mac.com Thu Jul 17 05:41:00 2008
From: toddransom at mac.com (Todd Ransom)
Date: Thu Jul 17 05:41:19 2008
Subject: DTS response time
In-Reply-To: <9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
References: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
<9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
Message-ID: <7208F5FE-A029-4459-9F49-AE395C73934B@mac.com>
Hey Rob,
I have not had great results from DTS either. I have filed two
incidents. One of them was resolved, but it took longer to hear back
from them than I expected. The other was never resolved. DTS kept
stalling me, saying they needed more information, even after I gave
them a six step procedure to reproduce the problem in TextEdit.
Eventually I just filed a bug and moved on. In my case the last
incident was part of an expiring ADC membership. I wasn't going to get
any resolution from them so I let it go. But if you actually paid for
your incident you should demand your money back if they cannot resolve
the issue.
Todd Ransom
StoryMill & Montage Development
Mariner Software
On Jul 16, 2008, at 10:41 PM, Rob Keniger wrote:
>
> On 17/07/2008, at 12:17 PM, Rob Keniger wrote:
>
>> If there is anybody on this list who knows somebody I should
>> contact to try and resolve this please let me know.
>
>
> Oh yeah, and if anyone at Apple is listening, my incident number is
> 49886723.
>
> --
> Rob Keniger
>
>
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
From louisk2 at gmail.com Thu Jul 17 07:43:46 2008
From: louisk2 at gmail.com (louisk2@gmail.com)
Date: Thu Jul 17 07:49:44 2008
Subject: Extracting and Converting snd resources
Message-ID:
Hi there,
I have an old hypercard stack with around 200 'snd ' resources inside.
I'm trying to extract them all into individual aiff files (mp3 or wav
will also do). I am able to get a handle on each 'snd ' resource using
the Carbon Resource Manager in NSData or Handle, however I am stuck as
to how to convert them to another format. Quicktime doesn't support
snd and I can't find any command line utilities to do any conversion.
Any ideas?
Thanks
Louis
From aglee at mac.com Thu Jul 17 08:04:43 2008
From: aglee at mac.com (Andy Lee)
Date: Thu Jul 17 08:04:55 2008
Subject: Extracting and Converting snd resources
In-Reply-To:
References:
Message-ID: <890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
On Jul 17, 2008, at 10:43 AM, louisk2@gmail.com wrote:
> I have an old hypercard stack with around 200 'snd ' resources
> inside. I'm trying to extract them all into individual aiff files
> (mp3 or wav will also do). I am able to get a handle on each 'snd '
> resource using the Carbon Resource Manager in NSData or Handle,
> however I am stuck as to how to convert them to another format.
> Quicktime doesn't support snd and I can't find any command line
> utilities to do any conversion. Any ideas?
Have a look at AudialHub, from the makers of the excellent VisualHub:
You can drag the files into the AudialHub window, pick your output
format, and go. It's a commercial product, but in unlicensed mode it
will convert up to a minute of each file. If your sounds are mostly
beeps and boops this should be okay. I used it to convert and trim a
3-second sound file for a web site I'm working on.
--Andy
From louisk2 at gmail.com Thu Jul 17 08:31:27 2008
From: louisk2 at gmail.com (Louis Klaassen)
Date: Thu Jul 17 08:31:37 2008
Subject: Extracting and Converting snd resources
In-Reply-To: <890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
References:
<890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
Message-ID:
Unfortunately its not possible for me to convert the sounds myself and
distribute them with my app, and I also can't distribute a converter
(unless it is free) with my app. The app is a patcher/porter that will
use the users copy of an old classic game and port it to OS X, so I
can't charge for it or distribute any original game media.
So I'm looking for a code solution or perhaps a small open source or
free 3rd party tool that I can use to do the conversion - preferably
guiless.
On 18/07/2008, at 1:04:43 AM, Andy Lee wrote:
> On Jul 17, 2008, at 10:43 AM, louisk2@gmail.com wrote:
>> I have an old hypercard stack with around 200 'snd ' resources
>> inside. I'm trying to extract them all into individual aiff files
>> (mp3 or wav will also do). I am able to get a handle on each 'snd '
>> resource using the Carbon Resource Manager in NSData or Handle,
>> however I am stuck as to how to convert them to another format.
>> Quicktime doesn't support snd and I can't find any command line
>> utilities to do any conversion. Any ideas?
>
> Have a look at AudialHub, from the makers of the excellent VisualHub:
>
>
>
> You can drag the files into the AudialHub window, pick your output
> format, and go. It's a commercial product, but in unlicensed mode
> it will convert up to a minute of each file. If your sounds are
> mostly beeps and boops this should be okay. I used it to convert
> and trim a 3-second sound file for a web site I'm working on.
>
> --Andy
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
From aglee at mac.com Thu Jul 17 08:46:25 2008
From: aglee at mac.com (Andy Lee)
Date: Thu Jul 17 08:46:34 2008
Subject: Extracting and Converting snd resources
In-Reply-To:
References:
<890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
Message-ID: <7AEDD15D-9746-4EE6-888C-1A9273C1467F@mac.com>
On Jul 17, 2008, at 11:31 AM, Louis Klaassen wrote:
> Unfortunately its not possible for me to convert the sounds myself
> and distribute them with my app, and I also can't distribute a
> converter (unless it is free) with my app. The app is a patcher/
> porter that will use the users copy of an old classic game and port
> it to OS X, so I can't charge for it or distribute any original game
> media.
>
> So I'm looking for a code solution or perhaps a small open source or
> free 3rd party tool that I can use to do the conversion - preferably
> guiless.
I see. A Google for "cocoa audio format convert open source" turned
this up:
Maybe useful?
--Andy
From kw at codebykevin.com Thu Jul 17 08:38:44 2008
From: kw at codebykevin.com (Kevin Walzer)
Date: Thu Jul 17 09:04:12 2008
Subject: Extracting and Converting snd resources
In-Reply-To:
References: <890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
Message-ID: <487F6784.7000907@codebykevin.com>
Louis Klaassen wrote:
> Unfortunately its not possible for me to convert the sounds myself and
> distribute them with my app, and I also can't distribute a converter
> (unless it is free) with my app. The app is a patcher/porter that will
> use the users copy of an old classic game and port it to OS X, so I
> can't charge for it or distribute any original game media.
>
> So I'm looking for a code solution or perhaps a small open source or
> free 3rd party tool that I can use to do the conversion - preferably
> guiless.
>
>
I believe SuperCard (http://www.supercard.us) and Runtime Revolution
(http://www.runrev.com) can import old Hypercard stacks. Would that be a
better migration path for your application? It might solve the entire
resource problem for you.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
From louisk2 at gmail.com Thu Jul 17 09:16:53 2008
From: louisk2 at gmail.com (Louis Klaassen)
Date: Thu Jul 17 09:17:04 2008
Subject: Extracting and Converting snd resources
In-Reply-To: <7AEDD15D-9746-4EE6-888C-1A9273C1467F@mac.com>
References:
<890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
<7AEDD15D-9746-4EE6-888C-1A9273C1467F@mac.com>
Message-ID: <80B278A8-7BB1-4A65-823E-806384210A7F@gmail.com>
I had tried using Supercard and Revolution, however they couldn't open
the stacks. I'm also considering moving this to the iphone so i need
to write in cocoa. I looked at SOX too, but I couldn't get it to
compile for Darwin OS X nor could I find a precompiled one. Although
it handles the SUN .au audio files and its variants (.snd) it isn't
the same as the snd resource file aka System 7 Sound - which is
unfortunate.
It's funny however, I did try to get QT to handle the snd resource but
it kept mucking up. As a side note, the QT player doesn't open a legit
system 7 sound file from the Mac OS 7 system sound set - so I just
assumed it didn't support it at all! However I will look at the http://developer.apple.com/qa/qtmcc/qtmcc16.html
and see what I can come up with, after all it was achieved in
FileJuicer. Its not a major issue that it can't be in 32 bit, unless
apple decide to drop 32 bit carbon support in a future release of OS X.
Thanks
Louis
From louisk2 at gmail.com Thu Jul 17 09:53:34 2008
From: louisk2 at gmail.com (Louis Klaassen)
Date: Thu Jul 17 09:53:55 2008
Subject: Extracting and Converting snd resources
Message-ID: <436EE1C2-0440-45A9-8286-88EC07A38644@gmail.com>
Yea, I do recall there being a codec for it. So it should be possible.
This is my code so far;
1. Extracts single snd resource from resource fork
2. Writes into new file as a single snd resource in its resource fork
3. Creates FSSpec to new file.
4. Creates new QT movie from file.
Now I have to get it to save it to disk as aiff!!
- (void)extractSounds:(NSString *)file toPath:(NSString *)dir
{
NDResourceFork *mystResource = [[NDResourceFork alloc]
initForReadingAtPath:file];
NSEnumerator *soundsEmu = [mystResource resourceEnumeratorOfType:'snd
'];
id object;
int count = 0;
while ((object = [soundsEmu nextObject]))
{
count = count + 1;
NSString *name = [object name];
NSString *path = [NSString localizedStringWithFormat:@"%@/%@", dir,
name];
NSData *soundData = [mystResource dataForType:'snd ' named:name];
[[NSFileManager defaultManager] createFileAtPath:path contents:nil
attributes:nil];
[soundData writeToResourceForkFile:path type:'snd ' Id:128 name:name];
FSSpec fss;
path2fss(&fss, path);
Handle freeHandle = NewHandle(0);
Movie qtSound = System7SoundToMovie(&fss, freeHandle);
}
}
int path2fss(FSSpec *fss, char *path)
{
char buf[256];
char *p = &buf[1];
strcpy(p, path); //convert to Str255
buf[0] = strlen(p);
return(FSMakeFSSpec(0, 0, (unsigned char *)buf, fss)); //== noErr
}
Movie System7SoundToMovie(const FSSpec *fss, Handle inSoundDataH)
{
Movie theMovie = 0;
FInfo fndrInfo;
OSErr err = noErr;
FSpGetFInfo(fss, &fndrInfo);
if (kQTFileTypeSystemSevenSound == fndrInfo.fdType) {
// QuickTime can't import these files in place, but that's ok,
// we just need a new place to put this stuff
Handle hDataRef = NULL;
MovieImportComponent theImporter = 0;
long ignore;
// Create a movie.
theMovie = NewMovie(newMovieActive);
// Build the data ref. -- create a Handle-sized Handle to hold
the real Handle.
PtrToHand(&inSoundDataH, &hDataRef, sizeof(Handle));
// Set where the data will be written when added to a movie
// This reference points to the passed in handle which will be
resized
// appropriately by the call to MovieImportFile
SetMovieDefaultDataRef(theMovie, hDataRef,
HandleDataHandlerSubType);
// Do the import
OpenADefaultComponent(MovieImportType,
kQTFileTypeSystemSevenSound, &theImporter);
MovieImportFile(theImporter, fss, theMovie,
NULL, NULL, 0, NULL, 0, &ignore);
CloseComponent(theImporter);
// Don't need the dataRef anymore but don't dispose
// of the sound data handle until
// after the the movie has been disposed or very bad
// things will happen!
DisposeHandle(hDataRef);
}
return theMovie;
}
From vip at avatar.com.au Thu Jul 17 12:57:55 2008
From: vip at avatar.com.au (DavidW)
Date: Thu Jul 17 14:01:53 2008
Subject: Extracting and Converting snd resources
In-Reply-To: <80B278A8-7BB1-4A65-823E-806384210A7F@gmail.com>
References:
<890F0769-76E7-4529-9E7D-CA27C6C1C98A@mac.com>
<7AEDD15D-9746-4EE6-888C-1A9273C1467F@mac.com>
<80B278A8-7BB1-4A65-823E-806384210A7F@gmail.com>
Message-ID: <028DDBC4-944F-4B0A-B9E7-E960B9C2CBE2@avatar.com.au>
Hi Lois,
Try play
http://www.hieper.nl/html/play.html
I use it all the time and its beut. It does list snd as a format - but
I haven't tried it.
good luck!
David
On 18/07/2008, at 2:16 AM, Louis Klaassen wrote:
> I had tried using Supercard and Revolution, however they couldn't
> open the stacks. I'm also considering moving this to the iphone so i
> need to write in cocoa. I looked at SOX too, but I couldn't get it
> to compile for Darwin OS X nor could I find a precompiled one.
> Although it handles the SUN .au audio files and its variants (.snd)
> it isn't the same as the snd resource file aka System 7 Sound -
> which is unfortunate.
>
> It's funny however, I did try to get QT to handle the snd resource
> but it kept mucking up. As a side note, the QT player doesn't open a
> legit system 7 sound file from the Mac OS 7 system sound set - so I
> just assumed it didn't support it at all! However I will look at the http://developer.apple.com/qa/qtmcc/qtmcc16.html
> and see what I can come up with, after all it was achieved in
> FileJuicer. Its not a major issue that it can't be in 32 bit, unless
> apple decide to drop 32 bit carbon support in a future release of OS
> X.
>
> Thanks
> Louis
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
________________________________________________
David Worrall.
- Experimental Polymedia: www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group: creative.canberra.edu.au/scrg
From dangerwillrobinsondanger at gmail.com Thu Jul 17 17:41:00 2008
From: dangerwillrobinsondanger at gmail.com (John Joyce)
Date: Thu Jul 17 17:41:05 2008
Subject: DTS Response Time
In-Reply-To: <20080717165133.BA3CB23E071@forums.omnigroup.com>
References: <20080717165133.BA3CB23E071@forums.omnigroup.com>
Message-ID: <06833A4F-651A-46A0-B586-4EEF137CA457@gmail.com>
This is neither the appropriate way or place to handle your issue with
DTS.
If you feel you have not received what you paid for, contact them and
ask for a refund.
Don't be unprofessional and complain in this forum.
From rob at menumachine.com Thu Jul 17 19:14:23 2008
From: rob at menumachine.com (Rob Keniger)
Date: Thu Jul 17 19:14:30 2008
Subject: DTS response time
In-Reply-To: <7208F5FE-A029-4459-9F49-AE395C73934B@mac.com>
References: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
<9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
<7208F5FE-A029-4459-9F49-AE395C73934B@mac.com>
Message-ID:
On 17/07/2008, at 10:41 PM, Todd Ransom wrote:
> Hey Rob,
>
> I have not had great results from DTS either. I have filed two
> incidents. One of them was resolved, but it took longer to hear back
> from them than I expected. The other was never resolved. DTS kept
> stalling me, saying they needed more information, even after I gave
> them a six step procedure to reproduce the problem in TextEdit.
> Eventually I just filed a bug and moved on. In my case the last
> incident was part of an expiring ADC membership. I wasn't going to
> get any resolution from them so I let it go. But if you actually
> paid for your incident you should demand your money back if they
> cannot resolve the issue.
Interestingly enough, I have now had an apology from DTS and they are
crediting me the support incident and moving the question to another
engineer, which is a good outcome. It's a shame that I had to yell
about it to get noticed, though.
--
Rob Keniger
From rob at menumachine.com Thu Jul 17 19:15:48 2008
From: rob at menumachine.com (Rob Keniger)
Date: Thu Jul 17 19:15:50 2008
Subject: DTS Response Time
In-Reply-To: <06833A4F-651A-46A0-B586-4EEF137CA457@gmail.com>
References: <20080717165133.BA3CB23E071@forums.omnigroup.com>
<06833A4F-651A-46A0-B586-4EEF137CA457@gmail.com>
Message-ID: <519FAE02-46B8-463F-82D9-3E849C902ABA@menumachine.com>
On 18/07/2008, at 10:41 AM, John Joyce wrote:
> This is neither the appropriate way or place to handle your issue
> with DTS.
> If you feel you have not received what you paid for, contact them
> and ask for a refund.
> Don't be unprofessional and complain in this forum.
But that's the point - I already contacted them multiple times with no
response. What am I supposed to do when email to dts@apple.com goes
into a black hole?
--
Rob Keniger
From madbird2 at noos.fr Fri Jul 18 01:36:59 2008
From: madbird2 at noos.fr (=?ISO-8859-1?Q?J=E9r=F4me=20Seydoux?=)
Date: Fri Jul 18 02:00:45 2008
Subject: Agent process shown as "non responding" in Activity Monitor
Message-ID: <20080718083659.291444515@smtp.free.fr>
Hi,
My app has a few agent processes (with no carbon event loop nor cocoa
NSApp, but that can use some other carbon or cocoa APIs). They are
sometimes shown as "non responding" in Activity Monitor on 10.5. They
are bundled executables, with a basic Info.plist file:
CFBundleDevelopmentRegion
English
CFBundleExecutable
FTFileCrawler
CFBundleInfoDictionaryVersion
6.0
CFBundleName
FTFileCrawler
CFBundlePackageType
APPL
LSBackgroundOnly
CFBundleIdentifier
com.ctmdev.FoxTrotFileCrawler
CFBundleSignature
FTb3
Is there something I can do to avoid that?
Thanks
From shawnce at gmail.com Fri Jul 18 07:31:58 2008
From: shawnce at gmail.com (Shawn Erickson)
Date: Fri Jul 18 07:32:02 2008
Subject: DTS response time
In-Reply-To:
References: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
<9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
<7208F5FE-A029-4459-9F49-AE395C73934B@mac.com>
Message-ID:
On Thu, Jul 17, 2008 at 7:14 PM, Rob Keniger wrote:
> Interestingly enough, I have now had an apology from DTS and they are
> crediting me the support incident and moving the question to another
> engineer, which is a good outcome. It's a shame that I had to yell about it
> to get noticed, though.
You could have contacted DTS directly about it and gotten the same
response likely (they are good group of folks).
-Shawn
From epeyton at epicware.com Fri Jul 18 07:49:32 2008
From: epeyton at epicware.com (Eric Peyton)
Date: Fri Jul 18 07:49:38 2008
Subject: Agent process shown as "non responding" in Activity Monitor
In-Reply-To: <20080718083659.291444515@smtp.free.fr>
References: <20080718083659.291444515@smtp.free.fr>
Message-ID:
An app listed as "non responding" in Activity Monitor is listed that
way because it registers with the window server but at a certain point
stops servicing window server calls and callbacks. This can happen in
daemons/agents if you check in and then run your own internal run loop
for example instead of the NSApp/Carbon run loops.
You can avoid this in a few different ways.
a) Don't register with the window server. Do your agents really need
UI?
b) Service the app run loop
Eric
On Jul 18, 2008, at 3:36 AM, J?r?me Seydoux wrote:
> Hi,
>
> My app has a few agent processes (with no carbon event loop nor cocoa
> NSApp, but that can use some other carbon or cocoa APIs). They are
> sometimes shown as "non responding" in Activity Monitor on 10.5. They
> are bundled executables, with a basic Info.plist file:
> CFBundleDevelopmentRegion
> English
> CFBundleExecutable
> FTFileCrawler
> CFBundleInfoDictionaryVersion
> 6.0
> CFBundleName
> FTFileCrawler
> CFBundlePackageType
> APPL
> LSBackgroundOnly
>
> CFBundleIdentifier
> com.ctmdev.FoxTrotFileCrawler
> CFBundleSignature
> FTb3
>
> Is there something I can do to avoid that?
>
> Thanks
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
From vjl at cullasaja.com Fri Jul 18 09:18:57 2008
From: vjl at cullasaja.com (Vince LaMonica)
Date: Fri Jul 18 09:38:51 2008
Subject: DTS response time
In-Reply-To:
References: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
<9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
<7208F5FE-A029-4459-9F49-AE395C73934B@mac.com>
Message-ID:
On Fri, 18 Jul 2008, Shawn Erickson wrote:
} On Thu, Jul 17, 2008 at 7:14 PM, Rob Keniger wrote:
}
} > Interestingly enough, I have now had an apology from DTS and they are
} > crediting me the support incident and moving the question to another
} > engineer, which is a good outcome. It's a shame that I had to yell about it
} > to get noticed, though.
}
} You could have contacted DTS directly about it and gotten the same
} response likely (they are good group of folks).
As his original post stated, and his followup yesterday again stated, he
*did* contact them several times over the course of a month and heard
nothing back.
/vjl/
From geowar at apple.com Fri Jul 18 19:08:05 2008
From: geowar at apple.com (George Warner)
Date: Fri Jul 18 19:08:15 2008
Subject: DTS response time
Message-ID:
On Thu, 17 Jul 2008 12:17:10 +1000, Rob Keniger wrote:
> Hi all,
>
> To those of you who have used an Apple Developer technical support
> incident:
>
> - how long did the response take?
> - was your question answered?
>
> I sent a technical support request on June 18 and it was eventually
> responded to on June 28 but only after I sent two emails (25 June and
> 27 June) enquiring about the status of the problem.
>
> The response I got was not helpful and requested more info from me. I
> then spent most of a day preparing a sample project to demonstrate the
> problem and sent it to Apple on June 29.
>
> On the 10th of July after receiving no response, I sent another
> message ask about the status of the problem. It's a week later and
> still no response.
>
> I am willing to cut Apple a little bit of slack due to all the iPhone
> hoohah but I consider their response to my technical question totally
> unacceptable. An entire month has now gone by and all I have to show
> for it is a request for more information. Which I provided.
>
> DTS questions are charged at $195 and for that price I bloody well
> expect decent service. Yes, I'm not happy.
>
> If there is anybody on this list who knows somebody I should contact
> to try and resolve this please let me know.
Hey Rob,
We typically try to respond within the initial 48 hours. We are iSwamped
right now (most of us have 12+ incidents in our queue; this is way above
normal for us). If you can provide me with the incident # I can follow up
with the engineer (and his manager if necessary).
You can always send feedback to .
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
From kusterer at gmail.com Sat Jul 19 03:12:36 2008
From: kusterer at gmail.com (Uli Kusterer)
Date: Sat Jul 19 03:12:42 2008
Subject: Agent process shown as "non responding" in Activity Monitor
In-Reply-To: <20080718083659.291444515@smtp.free.fr>
References: <20080718083659.291444515@smtp.free.fr>
Message-ID:
On 18.07.2008, at 10:36, J?r?me Seydoux wrote:
> My app has a few agent processes (with no carbon event loop nor cocoa
> NSApp, but that can use some other carbon or cocoa APIs). They are
> sometimes shown as "non responding" in Activity Monitor on 10.5. They
> are bundled executables, with a basic Info.plist file:
> (...)Is there something I can do to avoid that?
"Not Responding" is shown when a process hasn't processed events for
a while. Maybe you could add a CFRunLoop, NSRunLoop or whatever
(calling RAEL or creating an NSApplication and running that would be
OK as well)? That will usually shut up this message.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
From kusterer at gmail.com Sat Jul 19 03:13:47 2008
From: kusterer at gmail.com (Uli Kusterer)
Date: Sat Jul 19 03:13:55 2008
Subject: DTS response time
In-Reply-To:
References: <44A3E531-0690-4780-9790-8327CBEDFE79@menumachine.com>
<9A5ACF0E-7D45-494A-A26B-3A7EF8EA7243@menumachine.com>
<7208F5FE-A029-4459-9F49-AE395C73934B@mac.com>
Message-ID: <5618BFA9-522A-4FED-9DF9-0D87E8348F49@gmail.com>
On 18.07.2008, at 16:31, Shawn Erickson wrote:
> On Thu, Jul 17, 2008 at 7:14 PM, Rob Keniger
> wrote:
>
>> Interestingly enough, I have now had an apology from DTS and they are
>> crediting me the support incident and moving the question to another
>> engineer, which is a good outcome. It's a shame that I had to yell
>> about it
>> to get noticed, though.
>
> You could have contacted DTS directly about it and gotten the same
> response likely (they are good group of folks).
How do you contact DTS directly if it's not via dts@apple.com, which
is the address he had no success with? Just curious to get a new e-
mail address should that ever happen to me.
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
From dangerwillrobinsondanger at gmail.com Sat Jul 19 13:37:44 2008
From: dangerwillrobinsondanger at gmail.com (John Joyce)
Date: Sat Jul 19 13:37:54 2008
Subject: DTS response time
In-Reply-To: <20080719185737.5F84C243809@forums.omnigroup.com>
References: <20080719185737.5F84C243809@forums.omnigroup.com>
Message-ID:
> Re: DTS response time
I think George Warner explained it well. Apple does not ignore, but
Apple does handle things as they come in. Sometimes we all just need
to be patient is all. For those not in the know, response to a recent
product has been overwhelming.
From chad+macosx at objectwerks.com Sat Jul 19 22:52:34 2008
From: chad+macosx at objectwerks.com (objectwerks inc)
Date: Sat Jul 19 22:52:38 2008
Subject: DTS response time
In-Reply-To:
References: <20080719185737.5F84C243809@forums.omnigroup.com>
Message-ID: <77A2A8B2-9F99-4C52-9D05-C34EBC2ECA7B@objectwerks.com>
On Jul 19, 2008, at 2:37 PM, John Joyce wrote:
>
>
>> Re: DTS response time
> I think George Warner explained it well. Apple does not ignore, but
> Apple does handle things as they come in. Sometimes we all just need
> to be patient is all. For those not in the know, response to a
> recent product has been overwhelming.
Yeah, but for $195 a pop, they need to do better. If they don't have
enough people, they need to get them. This is not simple tech support
you get for free or for a $50/year subscription. This is big bucks
you pay for the privilege.
Chad
>
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
From pelorus at mac.com Sat Jul 19 23:29:01 2008
From: pelorus at mac.com (Matt Johnston)
Date: Sat Jul 19 23:27:43 2008
Subject: DTS response time
In-Reply-To: <77A2A8B2-9F99-4C52-9D05-C34EBC2ECA7B@objectwerks.com>
References: <20080719185737.5F84C243809@forums.omnigroup.com>
<77A2A8B2-9F99-4C52-9D05-C34EBC2ECA7B@objectwerks.com>
Message-ID:
--
Matt Johnston - 07515352971
On 20 Jul 2008, at 06:52, objectwerks inc wrote:
>
> Yeah, but for $195 a pop, they need to do better. If they don't
> have enough people, they need to get them. This is not simple tech
> support you get for free or for a $50/year subscription. This is
> big bucks you pay for the privilege.
>>
$195 isn't really big bucks for code-level assistance. When you
consider that some questions will take 15 minutes and some will take
hours and hours, because they may have to trawl through someone elses
code. $195 is very reasonable for the latter.
Where they make the money is with people like me who've not used any
of the 'included' ones but I don't think for a second this is a big
profit spinner.
I've had my own enquiry in since 1st July regarding an issue with
provisioning. It'll get dealt with eventually and though it means I
can't deploy ( though I've paid etc) I'm philosophical about it.
From chad+macosx at objectwerks.com Sun Jul 20 09:36:15 2008
From: chad+macosx at objectwerks.com (objectwerks inc)
Date: Sun Jul 20 09:36:21 2008
Subject: DTS response time
In-Reply-To:
References: <20080719185737.5F84C243809@forums.omnigroup.com>
<77A2A8B2-9F99-4C52-9D05-C34EBC2ECA7B@objectwerks.com>
Message-ID: <2CE63F77-1824-412F-AB60-E27402D4ED76@objectwerks.com>
On Jul 20, 2008, at 12:29 AM, Matt Johnston wrote:
>
>
> --
> Matt Johnston - 07515352971
>
> On 20 Jul 2008, at 06:52, objectwerks inc wrote:
>>
>> Yeah, but for $195 a pop, they need to do better. If they don't
>> have enough people, they need to get them. This is not simple tech
>> support you get for free or for a $50/year subscription. This is
>> big bucks you pay for the privilege.
>>>
>
> $195 isn't really big bucks for code-level assistance. When you
> consider that some questions will take 15 minutes and some will take
> hours and hours, because they may have to trawl through someone
> elses code. $195 is very reasonable for the latter.
>
> Where they make the money is with people like me who've not used any
> of the 'included' ones but I don't think for a second this is a big
> profit spinner.
>
> I've had my own enquiry in since 1st July regarding an issue with
> provisioning. It'll get dealt with eventually and though it means I
> can't deploy ( though I've paid etc) I'm philosophical about it.
If a request takes hours of work, maybe you need a higher level of
support (yes they exist). I would not be happy to pay $195 and then
get pisspoor response.
Chad
From madbird2 at noos.fr Sun Jul 20 10:32:26 2008
From: madbird2 at noos.fr (=?ISO-8859-1?Q?J=E9r=F4me=20Seydoux?=)
Date: Sun Jul 20 10:32:46 2008
Subject: Agent process shown as "non responding" in Activity Monitor
In-Reply-To:
References: <20080718083659.291444515@smtp.free.fr>
Message-ID: <20080720173226.1234541378@smtp.free.fr>
Eric Peyton wrote:
>a) Don't register with the window server. Do your agents really need
>UI?
I don't know why my processes registers with the window server. Is there
a breakpoint or anything I can do to find what causes my process to
register with the window server?
>b) Service the app run loop
What do you mean?
Uli Kusterer wrote:
> "Not Responding" is shown when a process hasn't processed events for
>a while. Maybe you could add a CFRunLoop, NSRunLoop or whatever
These agent processes do not process any event; they only process data
from TCP/IP sockets.
J?r?me
From rob at menumachine.com Sun Jul 20 21:13:27 2008
From: rob at menumachine.com (Rob Keniger)
Date: Sun Jul 20 21:13:33 2008
Subject: DTS response time
In-Reply-To:
References:
Message-ID:
On 19/07/2008, at 12:08 PM, George Warner wrote:
> We typically try to respond within the initial 48 hours. We are
> iSwamped
> right now (most of us have 12+ incidents in our queue; this is way
> above
> normal for us). If you can provide me with the incident # I can
> follow up
> with the engineer (and his manager if necessary).
>
> You can always send feedback to .
Hi George,
Thanks for the response. Someone at DTS is following up my query now.
Thanks also for the feedback email address, I didn't know it existed
and had I known about it I certainly would have used it before airing
my issue here in the forum.
--
Rob Keniger
From rob at menumachine.com Sun Jul 20 21:17:53 2008
From: rob at menumachine.com (Rob Keniger)
Date: Sun Jul 20 21:17:57 2008
Subject: DTS response time
In-Reply-To: <2CE63F77-1824-412F-AB60-E27402D4ED76@objectwerks.com>
References: <20080719185737.5F84C243809@forums.omnigroup.com>
<77A2A8B2-9F99-4C52-9D05-C34EBC2ECA7B@objectwerks.com>
<2CE63F77-1824-412F-AB60-E27402D4ED76@objectwerks.com>
Message-ID: <0BC0F4AF-5F9F-4D97-BC98-5F26EA116D2D@menumachine.com>
On 21/07/2008, at 2:36 AM, objectwerks inc wrote:
> If a request takes hours of work, maybe you need a higher level of
> support (yes they exist). I would not be happy to pay $195 and then
> get pisspoor response.
I don't mind so much if an issue takes time to resolve, my problem
really is the lack of communication. I shouldn't have to sit around
wondering what's going on with my issue, and I certainly expect to get
a response when I ask about it.
Not responding to repeated requests for a status update is very poor
communication in my opinion. I certainly wouldn't treat my customers
that way.
I am fully aware that Apple must be inundated with support issues at
this time due to the iPhone launch and I took that into consideration,
but a month with no progress or status update is really disappointing.
Thankfully the problem is now being attended to.
--
Rob Keniger
From finlay.dobbie at gmail.com Mon Jul 21 01:28:27 2008
From: finlay.dobbie at gmail.com (Finlay Dobbie)
Date: Mon Jul 21 01:28:31 2008
Subject: Agent process shown as "non responding" in Activity Monitor
In-Reply-To: <20080720173226.1234541378@smtp.free.fr>
References: <20080718083659.291444515@smtp.free.fr>
<20080720173226.1234541378@smtp.free.fr>
Message-ID:
On Sun, Jul 20, 2008 at 6:32 PM, J?r?me Seydoux wrote:
> Eric Peyton wrote:
>
>>a) Don't register with the window server. Do your agents really need
>>UI?
>
> I don't know why my processes registers with the window server. Is there
> a breakpoint or anything I can do to find what causes my process to
> register with the window server?
What frameworks are you using? See
http://developer.apple.com/technotes/tn2005/tn2083.html#SECLAYEREDFRAMEWORKS
-- Finlay
From geowar at apple.com Mon Jul 21 13:05:49 2008
From: geowar at apple.com (George Warner)
Date: Mon Jul 21 13:05:57 2008
Subject: DTS response time
Message-ID:
On Sat, 19 Jul 2008 12:13:47 +0200, Uli Kusterer wrote:
> How do you contact DTS directly if it's not via dts@apple.com, which
> is the address he had no success with? Just curious to get a new e-
> mail address should that ever happen to me.
You can always send feedback to .
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
From geowar at apple.com Mon Jul 21 14:07:32 2008
From: geowar at apple.com (George Warner)
Date: Mon Jul 21 14:07:37 2008
Subject: DTS response time
Message-ID:
On Mon, 21 Jul 2008 14:17:53 +1000, Rob Keniger wrote:
> Not responding to repeated requests for a status update is very poor
> communication in my opinion. I certainly wouldn't treat my customers
> that way.
This is certainly not the experience that we strive to provide to our
developers. If you could forward me the incident # (privately) I'd like to
follow thru to find out what happened (and see what I can do to make sure
that this doesn't happen again in the future).
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
From dev at terbium.org Mon Jul 21 18:30:38 2008
From: dev at terbium.org (Michael Moore)
Date: Mon Jul 21 18:35:59 2008
Subject: Core Data Reflexive Relationship and Cocoa Bindings
Message-ID: <1216690238.11277.1264663567@webmail.messagingengine.com>
Hi all, hoping someone can help me with this problem.
I'm building an app that is basically a contact list. This is a Core
Data Document-Based app.
There is a single entity in my data model, "Person." The