I’m trying out writing a Service associated with my app:
> @implementation PrServicesProvider
>
> - (void)openURL:(NSPasteboard *)pboard userData:(NSString *)userData
> error:(NSString *__autoreleasing *)error {
> NSURL * const targetURL = [WebView URLFromPasteboard:pboard];
> NSStri
On Sep 14, 2014, at 19:47 , Charles Jenkins wrote:
> let noWrappers: [AnyObject] = []
> self.theFileWrapper = NSFileWrapper( directoryWithFileWrappers:
> noWrappers )
> When I start typing “directoryWithFileWrappers,” Xcode displays its
> suggestion list showing the prototype:
>
> N
> On 15 Sep 2014, at 10:47 am, Charles Jenkins wrote:
>
> Now on to the next thing that doesn’t seem to work according to the
> documentation…
>
> These are the first few lines of my function which will save my document data:
>
> override func fileWrapperOfType(
>typeName: String!,
>
Now on to the next thing that doesn’t seem to work according to the
documentation…
These are the first few lines of my function which will save my document data:
override func fileWrapperOfType(
typeName: String!,
error outError: NSErrorPointer
) -> NSFileWrapper!
{
if self.t
Well, that explanation was helpful. I learned how to verify that the
images.xcassets is indeed included in my target build. Also I tried one of your
suggestions, and this is what works:
class func getImageAsset( name: String ) -> NSImage {
let bundle = NSBundle.mainBundle()
let img =
On Sep 14, 2014, at 13:36 , Luc Van Bogaert wrote:
> when I close the panel and reopen it again, it seems that the panel has lost
> a reference to the document and it doesn't display the document's properties
> anymore.
Actually, I meant to suggest it was a *bad* idea to put the panel in the
On 13 Sep 2014, at 00:11, Luc Van Bogaert wrote:
>
>> Op 12 Sep 2014 om 23:40 heeft Quincey Morris
>> het volgende geschreven:
>>
>>> On Sep 12, 2014, at 13:57 , Luc Van Bogaert wrote:
>>>
>>> When I try to close the inspector panel in my document base application,
>>> I'm getting the defa
Performance is another reason. IIRC, in earlier OS X releases it turned out
that there was significant overhead stemming from converting between different
types of file references as a call went up and down the stack —
NSString/CFString <—>NSURL/CFURL <—> FSRef <—> C strings, etc. (This may soun
On Sep 14, 2014, at 11:37 , Charles Jenkins wrote:
> Okay, here’s a point on which I may need education. Xcode created my project
> with an images.xcassets folder right there in it, and that’s where I’m adding
> my images. Do you mean that’s not enough? I need to add images.xcassets to
> the t
Okay, here’s a point on which I may need education. Xcode created my project
with an images.xcassets folder right there in it, and that’s where I’m adding
my images. Do you mean that’s not enough? I need to add images.xcassets to the
target somewhere else? How do I do that?
--
Charles Jen
On Sep 14, 2014, at 2:57 AM, Aandi Inston wrote:
>> No one should be using path-based API any more, generally.
>> You should use URL-based equivalents.
>
> Why? Really, why? Certainly there are APIs where we have to use URL's and
> we have to convert the path into a URL, but where a non-deprecat
1. I added Sudden Termination to my app. I have a controller that watches a
WebHistory instance for changes and the dirty flag is KVO-compliant. When the
flag goes from non-dirty to dirty, my application delegate suspends Sudden
Termination and calls the save-history method after a 60-second del
Le 14 sept. 2014 à 10:23, Quincey Morris
a écrit :
> On Sep 14, 2014, at 00:57 , Aandi Inston wrote:
>
>> Why? Really, why? Certainly there are APIs where we have to use URL's and
>> we have to convert the path into a URL, but where a non-deprecated
>> path-based URL exists, what current or f
On Sep 14, 2014, at 00:57 , Aandi Inston wrote:
> Why? Really, why? Certainly there are APIs where we have to use URL's and
> we have to convert the path into a URL, but where a non-deprecated
> path-based URL exists, what current or future obstacles do you foresee? The
> URL doesn't seem to be m
> No one should be using path-based API any more, generally.
> You should use URL-based equivalents.
Why? Really, why? Certainly there are APIs where we have to use URL's and
we have to convert the path into a URL, but where a non-deprecated
path-based URL exists, what current or future obstacles
15 matches
Mail list logo
