On Thu, 31 Jan 2013 10:54:54 +1100, Graham Cox said:
>> - allow specific paths (com.apple.security.temporary-
>exception.files.absolute-path.read-write)
>> - allow full access (com.apple.security.temporary-
>exception.files.absolute-path.read-write with the path "/")
>
>
>One question is whether a
Hmm well Mike you were right!
I was too enthusiastic yesterday by claiming that I fixed my Open Panel
problem… I tried it here on my old Mac Mini with OS X 10.7 and the Open Panel
still stays open even with my newer code with windowDidLoad tec.…strangely
enough but at home it did work with my iM
On 31 Jan 2013, at 15:06, Gilles Celli wrote:
> Hmm well Mike you were right!
>
> I was too enthusiastic yesterday by claiming that I fixed my Open Panel
> problem… I tried it here on my old Mac Mini with OS X 10.7 and the Open Panel
> still stays open even with my newer code with windowDidLoa
I had not launched the Ap from Finder … of course upon doing so Launch Services
registered all my new types.
Apologies the noise.
-koko
On Jan 30, 2013, at 8:14 PM, koko wrote:
> For a few years now I have defined CFBundleDocumentTypes in my apps
> info.plist. The LSItemContentTypes contain
Now that I'm using this the right way, I'm having a hard time getting the popup
to use the correct names from the Info.plist. I've edited them recently, and
nothing I do helps (ran "lsregister -v -f /path/to/app.app", ran "touch
/path/to/app.app", launched app from Finder, rebooted). Any ideas?
On Jan 31, 2013, at 14:30 , Steve Mills wrote:
> I'm also confused about which things need to be in the Info.plist these days
I'd suggest a return visit to the documentation:
https://developer.apple.com/library/mac/#documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideFor
On Jan 31, 2013, at 14:30 , Steve Mills wrote:
> Now that I'm using this the right way, I'm having a hard time getting the
> popup to use the correct names from the Info.plist. I've edited them
> recently, and nothing I do helps (ran "lsregister -v -f /path/to/app.app",
> ran "touch /path/to/a
On 01/02/2013, at 1:24 AM, Sean McBride wrote:
> You are conflating issues. They are only "useless in practice" if you
> distribute with the app store. If you distribute otherwise, they are plenty
> useful: you can use the temp entitlements to get other App Sandbox benefits
> even if you gr
On Jan 31, 2013, at 17:04:24, Quincey Morris
wrote:
> I've had pretty good luck by holding down Option and choosing "Clean Build
> Folder" from the "Product" menu in Xcode. I think the problem is that if your
> intermediate build folder contains a build product other than the one you
> just
On Jan 31, 2013, at 16:50:12, Quincey Morris
wrote:
> I'd suggest a return visit to the documentation:
>
>
> https://developer.apple.com/library/mac/#documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/ApplicationCreationProcess/ApplicationCreationProcess.html
>
>
Hi all,
I have objects which have numerous properties that are CF types rather than
NSObject-derived types, e.g.
@property CGPathRef path;
I've just found that these properties can't be accessed using KVC, and in turn
that means archiving doesn't work either, since I use KVC to iterate throu
On Jan 31, 2013, at 7:36 PM, Graham Cox wrote:
> It makes me wonder how other objects in the system, e.g. CALayer, which have
> many similar CF type properties, are able to support NSCoding and KVC.
While I can't say whether or not CALayer does it, you could override
valueForKey: and handle tho
On Jan 31, 2013, at 8:33 PM, Seth Willits wrote:
> On Jan 31, 2013, at 7:36 PM, Graham Cox wrote:
>
>> It makes me wonder how other objects in the system, e.g. CALayer, which have
>> many similar CF type properties, are able to support NSCoding and KVC.
>
> While I can't say whether or not CAL
On 01/02/2013, at 3:33 PM, Seth Willits wrote:
> While I can't say whether or not CALayer does it, you could override
> valueForKey: and handle those properties yourself.
>
Yep, that's sort of what I'm doing... but it's more complex than that.
Basically, CFTypes are not natively archivable.
On Jan 31, 2013, at 21:08 , Kyle Sluder wrote:
> But CFTypes *are* NSObjects.
Only if they're toll-free bridged, and even then they'll need to conform to
NSCoding if they're going to encode/decode automatically. The
non-toll-free-bridged ones are memory-managed objects, but not necessarily Obj
On Jan 31, 2013, at 9:46 PM, Quincey Morris
wrote:
> On Jan 31, 2013, at 21:08 , Kyle Sluder wrote:
>
>> But CFTypes *are* NSObjects.
>
> Only if they're toll-free bridged,
All CFTypes are toll-free bridges to NSObject. (I was surprised when I learned
this, and I don't know how far back thi
On 01/02/2013, at 4:08 PM, Kyle Sluder wrote:
> But CFTypes *are* NSObjects. So I'm not sure why your case isn't working. Can
> you be more specific?
This is why the result surprised me - I have "known" this for years, and
assumed that there wouldn't be a problem with this. But, this is the
On Jan 31, 2013, at 11:46 PM, Quincey Morris
wrote:
> On Jan 31, 2013, at 21:08 , Kyle Sluder wrote:
>
>> But CFTypes *are* NSObjects.
>
> Only if they're toll-free bridged
Huh? It's been my understanding that all CFTypes bridge to NSObjects. CGPathRef
certainly does:
#import
int main(in
On Jan 31, 2013, at 21:51 , Kyle Sluder wrote:
> All CFTypes are toll-free bridges to NSObject. (I was surprised when I
> learned this, and I don't know how far back this holds true.)
> GCD objects and XPC objects are NSObjects as of 10.8.
Ah, yes, I see now this is so, now that I look.
I pre
On 1 Feb, 2013, at 1:53 PM, Graham Cox wrote:
>
> On 01/02/2013, at 4:08 PM, Kyle Sluder wrote:
>
>> But CFTypes *are* NSObjects. So I'm not sure why your case isn't working.
>> Can you be more specific?
>
>
> This is why the result surprised me - I have "known" this for years, and
> assu
>
> I don't understand that. The search pattern for valueForKey: is documented
> very clearly and if you have a myColor method or a _myColor instance
> variable, as you surely must, it should find it and return it. The only
> question from reading the documentation is .. what should it return i
On 01/02/2013, at 5:18 PM, Quincey Morris
wrote:
>> /* CoreGraphics - CGPath.h
>>Copyright (c) 2001-2011 Apple Inc.
>>All rights reserved. */
>>
>> typedef struct CGPath *CGMutablePathRef;
>> typedef const struct CGPath *CGPathRef;
>
> So KVC isn't going to know these are objects. Int
On Jan 31, 2013, at 22:54 , Graham Cox wrote:
> For the errant CFTypes, I hit -valueForUndefinedKey: and
> -setValue:forUndefinedKey:, overridden in this base class. This then checks
> whether in fact the selector really is undefined, and if not, it forces the
> value to be returned using -per
23 matches
Mail list logo
