Re: 'originals' folder is greyed out

[Rob Petrovec via Cocoa-dev]

Are you overriding NSOpenSavePanelDelegate -panel:shouldEnableURL:?  If so, 
make sure your code isn’t inadvertently disabling the folder for some reason.

Doing those steps in TextEdit works fine for me.  Maybe ask the user to try the 
same steps with TextEdit Open dialog and see if the behavior is different?

If it was a permissions issue the icon would have a  badge on it and should 
not appear disabled (grayed out).  Hope that helps & good luck.

—Rob


> On Sep 5, 2023, at 12:10 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> My app loads a number of image files and displays them.
> To some users, I suggest the following in order for them to loads their 
> photos:
> 
>> in Finder, go to your Pictures folder;
>> control-click on the icon
>>  Photos Library.photoslibrary,
>> then select "Show Package Contents".
>> Now go to the app's settings. 
>> First, select "Follow aliases", second
>> click "Change" (folder to search);
>> a folder dialog appears. Now, from the Photos library package contents 
>> folder,
>> drag the folder 'originals' into the app's folder dialog.
>> Then click Open, then OK.
> 
> Now, one user reported that, in his case, the folder 'originals' is greyed 
> out.
> (Dunno if it's greyed out in Finder, or in the app's folder open dialog.)
> 
> Anyways, I am wondering, does anybody have an idea why that is?
> 
> Best regards, Gabriel
> 
> PS:
> Yes, I know that an app/user should never mess with the contents of the 
> photos library.
> But in my app, I am merely loading the files, nothing else.
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Avoiding leaks with "initWithCGImage"

[Rob Petrovec via Cocoa-dev]

To be clear, CGImageForProposedRect doesn’t have ‘Create’ in the name. So the 
'Create Rule' doesn’t apply.  But it is an easy thing to overlook.

—Rob


> On Aug 24, 2023, at 2:35 AM, JPH  wrote:
> 
> Thanks to all of you
> The  CFRelease(imageRef); was the problem and the  CFRelease(subImageRef); is 
> OK
> My fault was then to apply the old days « Create rule » , bypassing ARC ! 
> I was misled by Instruments/Leaks which  reports a leak, which meant to me 
> that I had to look  for  a missing release, not an over-release !! 
> Very confusing !
> 
> Thank again 
> Happy Dog Days ( 41°C  / 105,8°F here ! ) 
> 
> JP
> 
> 
> 
>> Le 24 août 2023 à 00:55, Rob Petrovec  a écrit :
>> 
>> CGImageForProposedRect returns an autoreleased CGImageRef, so your 
>> CFRelease(imageRef) is an overrelease and likely the cause of your problem.  
>> The rest of the code looks fine, including the release of subImageRef (if it 
>> was uncommented).
>> 
>> —Rob
>> 
>> Le 24 août 2023 à 01:11, Alex Zavatone  a écrit :
>> 
>> Got a small sample we could play with?  I would expect the crash on explicit 
>> release as it would cause a double release.
>> 
>> I tend to ignore I strums to with leaks and use the Memory Graph debugger 
>> religiously.
>> 
>> If you have a little sample showing this, I would be happy to test a bit 
>> with it.
>> 
>> Cheers,
>> Alex Zavatone
> 
> 
> Le 24 août 2023 à 07:44, Sandor Szatmari  a 
> écrit :
> 
> You mention ARC… aren’t you not supposed to explicitly release objects under 
> ARC?  Am I misunderstanding?
> 
> Sandor
> 
>> 
>>> On Aug 23, 2023, at 4:47 PM, JPH via Cocoa-dev  
>>> wrote:
>>> 
>>> Hello friends,
>>> 
>>> The enclosed procedure is producing a NSImage from  another NSImage, by 
>>> cropping in a NSRect.
>>> The resulting sub-Image feeds  an imageView  in the APP Interface and the 
>>> may change frequently,  then being hopefully disposed by ARC
>>> The last line of the procedure :
>>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef 
>>> size:NSZeroSize];
>>> Generates a leak problem.
>>> 
>>> it is quite unclear if i should release or not  the  subImageRef.
>>> 
>>> If I release,  the app crashes soon after.
>>> If I don’t release, Instrument/Leaks reports a leak  of subImageRef  after 
>>> each call.
>>> 
>>> Obviously, ARC never releasessubImageRefwhich, as far as I 
>>> understand, is owned by the  subImage after the call.
>>> 
>>> Digging the web , apple doc, and various AI, did not provide a solution to 
>>> this dilemme.
>>> 
>>> I would greatly appreciate some help on this
>>> 
>>> Happy summer.. 
>>> JP
>>> 
>>> C
>>> //=
>>> + (NSImage *)getSubImageFromImage:(NSImage *)image atRect:(NSRect)rect
>>> //=
>>> {
>>> // Convert the NSImage to a CGImageRef
>>> CGImageRef imageRef= nil, subImageRef= nil;
>>> imageRef = [image CGImageForProposedRect:NULL context:nil hints:nil];
>>> if (imageRef == nil ) {  return nil; } // Failed to create CGImageRef
>>> // Get the subimage from the CGImageRef
>>> subImageRef = CGImageCreateWithImageInRect(imageRef, rect);
>>> CFRelease(imageRef);
>>> if(subImageRef == nil ) {  return nil;  }  // Failed to create subImageRef
>>> // Convert the subimage CGImageRef to an NSImage
>>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef 
>>> size:NSZeroSize];
>>> //   CFRelease(subImageRef); // it is quite unclear if i should release the 
>>>  subImageRef
>>> //If I release, the app crashes soon after.
>>> // If i dont release Instrument/Leaks report a leak at next call.
>>> // The subImage goes to a NSbutton in the interface, and will also soon be 
>>> replaced by another one, producing a leak of subImageRef
>>> 
>>> return subImage;
>>> }// getSubImageFromImage
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
>>> 
>>> This email sent to petr...@mac.com
>> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Avoiding leaks with "initWithCGImage"

[Rob Petrovec via Cocoa-dev]

ARC only affects Objective-C objects.  It has no effect on CF objects like 
CGImageRefs, CFArrayRefs, CFDictionaryRefs etc.  If you play with CF objects in 
an ARC app you still need to release them. You don’t need to release Obj-C 
objects and the compiler will warn you if you try to.

—Rob


> On Aug 23, 2023, at 11:44 PM, Sandor Szatmari via Cocoa-dev 
>  wrote:
> 
> You mention ARC… aren’t you not supposed to explicitly release objects under 
> ARC?  Am I misunderstanding?
> 
> Sandor
> 
>> On Aug 23, 2023, at 18:48, JPH via Cocoa-dev  
>> wrote:
>> 
>> Hello friends,
>> 
>> The enclosed procedure is producing a NSImage from  another NSImage, by 
>> cropping in a NSRect.
>> The resulting sub-Image feeds  an imageView  in the APP Interface and the 
>> may change frequently,  then being hopefully disposed by ARC
>> The last line of the procedure :
>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef 
>> size:NSZeroSize];
>> Generates a leak problem.
>> 
>> it is quite unclear if i should release or not  the  subImageRef.
>> 
>> If I release,  the app crashes soon after.
>> If I don’t release, Instrument/Leaks reports a leak  of subImageRef  after 
>> each call.
>> 
>> Obviously, ARC never releasessubImageRefwhich, as far as I 
>> understand, is owned by the  subImage after the call.
>> 
>> Digging the web , apple doc, and various AI, did not provide a solution to 
>> this dilemme.
>> 
>> I would greatly appreciate some help on this
>> 
>> Happy summer.. 
>> JP
>> 
>> C
>> //=
>> + (NSImage *)getSubImageFromImage:(NSImage *)image atRect:(NSRect)rect
>> //=
>> {
>> // Convert the NSImage to a CGImageRef
>> CGImageRef imageRef= nil, subImageRef= nil;
>> imageRef = [image CGImageForProposedRect:NULL context:nil hints:nil];
>> if (imageRef == nil ) {  return nil; } // Failed to create CGImageRef
>> // Get the subimage from the CGImageRef
>> subImageRef = CGImageCreateWithImageInRect(imageRef, rect);
>> CFRelease(imageRef);
>> if(subImageRef == nil ) {  return nil;  }  // Failed to create subImageRef
>> // Convert the subimage CGImageRef to an NSImage
>> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef 
>> size:NSZeroSize];
>> //   CFRelease(subImageRef); // it is quite unclear if i should release the  
>> subImageRef
>> //If I release, the app crashes soon after.
>> // If i dont release Instrument/Leaks report a leak at next call.
>> // The subImage goes to a NSbutton in the interface, and will also soon be 
>> replaced by another one, producing a leak of subImageRef
>> 
>> return subImage;
>> }// getSubImageFromImage
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com
>> 
>> This email sent to admin.szatmari@gmail.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Avoiding leaks with "initWithCGImage"

[Rob Petrovec via Cocoa-dev]

CGImageForProposedRect returns an autoreleased CGImageRef, so your 
CFRelease(imageRef) is an overrelease and likely the cause of your problem.  
The rest of the code looks fine, including the release of subImageRef (if it 
was uncommented).

—Rob


> On Aug 23, 2023, at 4:47 PM, JPH via Cocoa-dev  
> wrote:
> 
> Hello friends,
> 
> The enclosed procedure is producing a NSImage from  another NSImage, by 
> cropping in a NSRect.
> The resulting sub-Image feeds  an imageView  in the APP Interface and the may 
> change frequently,  then being hopefully disposed by ARC
> The last line of the procedure :
> NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef 
> size:NSZeroSize];
> Generates a leak problem.
> 
> it is quite unclear if i should release or not  the  subImageRef.
> 
> If I release,  the app crashes soon after.
> If I don’t release, Instrument/Leaks reports a leak  of subImageRef  after 
> each call.
> 
> Obviously, ARC never releasessubImageRefwhich, as far as I 
> understand, is owned by the  subImage after the call.
> 
> Digging the web , apple doc, and various AI, did not provide a solution to 
> this dilemme.
> 
> I would greatly appreciate some help on this
> 
> Happy summer.. 
> JP
> 
> C
> //=
> + (NSImage *)getSubImageFromImage:(NSImage *)image atRect:(NSRect)rect
> //=
> {
>  // Convert the NSImage to a CGImageRef
>  CGImageRef imageRef= nil, subImageRef= nil;
>  imageRef = [image CGImageForProposedRect:NULL context:nil hints:nil];
>  if (imageRef == nil ) {  return nil; } // Failed to create CGImageRef
>  // Get the subimage from the CGImageRef
>  subImageRef = CGImageCreateWithImageInRect(imageRef, rect);
>  CFRelease(imageRef);
>  if(subImageRef == nil ) {  return nil;  }  // Failed to create subImageRef
>  // Convert the subimage CGImageRef to an NSImage
>  NSImage *subImage = [[NSImage alloc] initWithCGImage:subImageRef 
> size:NSZeroSize];
> //   CFRelease(subImageRef); // it is quite unclear if i should release the  
> subImageRef
> //If I release, the app crashes soon after.
> // If i dont release Instrument/Leaks report a leak at next call.
> // The subImage goes to a NSbutton in the interface, and will also soon be 
> replaced by another one, producing a leak of subImageRef
> 
>  return subImage;
> }// getSubImageFromImage
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Substitute for kill(2)?

[Rob Petrovec via Cocoa-dev]

NSDistributedNotificationCenter is a way to send a notification out across the 
system. Only processes that are listening for the notification will receive it 
and have a chance to do something with it. It’s like yelling out in a crowded 
room to tell a single person something. Everyone will hear your message, but 
only one will be listening. Make sense?  
https://developer.apple.com/documentation/foundation/nsdistributednotificationcenter?changes=_4=objc

But what it really sounds like you want to use XPC (Cross Process 
Communication) for a more targeted messaging (possibly with payloads) between 
your app and menuling.  
https://developer.apple.com/documentation/xpc?language=objc

—Rob


> On Jul 25, 2023, at 7:51 AM, Gabriel Zachmann  wrote:
> 
> Thanks a lot for your responses!
> 
> Sorry for the misunderstanding: I don't want to kill the other process.
> (In case you forgot: the kill(2) system call is for sending unix signals to 
> processes, which can listen to those signals (at least, most of them). I just 
> want to signal the other process, not really kill it. So, SIGUSR1 would've 
> been my choice, if macOS would allow me to send a signal.)
> 
> What do you mean by "distributed notification" ?
> How would I send it?
> 
> Best regards, Gabriel
> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Substitute for kill(2)?

[Rob Petrovec via Cocoa-dev]

Yeah, you might be able to send out a distributed notification and have the 
menuling listen for it. When it receives it it can kill itself or go through 
the normal teardown/quit procedure.

—Rob


> On Jul 25, 2023, at 6:15 AM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> What if you called a method in the other process and the other process kills 
> itself with a kill?  
> 
> Is kill no longer functional from any process?
> 
>> On Jul 25, 2023, at 2:49 AM, Gabriel Zachmann via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> Is there a simple way for one process to send a single signal to another 
>> process?
>> Both processes are my programs, one is a regular app, the other a menu bar 
>> item.
>> Both are launched by the same user.
>> 
>> In the old unix days, I would have used kill(2) and send a SIGUSR1 , but as 
>> far as I understand, this is no longer possible.
>> (At least,  not without privilege elevation, which seems too complicated.)
>> 
>> All hints and ideas will be appreciated!
>> Best regards, Gabriel
>> 
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
>> 
>> This email sent to z...@mac.com 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> )
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> 
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com 
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSScreen.screens under multiple displays

[Rob Petrovec via Cocoa-dev]

The order of the screens can change under various user scenarios.  One easy one 
is simply re-arranging the displays, or even moving the menu bar thing from one 
display to another in the Arrange UI Displays prefs pane. Obviously plugging & 
unplugging displays or closing a laptop with an external display will change it 
too. You should not assume the index of the screen your window is on, if that 
is what you were thinking.  Hope that helps.

—Rob


> On Jun 8, 2023, at 10:53 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> In my method 
> 
>   - (void) viewDidMoveToWindow
> 
> I have these lines of code:
> 
>window_ = [self window];
>NSUInteger idx_of_screen = [NSScreen.screens indexOfObject: 
> window_.screen];
> 
> My question is: will this always produce the same results, whether or not the 
> user has switched "Displays have separate Spaces" on or off (under Desktop & 
> Dock).
> 
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Memory leak in Apple's image handling frameworks ?

[Rob Petrovec via Cocoa-dev]

> On May 1, 2023, at 5:04 AM, Gabriel Zachmann  wrote:
> 
> Thanks so much again!
> 
> I tried, and it didn't give me a good clue, though.
> What I got as output is:
> All zones: 1466 nodes malloced - Sizes: 117040KB[25] 96KB[25] 8KB[2] 5.5KB[1] 
> 5KB[1] 4KB[2] 3KB[3] 2.5KB[2] 2KB[4] 1.5KB[4] 656[15] 592[2] 528[2] 512[2] 
> 448[5] 400[3] 384[2] 368[3] 352[1] 336[1] 304[35] 288[19] 272[16] 256[29] 
> 240[8] 224[6] 208[40] 192[9] 176[15] 160[7] 144[5] 128[7] 112[30] 96[7] 
> 80[32] 64[115] 48[298] 32[553] 16[130] 

> 117040KB[25]
Thats twenty five 117MB objects.  That seems suspicious. Also, if you 
look further down the heap output to the table of objects look for one or more 
objects that have a high count that is unexpected.  I’d start investigating 
there.


> So that does not account for the 5+GB (after a few minutes, and growing), I 
> think.
At the time you ran heap did it say the 'Physical footprint’ was 5GB?

—Rob


>> On 30. Apr 2023, at 20:41, Rob Petrovec  wrote:
>> 
>> Oh yeah, Gabriel, another technique you can use is to start your app and 
>> create a memgraph _before_ reproducing the problem.  Then reproduce the 
>> problem and run ‘heap MyApp --diffFrom MyApp.memgraph’.  It will show the 
>> new objects that have been created since the memgraph was taken, sorted 
>> number of objects. That might narrow down what object(s) are eating your 
>> memory.  Good luck.
>> 
>> —Rob
>> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Memory leak in Apple's image handling frameworks ?

[Rob Petrovec via Cocoa-dev]

Oh yeah, Gabriel, another technique you can use is to start your app and create 
a memgraph _before_ reproducing the problem.  Then reproduce the problem and 
run ‘heap MyApp --diffFrom MyApp.memgraph’.  It will show the new objects that 
have been created since the memgraph was taken, sorted number of objects. That 
might narrow down what object(s) are eating your memory.  Good luck.

—Rob


> On Apr 30, 2023, at 12:31 PM, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
> Hey,
>   Since you have unbounded memory growth, you will likely have one or 
> more object types with a TON of instances in the list on the left. They are 
> likely the source, or part of a chain of objects eating your memory.  
> MallocStackLogging doesn’t show more info about a possible cause.  Once you 
> find the cause (the object type(s) eating your memory) MallocStackLogging 
> will show you where those objects are being created and you can inspect their 
> retain/release history to see where you may be forgetting to release 
> something.  Memory issues are not simple to track down, but once you do find 
> the cause they are totally satisfying when you find a fix. Good luck.
> 
> —Rob
> 
> 
>> On Apr 30, 2023, at 9:41 AM, Gabriel Zachmann  wrote:
>> 
>> Thanks a lot for your response!
>> And thanks a lot for your hints to 'leaks'.
>> 
>> I tried it, but I don't see any "ROOT CYCLE" in the output of 'leaks'.
>> (I see a bunch of ROOT LEAKS, but in total it's just 6 kB.)
>> 
>> Also, in the Debugger of Xcode, when i click on "Debug Memory Graph" icon, I 
>> get lots of graphs, but none of them shows a cycle.
>> Same when I double-click the memgraph file: I can select all the memory 
>> graphs that go through CGImage, but none of them contains a cycle (and most 
>> of them don't originate in my code).
>> 
>> And, yes, I do release the images using CFRelease() - but, of course, still 
>> thanks for the thought!
>> 
>> ( I also switched on MallocStackLogging, but that did not provide more info 
>> on potential causes for the massive leak, of course.)
>> 
>> 
>> Still stymied, Gab.
>> 
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Memory leak in Apple's image handling frameworks ?

[Rob Petrovec via Cocoa-dev]

Curious, Alex, what does this memoryFootprint function show that running 
‘footprint’ or ‘heap’ in Terminal doesn’t?

—Rob


> On Apr 30, 2023, at 8:12 AM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> Memory used query method for iOS.
> 
> https://stackoverflow.com/a/57315975/1058199
> 
> //  Created by Alex Zavatone on 8/1/19.
> //
> 
> class Memory: NSObject {
> 
>// From Quinn the Eskimo at Apple.
>// https://forums.developer.apple.com/thread/105088#357415
> 
>class func memoryFootprint() -> Float? {
>// The `TASK_VM_INFO_COUNT` and `TASK_VM_INFO_REV1_COUNT` macros are 
> too
>// complex for the Swift C importer, so we have to define them 
> ourselves.
>let TASK_VM_INFO_COUNT = 
> mach_msg_type_number_t(MemoryLayout.size / 
> MemoryLayout.size)
>let TASK_VM_INFO_REV1_COUNT = 
> mach_msg_type_number_t(MemoryLayout.offset(of: 
> \task_vm_info_data_t.min_address)! / MemoryLayout.size)
>var info = task_vm_info_data_t()
>var count = TASK_VM_INFO_COUNT
>let kr = withUnsafeMutablePointer(to: ) { infoPtr in
>infoPtr.withMemoryRebound(to: integer_t.self, capacity: 
> Int(count)) { intPtr in
>task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), 
> intPtr, )
>}
>}
>guard
>kr == KERN_SUCCESS,
>count >= TASK_VM_INFO_REV1_COUNT
>else { return nil }
> 
>let usedBytes = Float(info.phys_footprint)
>return usedBytes
>}
> 
>class func formattedMemoryFootprint() -> String
>{
>let usedBytes: UInt64? = UInt64(self.memoryFootprint() ?? 0)
>let usedMB = Double(usedBytes ?? 0) / 1024 / 1024
>let usedMBAsString: String = "\(usedMB)MB"
>return usedMBAsString
> }
> }
> Enjoy
> 
> 
> 
>> On Apr 30, 2023, at 9:05 AM, Alex Zavatone  wrote:
>> 
>> Use the memory graph debugger, not Instruments.  
>> 
>> I also have a method published on StackOverflow that lets you check on and 
>> print out the amount of memory used.  It is for iOS.
>> 
>> As for abandoned memory, that also could be the case.  An object in memory 
>> with no pointer to it.
>> 
>> If you want, we could do a video meeting and I could guide you through it. 
>> 
>> Will reply with the memory querying function.
>> 
>> Cheers,
>> Alex Zavatone
>> 
>> Sent from my iPhone
>> 
>>> On Apr 29, 2023, at 11:15 PM, Rob Petrovec via Cocoa-dev 
>>>  wrote:
>>> 
>>> This sounds like Abandoned Memory, not a leak.  Abandoned memory is a 
>>> retain cycle somewhere.  Best/easiest way to find those is with a memgraph. 
>>>  Click the little sideways V icon in Xcode’s debugger when the problem is 
>>> reproducing.
>>> 
>>> 
>>> 
>>> Or run ‘leaks MyApp --outputGraph ~’ in Terminal when the problem is 
>>> reproducing and open the resulting .memgraph file in your home directory.  
>>> Bonus points is enabling MallocStackLogging in the Xcode Project -> Edit 
>>> Scheme -> Run -> Diagnostics and check Malloc Stack Logging and switch to 
>>> All Allocations And Free History. This will show backtraces for where an 
>>> object is created in the memgraph and other useful info.
>>> 
>>> Leaks show up as little yellow caution signs and abandoned memory sometimes 
>>> have purple caution signs. Either way, look for an abnormally high number 
>>> of objects and see if they point back to your image.  Thats likely where 
>>> your memory is being consumed.
>>> 
>>>> CGImageSourceCreateWithURL() for loading, CALayer for displaying.
>>>  Just a thought since you didn’t mention it: are you releasing the 
>>> CGImageSource object too?
>>> 
>>> Good luck.
>>> 
>>> —Rob
>>> 
>>> 
>>>> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev 
>>>>  wrote:
>>>> 
>>>> I have an app that is basically a slide show.
>>>> Basically, it loads one image after another, displays it, then frees up 
>>>> its memory.
>>>> When I test it with my image collection of 100k+ images, everything is 
>>>> fine.
>>>> 
>>>> However, one user sent me a photo (JPG) that makes my app use up more and 
>>>> more memory.
>>>> I can see it in Activity Monitor and in Xcode's Memory Report View.
>>>> After a minute, my app uses 5 GB of main memory, after that, the growth 

Re: Memory leak in Apple's image handling frameworks ?

[Rob Petrovec via Cocoa-dev]

Hey,
Since you have unbounded memory growth, you will likely have one or 
more object types with a TON of instances in the list on the left. They are 
likely the source, or part of a chain of objects eating your memory.  
MallocStackLogging doesn’t show more info about a possible cause.  Once you 
find the cause (the object type(s) eating your memory) MallocStackLogging will 
show you where those objects are being created and you can inspect their 
retain/release history to see where you may be forgetting to release something. 
 Memory issues are not simple to track down, but once you do find the cause 
they are totally satisfying when you find a fix. Good luck.

—Rob


> On Apr 30, 2023, at 9:41 AM, Gabriel Zachmann  wrote:
> 
> Thanks a lot for your response!
> And thanks a lot for your hints to 'leaks'.
> 
> I tried it, but I don't see any "ROOT CYCLE" in the output of 'leaks'.
> (I see a bunch of ROOT LEAKS, but in total it's just 6 kB.)
> 
> Also, in the Debugger of Xcode, when i click on "Debug Memory Graph" icon, I 
> get lots of graphs, but none of them shows a cycle.
> Same when I double-click the memgraph file: I can select all the memory 
> graphs that go through CGImage, but none of them contains a cycle (and most 
> of them don't originate in my code).
> 
> And, yes, I do release the images using CFRelease() - but, of course, still 
> thanks for the thought!
> 
> ( I also switched on MallocStackLogging, but that did not provide more info 
> on potential causes for the massive leak, of course.)
> 
> 
> Still stymied, Gab.
> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Memory leak in Apple's image handling frameworks ?

[Rob Petrovec via Cocoa-dev]

This sounds like Abandoned Memory, not a leak.  Abandoned memory is a retain 
cycle somewhere.  Best/easiest way to find those is with a memgraph.  Click the 
little sideways V icon in Xcode’s debugger when the problem is reproducing.


Or run ‘leaks MyApp --outputGraph ~’ in Terminal when the problem is 
reproducing and open the resulting .memgraph file in your home directory.  
Bonus points is enabling MallocStackLogging in the Xcode Project -> Edit Scheme 
-> Run -> Diagnostics and check Malloc Stack Logging and switch to All 
Allocations And Free History. This will show backtraces for where an object is 
created in the memgraph and other useful info.

Leaks show up as little yellow caution signs and abandoned memory sometimes 
have purple caution signs. Either way, look for an abnormally high number of 
objects and see if they point back to your image.  Thats likely where your 
memory is being consumed.

> CGImageSourceCreateWithURL() for loading, CALayer for displaying.
Just a thought since you didn’t mention it: are you releasing the 
CGImageSource object too?

Good luck.

—Rob


> On Apr 29, 2023, at 4:07 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I have an app that is basically a slide show.
> Basically, it loads one image after another, displays it, then frees up its 
> memory.
> When I test it with my image collection of 100k+ images, everything is fine.
> 
> However, one user sent me a photo (JPG) that makes my app use up more and 
> more memory.
> I can see it in Activity Monitor and in Xcode's Memory Report View.
> After a minute, my app uses 5 GB of main memory, after that, the growth rate 
> slows down a bit,
> but it keeps growing without bounds, until, eventually, it crashes, of course.
> 
> However, when I try to check for memory leaks using XCode/Instruments/Leaks, 
> it says there are none!
> 
> Is it possible there is a memory leak in Apple's frameworks?
> 
> If you are interested, you can find the image here:
>  https://owncloud.informatik.uni-bremen.de/index.php/s/BbBJcjMSTm9enwW
> It's just 5 MB, and I can't see any issue with it.
> The uncompressed image in-memory maybe takes up 100MB.
> 
> The frameworks/methods I use are the usual:
> CGImageSourceCreateWithURL() for loading, CALayer for displaying.
> 
> I assign the image like this:
> 
>CALayer * imgLayer   = [CALayer layer];
>imgLayer.contents= (__bridge id)(imageRef); 
> 
> where imageRef is of type CGImageRef.
> I also release my images later with CGImageRelease().
> 
> I am a stymied.
> Any hints/suggestions will be highly appreciated.
> 
> Gab.
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSCollectionView, disappearing items on reloadData

[Rob Petrovec via Cocoa-dev]

NSCollectionView, like NSTableView/NSOutlineView, will reuse existing views 
instead of recreating them when it can to speed up the UI. This is most 
commonly used during scrolling where views that scroll out of view will be 
reused with new data and scrolled into view. It will call -prepareForReuse (See 
NSCollectionVIewElement protocol) on the NSCollectionViewItem (and I think the 
view too) so you can reset them back to their post -init state.  I’d look into 
implementing that and see if that helps.

Also, -reloadData will trigger a series of NSCollectionViewDelegate methods to 
be called which will dictate what appears in the view after reload.  Set some 
breakpoints in -collectionView:numberOfItemsInSection: & 
-collectionView:itemForRepresentedObjectAtIndexPath: and make sure you are 
returning expected values.

With that said, -reloadData is a pretty big hammer and can kill performance 
with large view hierarchies. It’s better to use API like 
-performBatchUpdates:completionHandler: and related methods to 
insert/move/remove views as needed.

Hope that helps & good luck.

—Rob


> On Jan 8, 2023, at 2:03 PM, Arved von Brasch via Cocoa-dev 
>  wrote:
> 
> Hello list,
> 
> I’ve encountered a bug for the life of me I can’t work out. I’m restricted to 
> supporting Mojave (10.14) for the time being, so it is possible this has been 
> fixed / not an issue on later releases. This is a Core Data backed 
> application, with several Xib loaded views that are swapped in and out based 
> on the selection of a segmented control in the toolbar. The basic issue is 
> that when I call ‘reloadData()’ on a CollectionView, all the items disappear 
> (this typically happens if the user switches to a different view and then 
> back again, as, while previously loaded views are kept in memory, they are 
> reloaded upon switching back to the foreground - ie. this is not tabs, but 
> separate loads of Xib file Views). If I put a break point in an override of 
> ‘viewWillDisappear()` in my NSCollectionViewItem subclass, I can see the 
> backtrace indicates that NSCollectionView has decided to reuse the 
> CollectionViewItem but not issued a new one:
> 
> * NSCollectionView reloadData
> * _NSCollectionViewCore reloadData
> * _NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:
> * __35-_NSCollectionViewCore reloadData]_block_invoke
> * NSCollectionViewCore _reuseCell:notifyDidEndDisplaying:
> * _reuseViewWithReuseQueue
> * NSCollectionViewItem _setHiddenForReuse:
> * NSView(NSInternal) _setHidden:setNeedsDisplay:
> * NSView _recursiveViewWillDisappearBeacuseHidden
> * NSViewController _sendViewWillDisappear
> * @objc CollectionViewItem.viewWillDisappear()
> * CollectionViewItem.viewWillDisappear()
> 
> In the NSCollectionView itself, I can see the items are removed from the 
> ‘visibleItems()’ array, but the items themselves still seems to be known 
> about by the collection view, as they will remain in the 
> ‘selectionIndexPaths:’ if they were previously selected.
> 
> What’s really weird is that because we have multiple top level views, a lot 
> of the code is reused on different displays, including the NSArrayController 
> subclass that serves as the Delegate and DataSource for this 
> NSCollectionView. It works perfectly fine in the other case. The main 
> difference between these two top levels views, is that in the one that works, 
> the Collection View is slaved to a Table View (ie the collection view shows 
> the items in a relationship to the selection in the table view), where as in 
> the one that doesn’t work, the behaviour is inverted (the selection in the 
> collection view is the data source for a slaved table view). To be clear, 
> though, both are displaying completely different Core Data entities. I don’t 
> think I’ve missed anything, so as far as I can tell both NSCollectionViews 
> are configured identically in the two XIBs.
> 
> The last weird thing is that the problem only seems to manifest if the 
> application has previously been built. If I Make Clean first, the resulting 
> behaviour is as I would expect. If I close and reopen the application, the 
> behaviour is then broken. The backtrace is common to both situations, so the 
> problem is that something is preventing the Collection View from reissuing a 
> CollectionViewItem for the objects. I’m not sure where to look for that side, 
> other than to say that ‘viewWillAppear()’ is not called when the problem is 
> occurring, and does when it isn't.
> 
> I’m fairly convinced that the problem is in the Xib file. I have tried 
> removing everything else except the NSCollectionView and a few buttons and 
> the problem doesn’t seem to manifest in that case. I haven’t tried bringing 
> in one additional view or controller at a time to see when it eventually 
> breaks, because there are far too many for that to be a good debugging path. 
> The view with the working CollectionView is significantly simpler, if that 
> matters. (I suppose a 

Re: NSAppKitVersionNumber wrong on latest Big Sur versions?!

[Rob Petrovec via Cocoa-dev]

Yes, this is a bug that started in 11.7 that doesn’t appear to have been fixed 
yet in 11.7.2.

Have you tried the arguably more robust and less error prone runtime checks of:

Swift
if #available(macOS 10.16, *) {
  // macOS 10.16 or later code path
} else {
  // code for earlier than 10.16
}

Objective-C
if (@available(macOS 10.16, *)) {
  // macOS 10.16 or later code path
} else {
  // code for earlier than 10.16
}

—Rob


> On Jan 6, 2023, at 1:32 PM, Sean McBride via Cocoa-dev 
>  wrote:
> 
> Hi all,
> 
> On at least 3 Macs in my office, running macOS 11.7 or 11.7.2, 
> NSAppKitVersionNumber (at runtime) is 2202.7 (sic).  This conflicts with 
> NSApplication.h which has:
> 
> static const NSAppKitVersion NSAppKitVersionNumber11_0 = 2022;
> static const NSAppKitVersion NSAppKitVersionNumber11_1 = 2022.2;
> static const NSAppKitVersion NSAppKitVersionNumber11_2 = 2022.3;
> static const NSAppKitVersion NSAppKitVersionNumber11_3 = 2022.4;
> static const NSAppKitVersion NSAppKitVersionNumber11_4 = 2022.5;
> static const NSAppKitVersion NSAppKitVersionNumber11_5 = 2022.6;
> 
> I had a macOS 11.2 installer lying around, and installed it in a VM, and 
> there NSAppKitVersionNumber is 2022.3 as expected.
> 
> I can't help but note that 2202 looks like a typo vs 2022!
> 
> As 2202.7 is larger than NSAppKitVersionNumber12_0 (2113) it results in going 
> into branches that should be Monterey-only.  Ouch.
> 
> Has anyone else observed this?
> 
> Thanks,
> 
> Sean
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: setting Finder search input

[Rob Petrovec via Cocoa-dev]

Is it always going to be the same search?  If so, you could create a Saved 
Search in the Finder and include it with your app.  Then when you want to bring 
up the search you can open the Saved Search bundle and it will open in the 
Finder.  Hope that helps.

—Rob


> On Dec 13, 2022, at 1:10 PM, Torsten Curdt via Cocoa-dev 
>  wrote:
> 
> I would like to open a Finder window with a pre-filled search filter and
> search results - but I just cannot find a good way to do it. I tried to
> find a way through the Scripting Bridge but it seems like this is not
> exposed at all.
> 
> Any other suggestions?
> 
> cheers,
> Torsten
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: dispatch_apply() on an NSArray and Thread Sanitizer

[Rob Petrovec via Cocoa-dev]

> On Apr 19, 2022, at 5:26 PM, Sean McBride via Cocoa-dev 
>  wrote:
> 
> On 19 Apr 2022, at 18:47, Saagar Jha wrote:
> 
>> If Thread Sanitizer says your code has a race, it almost certainly has a 
>> race.
> 
> Yeah, that's been my general experience until now.
> 
>> Your simple code seems OK superficially, but there are a couple things that 
>> could be problematic here: either your real code is actually mutating 
>> something, or (unlikely) you are touching some internal state, perhaps a CoW 
>> optimization, that is not visible to you but is silently changing things 
>> under the hood.
> 
> In case it wasn't clear, the code snippet in my email actually reproduces the 
> issue.  I created a fresh Xcode project and it's literally just:
> 
> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
>   NSArray* array = @[@5, @6, @7, @8, @9, @10, @11];
>   
>   [array enumerateObjectsWithOptions:NSEnumerationConcurrent 
> usingBlock:^(NSNumber* num, NSUInteger idx, BOOL* stop) {
>   array[idx];
>   }];
> } 
> 
> TSan complains with this on macOS 12.3.1 on an M1 Mac Mini with Xcode 13.3.  
> But on an Intel Mac Pro, macOS 11.6.6 with Xcode 13.2.1, TSan does not 
> complain.
> 
>> In any case, I would generally suggest using -[NSArray 
>> enumerateObjectsAtIndexes:options:usingBlock:] with the 
>> NSEnumerationConcurrent flag, which should rule out any issues with 
>> concurrent access on the array itself.
> 
> I tried enumerateObjectsWithOptions:usingBlock: and TSan doesn't complain 
> with it.  But I was suspicious of that and added an NSLog to print the index, 
> and even after adding random sleeps:
> 
>   [array enumerateObjectsWithOptions:NSEnumerationConcurrent 
> usingBlock:^(NSNumber* nub, NSUInteger idx, BOOL* stop) {
>   usleep(arc4random_uniform(100));
>   NSLog(@"idx: %d", idx);
>   array[idx];
>   }];
> 
> The thing is *not* running concurrently on the M1.  The indices are always 
> printed in order.  Weird.
The docs for NSEnumerationConcurrent state that it is a hint and may be 
ignored at run time.  If you absolutely need it to be run on multiple threads 
you should do it explicitly, IMO, with dispatch_async and appropriate critical 
section locking.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Building for 10.12

[Rob Petrovec via Cocoa-dev]

> On Mar 20, 2022, at 11:41 AM, Quincey Morris 
>  wrote:
> 
> (Resending because I forgot to cc the list)
> 
> On Mar 20, 2022, at 08:09, Gabriel Zachmann via Cocoa-dev 
>  wrote:
>> 
>> Apparently, this caused it:
>> 
>> Symbol not found: _AVAudioSessionInterruptionNotification
>> 
>> Yes, I am using that function, and yes, it seems to be available only on 
>> macOS 11 and higher.
> 
> AVAudioSession doesn’t exist on macOS, in any version. I see that the 
> documentation page for AVAudioSessionInterruptionNotification lists it 
> incorrectly as supported on macOS 11+, but I can’t find anything in the SDK 
> headers to suggest where that incorrect information came from.
Wow, good catch.  


> The real question is how the macOS target compiled at all. Can you shed any 
> light on how you got as far as linking, with an unknown 
> _AVAudioSessionInterruptionNotification symbol in your target?
The header, in the 12.2 SDK, doesn’t list macOS as one of the available 
OSs for that constant, so Quincey is right. It shouldn’t have compiled for 
macOS.

OS_EXPORT NSNotificationName const  AVAudioSessionInterruptionNotification 
API_AVAILABLE(ios(6.0), watchos(2.0), tvos(9.0));

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Building for 10.12

[Rob Petrovec via Cocoa-dev]

> On Mar 20, 2022, at 9:09 AM, Gabriel Zachmann  wrote:
> 
> I have now the crash report.
> 
> Apparently, this caused it:
> 
>  Symbol not found: _AVAudioSessionInterruptionNotification
> 
> Yes, I am using that function, and yes, it seems to be available only on 
> macOS 11 and higher.
> 
> My question now is: why did Xcode not warn me about that function, even 
> though the deployment target was set to 10.12 ?
The deployment target not a compiler setting. It is more of a runtime 
thing.  So if you set the deployment target to 13.0 it will not launch on macOS 
12, for example.  The SDK is what determines what API are (not) available. So 
if you were building against the 10.12 SDK you would have gotten a compiler 
error.


> How can I prevent things like that happening in the future?
Use the correct SDK for the OS builds you want to support.  There are 
macros you can use to block off areas of code that require specific OS 
versions.  For example:
#include 
#if defined(__MAC_10_12) && __MAC_OS_X_VERSION_MAX_ALLOWED >= __MAC_10_12
// code that requires the 10.12 or later SDK
#endif

—Rob



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Building for 10.12

[Rob Petrovec via Cocoa-dev]

> On Mar 18, 2022, at 1:11 PM, Gabriel Zachmann  wrote:
> 
>>> I am trying to build my app for macOS 10.12 (Sierra).
>>> 
>>> First of all, is it correct that I need to build it for "My Mac" , not do a 
>>> niversal build (Any Mac)?
>>  If you are only building to debug it then My Mac is fine. But if you 
>> are building to send out to customers then you want Universal.
> 
> So macOS 10.12 can "understand" universal builds?
There was a time when Universal meant a PowerPC & Intel binary.  Its 
been transformed to also mean Intel & Apple Silicon binaries.  I don’t remember 
if Universal (Intel & PPC) binaries are useful on 10.12 or not. But it wouldn’t 
hurt to help if its an option once you get the correct SDK installed.


>>  Make sure you have the 10.12 SDK installed in your Xcode.  To find out 
>> what OS SDK is installed in your selected Xcode run:
>> 
>>  xcodebuild -version -sdk macosx
>> 
> 
> Thanks a lot!
> 
> Here is the complete output:
> 
> % xcodebuild -version -sdk macosx
> 2022-03-18 20:09:43.281 xcodebuild[40530:14001720] Requested but did not find 
> extension point with identifier 
> Xcode.IDEKit.ExtensionSentinelHostApplications for extension 
> Xcode.DebuggerFoundation.AppExtensionHosts.watchOS of plug-in 
> com.apple.dt.IDEWatchSupportCore
> 2022-03-18 20:09:43.282 xcodebuild[40530:14001720] Requested but did not find 
> extension point with identifier 
> Xcode.IDEKit.ExtensionPointIdentifierToBundleIdentifier for extension 
> Xcode.DebuggerFoundation.AppExtensionToBundleIdentifierMap.watchOS of plug-in 
> com.apple.dt.IDEWatchSupportCore
> MacOSX12.3.sdk - macOS 12.3 (macosx12.3)
> SDKVersion: 12.3
> Path: 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk
> PlatformVersion: 12.3
> PlatformPath: 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
> ProductBuildVersion: 21E226
> ProductCopyright: 1983-2022 Apple Inc.
> ProductName: macOS
> ProductUserVisibleVersion: 12.3
> ProductVersion: 12.3
> iOSSupportVersion: 15.4
> 
> So, that means I do *not* have the 10.12 SDK , right?
Correct.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Building for 10.12

[Rob Petrovec via Cocoa-dev]

> On Mar 18, 2022, at 8:47 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I am trying to build my app for macOS 10.12 (Sierra).
> 
> First of all, is it correct that I need to build it for "My Mac" , not do a 
> niversal build (Any Mac)?
If you are only building to debug it then My Mac is fine. But if you 
are building to send out to customers then you want Universal.


> Second, I have been switching the scheme to build for "My Mac", but when I 
> archive it to notarize it and export it, I still get a universal app.
> What gives?
Thats what you want.  Why wouldn’t you want a universal app for 
customers to use?


> BTW: I have sent such a build to a beta tester using 10.12, but he gets the 
> error message 
>   "cannot be opened because of a problem".
Thats not enough information.  Did the app crash on launch?  If so, a 
crash log would be needed.


> PS:
> 
> I have, of course, switched the Deployment Target to 10.12,
> but I am working on macOS 12.1 and Xcode 13.3.
Make sure you have the 10.12 SDK installed in your Xcode.  To find out 
what OS SDK is installed in your selected Xcode run:

xcodebuild -version -sdk macosx

Good luck.

—Rob




> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSControl subclass and accessibility

[Rob Petrovec via Cocoa-dev]

Accessibility for NSControls is handled by the NSCell inside it, not the 
NSControl.  Good luck.

—Rob


> On Mar 13, 2022, at 7:55 AM, Eyal Redler via Cocoa-dev 
>  wrote:
> 
> Hi,
> 
> I'm having trouble getting a custom NSControl subclass properly visible with 
> regards to accessibility.
> 
> If I implement my custom control as an NSView subclass and adopt the 
> NSAccessibilityButton protocol, I can "see" my custom control with 
> accessibility inspector when I hover above it.
> If I take the same class but make it a subclass of NSControl, I'm not able to 
> "see" my control using accessibility inspector when hovering above it. It is 
> detecting something because I can see that when I hover in the containing 
> view, I can see the window ui element, but when I hover above the control 
> itself, I'm only seeing the "app" element. Also, when I inspect the 
> containing view I can see my control listed there and I can access it and 
> perform the action.
> 
> I feel like I'm missing something obvious. Any ideas?
> 
> Here's my code, If I replace NSControl with NSView, it seems to work great.
> 
> @interface MyFancyButton : NSControl 
> 
> @end
> 
> @implementation MyFancyButton
> - (void)drawRect:(NSRect)dirtyRect ...
> 
> - (void)mouseDown:(NSEvent *)event ...
> 
> - (void)simulateClick ...
> 
> 
> - (nullable NSString *)accessibilityLabel
> {
>   return @"my_label";
> }
> - (BOOL)accessibilityPerformPress
> {
>   [self simulateClick];
>   return YES;
> }
> @end
> 
> Thanks in advance,
> 
> 
> 
> 
> Eyal Redler
> 
> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
> way."
> --James Randi
> www.eyalredler.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Indexing broken for one project

[Rob Petrovec via Cocoa-dev]

Quit Xcode, delete the DerivedData directory for your project and re-open your 
project.  That should trigger a re-index and a full rebuild of your product.

The default location for the DerivedData directory is in 
~/Library/Developer/Xcode/DerivedData/-.  You can also configure it to be in your source directory, like I do, 
so you can keep your build products with your code.

Hope that helps.

—Rob


> On Feb 6, 2022, at 6:20 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> A few weeks ago, indexing in Xcode 13 stopped working for one of my projects.
> So, for instance, "Jump to Definition" does not work any more.
> I don't know what stopped indexing to work.
> 
> The project consists of objective-c source code.
> For other projects, indexing still works fine.
> 
> I have tried to delete Derived Data (which, in my case, is stored under /tmp).
> I have also tried to follow these instructions 
>  https://levelup.gitconnected.com/uncovering-xcode-indexing-8b3f3ff82551
> and perused the log file, but I could not see any error messages.
> 
> Any ideas what else I can try?
> Could it be something in the source code / header files?
> (The project compiles just fine, though.)
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: App can't be opened

[Rob Petrovec via Cocoa-dev]

The text in an error dialog is typically a washed down version of the actual 
error.  See if you can get the user to give you a sysdiagnose log, taken just 
after reproducing the problem, so you can check out the .logarchive to see what 
the actual error was from the system.  It should provide more insight into what 
the problem actually is.

btw, if you sent the app as a zip file you should double check the permissions 
on the app, including its bundle contents.  Your uid may not be the same has 
the users uid, so the privs could be set to not allow anyone but you to open 
it.  Thats why installers are better than sending the raw bits.

—Rob


> On Sep 9, 2021, at 7:13 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I have compiled my app for macOS 10.12, because one user runs macOS 10.13.
> 
> Now he reports that he gets the error message "app can't be opened due to a 
> problem"
> (the err message is in German, but I guess this is what it would say in 
> English.)
> 
> The error message does NOT say ".. unidentified developer"
> and it does NOT say ".. cannot check it for malicious software".
> 
> I have notarized my app using Xcode's Archive utility.
> I sent the user the app as a zip file - if you want , you can try it for 
> yourself:
> 
>https://owncloud.informatik.uni-bremen.de/index.php/s/9i3DCYodkgHZeZw
> 
> It goes without saying that I can run the app from that very zip file on my 
> Mac.
> 
> Does anyone have an idea what might be causing this funny error message?
> 
> Best, G.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableColumn width computation doesn't work correctly on macOS 11

[Rob Petrovec via Cocoa-dev]

> On Jun 25, 2021, at 2:40 PM, Andreas Falkenhahn via Cocoa-dev 
>  wrote:
> 
> On 25.06.2021 at 18:54 Carl Hoefs wrote:
> 
>> So I think it's safe to say that something has changed, and you're not 
>> fighting fantoms...
> 
> Do you think this should be reported to Apple or will nobody care because I'm 
> using deprecated APIs?
It wouldn’t hurt, but I doubt it will get much attention. if any, other 
than a reply saying to switch to non-deprecated API.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableColumn width computation doesn't work correctly on macOS 11

[Rob Petrovec via Cocoa-dev]

You are using deprecated cell based table views/API. I would advise switching 
to view based API (available in macOS 10.7 and newer).  Cell based was 
deprecated in 10.10 back in 2014.

With that said, I would create an NSTextFieldCell subclass (if you haven’t 
already) and stuff it into the text field for the row being truncated.  Then 
override:
- (NSSize)cellSizeForBounds:(NSRect)rect;
- (NSRect)imageRectForBounds:(NSRect)rect;
- (NSRect)titleRectForBounds:(NSRect)rect;

and see what they return on 10.13 & 11. -cellSize calls -cellSizeForBounds: 
which calls the other two methods to calculate the ideal size of the text field 
(including measuring width of the text).  Maybe that will give you some 
insight.  Good luck.

—Rob


> On Jun 25, 2021, at 8:22 AM, Andreas Falkenhahn via Cocoa-dev 
>  wrote:
> 
> I'm manually calculating the minimum size of my NSTableColumn to avoid text 
> ellipsization. The calculation looks like this:
> 
>   NSCell *cell = [m_view preparedCellAtColumn:m_column row:row];
> 
>   int width = ceil([cell cellSize].width);
> 
>   if(m_column == [m_view outlineTableColumn]) {
>  width += [m_view indentationPerLevel] * [m_view levelForRow:row];
>  width += m_expander;
>   }
> 
> The m_expander value is calculated like this:
> 
>   // assume that row 0 has an expander
>   NSRect rc = [m_view frameOfOutlineCellAtRow:0];
>   m_expander = ceil(rc.origin.x + rc.size.width);
> 
> This works nicely on 10.13. See here: https://imgur.com/w8uT4gu 
> 
> On macOS 11, however, the calculation is not correct and the text gets 
> ellipsized, see here: https://imgur.com/HiOBVjh 
> 
> Debugging has shown that m_expander is missing 4 pixels on macOS 11. On macOS 
> 10.13 rc.origin.x is 6 and rc.size.width is 12. On macOS 11, rc.origin.x is 2 
> and rc.size.width is 12. However, this seems to be correct because you can 
> see that the space to the left of the expander is smaller on macOS 11 than on 
> macOS 10.13 so the values look correct. All other values are identical 
> between 10.13 and 11. The column width computed by 10.13 is 169 and the 
> column width computed by macOS 11 is 165.
> 
> Still, as you can see, the overall column width calculation is not correct on 
> macOS 11 because the text gets ellipsized. Anybody got an idea what the 
> problem here is?
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Special question about NSOpenPanel

[Rob Petrovec via Cocoa-dev]

> (It goes without saying that on my system everything runs fine, both on macOS 
> 10.15.4 and macOS 11.3.1.)
Since the problem appears to happen on 10.15.0, but not 10.15.4 and 
newer, I would just chalk it up to a bug in the OS and ask your customer to 
update to at least 10.15.4.  I’m not aware of any compatibility issues between 
10.15.0 & 10.15.4, but stranger things have happened.
As a work around, if your customer refuses to update, you could provide 
your customer some way to set whatever thing you are using the result from the 
open panel for. You could set up a small helper app they can run, or a 
'defaults write xxx’ command or whatever.  Good luck.

>>> Didn’t we cover this a couple years ago? No, you can’t do anything other 
>>> than submit the problem to Apple and hope they do something about it.
The bug doesn’t happen on 10.15.4, so it was already fixed a long time 
ago.

—Rob


> On May 30, 2021, at 12:24 PM, Glenn L. Austin via Cocoa-dev 
>  wrote:
> 
>> On May 30, 2021, at 5:55 AM, Steve Mills via Cocoa-dev 
>>  wrote:
>> 
>>> On May 30, 2021, at 06:46, Gabriel Zachmann via Cocoa-dev 
>>>  wrote:
>>> 
>>> Thanks again for the hints.
>>> In the meantime I have found out that it seems like legacyScreenSaver under 
>>> macOS 10.15.0 does not have the right entitlements.
>> 
>> Didn’t we cover this a couple years ago? No, you can’t do anything other 
>> than submit the problem to Apple and hope they do something about it.
>> 
>> Steve via iPad
> 
> Your only option is to have a separate application that displays your 
> NSOpenPanel to set your preferences.
> 
> -- 
> Glenn L. Austin, Computer Wizard and Race Car Driver <><
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Special question about NSOpenPanel

[Rob Petrovec via Cocoa-dev]

To trigger a sysdiagnose: 

- reproduce the problem
- Hold down Shift-Control-Option-Command-‘.’ (period) for a few seconds
- After a couple minutes a Finder window will appear with a 
“sysdiagnose….tar.gz" archive pre-selected. You want that archive.
- Once you have the archive, uncompress it and open the system_logs.logarchive 
file in Console

All the logs will be in there.  You can use Console’s filtering features to 
narrow down to the process/logs you care about

—Rob


> On May 25, 2021, at 1:56 PM, Gabriel Zachmann  wrote:
> 
> Thanks a lot for the hint!
> 
> Is there an easy way to extract those logs?
> You know, I have to give the user simple instructions ...
> 
> Best regards, Gabriel
> 
> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Special question about NSOpenPanel

[Rob Petrovec via Cocoa-dev]

AppKit is pretty good at logging failures like this.  I would look for messages 
in the system.logs (or better yet from a sysdiagnose archive) from your process 
as well as com.apple.appkit.xpc.openAndSavePanelService (the process that 
actually shows the open/save panel).  See if there are any logs around the time 
of the failure that could shed some light on what happened.  Good luck.

—Rob



> On May 25, 2021, at 1:06 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Yes, I am suspecting a bug in macOS , too, since exactly the same code works 
> fine under 10.15.2+
> Problem is, though, that the user says he cannot upgrade his macOS 10.15.0 to 
> something higher.
> (don't know why)
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Exception not being caught in try statement

[Rob Petrovec via Cocoa-dev]

Don’t forget to include a sample app that demonstrates the problem.

—Rob



> On Mar 26, 2021, at 12:02 PM, Gary L. Wade via Cocoa-dev 
>  wrote:
> 
> Try surrounding the call with beginEditing and endEditing on the text 
> storage. If it still happens, submit a feedback to Apple with the full crash 
> log.
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Mar 26, 2021, at 4:11 AM, Mark Allan via Cocoa-dev 
>>  wrote:
>> 
>> Hi folks,
>> 
>> Some users are reporting a crash that I can't reproduce, and in an attempt 
>> to gain additional diagnostics from a user, I wrapped the affected line in a 
>> try/catch block.  For two users it resolve the crash, but for a third, it's 
>> still crashing at the same point!
>> 
>> The crash occurs when a user attempts to open the "About" window from my 
>> app's main menu item. I'm not using the standard about panel as there's a 
>> few additional items I need to display, one of which is an NSTextView which 
>> I populate with the contents of an RTF file from within the app bundle.
>> 
>> I've symbolicated the crash log to find it's happening when populating that 
>> TextView. The line in question now reads as follows:
>> 
>>   @try {
>>   [self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle mainBundle] 
>> pathForResource:@"Credits" ofType:@"rtf"]];
>>   } @catch (NSException *exception) {
>>   NSLog(@"Error loading the contents of the text file for the About Box. 
>> %@", exception);
>>   //Check we have a file at the expected path 
>>   if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle 
>> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
>>   NSLog(@"Yes. Found the RTF credits file");
>>   // check the attributes in case somehow there's no permission to 
>> read the file
>>   NSDictionary *fileAttributes =[[NSFileManager defaultManager] 
>> attributesOfItemAtPath:[[NSBundle mainBundle] pathForResource:@"Credits" 
>> ofType:@"rtf"] error:nil];
>>   NSLog(@"RTF file has following attributes %@", fileAttributes);
>>   }
>>   else {
>>   NSLog(@"Nope, file not found");
>>   }
>>   }
>> 
>> This is the crash log from the newest build (with the try/catch around that 
>> line):
>> 
>>> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540
>>> *** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
>>> reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
>>> terminating with uncaught exception of type NSException
>>> abort() called
>>> 
>>> Application Specific Backtrace 1:
>>> 0   CoreFoundation  0x7fff206ea6af 
>>> __exceptionPreprocess + 242
>>> 1   libobjc.A.dylib 0x7fff204223c9 
>>> objc_exception_throw + 48
>>> 2   CoreFoundation  0x7fff2079ea9a -[__NSCFString 
>>> characterAtIndex:].cold.1 + 0
>>> 3   CoreFoundation  0x7fff2079c953 -[__NSArrayM 
>>> insertObject:atIndex:].cold.2 + 0
>>> 4   CoreFoundation  0x7fff20610421 -[__NSArrayM 
>>> insertObject:atIndex:] + 1135
>>> 5   UIFoundation0x7fff23c223ab 
>>> __defaultTabStops_block_invoke + 161
>>> 6   libdispatch.dylib   0x7fff203cd7c7 
>>> _dispatch_client_callout + 8
>>> 7   libdispatch.dylib   0x7fff203ce96b 
>>> _dispatch_once_callout + 20
>>> 8   UIFoundation0x7fff23c229d7 
>>> -[NSMutableParagraphStyle setTabStops:] + 199
>>> 9   UIFoundation0x7fff23c3c697 -[NSRTFReader 
>>> defaultParagraphStyle] + 75
>>> 10  UIFoundation0x7fff23c3c5be -[NSRTFReader 
>>> _mutableParagraphStyle] + 112
>>> 11  UIFoundation0x7fff23c36113 controlClass + 
>>> 1757
>>> 12  UIFoundation0x7fff23c356b4 -[NSRTFReader 
>>> attributedString] + 76
>>> 13  UIFoundation0x7fff23c311a6 
>>> _NSReadAttributedStringFromURLOrData + 3213
>>> 14  UIFoundation0x7fff23d46985 
>>> -[NSAttributedString(NSAttributedStringUIFoundationAdditions) 
>>> initWithURL:options:documentAttributes:error:] + 228
>>> 15  AppKit  0x7fff23677d9a -[NSTextView 
>>> readRTFDFromFile:] + 126
>>> 16  MyAppHere 0x000105fa18a7 MyAppHere+ 
>>> 227495
>>> 17  AppKit  0x7fff230af7fd 
>>> -[NSApplication(NSResponder) sendAction:to:from:] + 283
>>> 18  AppKit  0x7fff231b2611 -[NSMenuItem 
>>> _corePerformAction] + 413
>> 
>> 
>> Any ideas what's going on? Other than the file not being found, why else 
>> might the object at line 3 in the backtrace be nil...and more interestingly, 
>> why is the exception not being caught?
>> 
>> Thanks
>> Mark
> 
> ___
> 
> Cocoa-dev mailing 

Re: fileManagerWithAuthorization:

[Rob Petrovec via Cocoa-dev]

That error message is less than helpful.  Does the current user have 
permissions to write to that directory, let alone to the file being replaced?  
if not, no amount of entitlements will let you do what you want.

—Rob



> On Mar 14, 2021, at 3:43 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> I’ve tried something like the code below to save a file not owned by current 
> user.
> 
> I have codesigned the application using hardened runtime and the 
> `com.apple.developer.security.privileged-file-operations` entitlement 
> (although this is outside App Store and no sandboxing).
> 
> It doesn’t work and I see this error in the console: 
> `(libsystem_secinit.dylib) com.apple.secinitd.fileoperations: 
> xpc_pipe_routine() returned [5: Input/output error]`
> 
> Does anyone know if, when, or how it is supposed to work?
> 
>[NSWorkspace.sharedWorkspace 
> requestAuthorizationOfType:NSWorkspaceAuthorizationTypeReplaceFile 
> completionHandler:^(NSWorkspaceAuthorization* authorization, NSError* error){
>   if(authorization) {
>  if([[NSFileManager fileManagerWithAuthorization:authorization] 
> replaceItemAtURL:originalURL withItemAtURL:tempURL backupItemName:nil 
> options:0 resultingItemURL:nil error:]) {
> …
>  }
>  …
>   }
>   …
>}];
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Bug reporting again.

[Rob Petrovec via Cocoa-dev]

Yes, Ben is correct.  One thing to note, when you report the bug if you can 
supply a test project showing the behavior in Obj-C and another project showing 
the behavior in Swift that would likely give this bug a lot more traction.  
Good luck.

—Rob


> On Nov 22, 2020, at 2:08 PM, Ben Kennedy via Cocoa-dev 
>  wrote:
> 
> 
>> On 22 Nov 2020, at 12:45 pm, Alex Zavatone via Cocoa-dev 
>>  wrote:
>> 
>> I’ve found a bug in Swift’s loadView for UIViewController on iOS that I’d 
>> like to report.  Swift.org tells us to use https://bugreport.apple.com which 
>> returns  “bugreport.apple.com’s server IP address could not be found.”.
> 
> Apple replaced Bug Reporter with Feedback Assistant months ago: 
> https://developer.apple.com/bug-reporting/
> 
> The web site you're looking for is https://feedbackassistant.apple.com.
> 
> -ben
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSScrollView's custom content inset

[Rob Petrovec via Cocoa-dev]

No problem.  Looks like a bug about to clarify the documentation is in order.

—Rob



> On Nov 5, 2020, at 2:35 PM, Dragan Milić via Cocoa-dev 
>  wrote:
> 
>> čet 05.11.2020., at 20:57, Rob Petrovec wrote:
>> 
>> Check out NSTableViewStylePlain
> 
> Yes Rob, that was it, thanks a lot!! And now I feel quite stupid, trying all 
> complicated things (described in my second message), while it’s so very 
> simple :-)
> 
> To my defence, that value stands somehow apart, both in documentation and in 
> IB, so it looked like some deprecated value to me. Additionally, I was paying 
> attention to that page I posted (changes in macOS 11.0), where it says the 
> padding is present regardless of the tableView style, so I never checked that 
> value.
> 
> Thanks again!!
> -- Dragan
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSScrollView's custom content inset

[Rob Petrovec via Cocoa-dev]

Check out NSTableViewStylePlain

—Rob



> On Nov 5, 2020, at 12:28 PM, Dragan Milić via Cocoa-dev 
>  wrote:
> 
> Hi all,
> 
> What would be the best approach to set custom insets of the contentView 
> (NSClipView) of a NSScrollView? I’ll try to describe the problem in more 
> details…
> 
> I’m trying to make and application look nice on upcoming Big Sur. The fact 
> that Apple has made it so hard for an application (with reasonably 
> complicated UI) to look good on both Bit Sur and older OS version is a topic 
> for some other rant thread… Anyway, I’m trying to get rid of some unwanted 
> NSTableView properties, introduced in Bit Sur.
> 
> I’ve got a NSTableView with a single column. Cells (NSView based) in that 
> single column show some custom content, mostly custom view full of custom 
> Core Text drawing and colouring. It’s very important (visually appealing) if 
> that custom content is stretched through the whole width of the table
> 
> -- Dragan
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSAlert runModal in outlineView:acceptDrop crashes with may not be invoked inside of transaction begin/commit pair

[Rob Petrovec via Cocoa-dev]

PLEASE PLEASE PLEASE don’t put up a modal dialog in the middle of a drag.  All 
drags are done on the main thread. This includes calls to NSDraggingSource, 
NSDraggingDestination, NSFilePromiseProvider, NSFilePromiseReceiver methods and 
drag methods from NSTableView/NSOutlineVIew & NSCollectionView. In some cases, 
when the drag is between two apps, the other app involved in the drag may be 
waiting for a response and is therefor blocked until your method returns. If 
your implementation of these drag methods takes too long then both your app and 
the other app involved can SPOD. To avoid this, try to perform any operations 
that can take some time, like reading/writing to disk, asynchronously off the 
main thread. If that is not an option (e.g. bringing up modal dialogs), 
performing the operation after the drag method has returned will work too. You 
can use methods like [self performSelector: … afterDelay: 0] to achieve this. 
However, this will prevent the other app in the drag from SPOD’ing, your app 
may still SPOD. So take that into consideration when choosing a technique to 
fix this.

As for the problem you are asking about, the transactions its talking about 
sound like CoreAnimation transactions dealing with drawing.  I wouldn’t expect 
the outline view drag call to be inside of one of those unless you are 
overriding something to add one.

—Rob


> On Oct 31, 2020, at 6:24 AM, Michael Kloske via Cocoa-dev 
>  wrote:
> 
> Hello,
> 
> I have an OutlineView. Whenever I drag and drop a child item within the 
> Outline-View my application crashes when I open do an "NSAlert runModal" like 
> in the code below:
> 
> - (BOOL)outlineView:(NSOutlineView *)outlineView acceptDrop:(id < 
> NSDraggingInfo >)info item:(id)item childIndex:(NSInteger)index
> {
> ...
> 1if(needToAskUser)
>  {
> 2NSAlert *alert = [[NSAlert alloc] init];
> 3// .. set some texts and buttons in alert
> 4   [alert runModal];
>  }
> }
> 
> In line 4 the app crashes with the following uncaught exception:
> [General] -[NSAlert runModal] may not be invoked inside of transaction 
> begin/commit pair, or inside of transaction commit (usually this means it was 
> invoked inside of a view's -drawRect: method.)
> 
> I have a tree like this:
> Top Level 1
>   - Child Item A
>   - Child Item B
> Top Level 2
>   - Child Item C
> ...
> 
> The problem occurs only, when I drag one of the Child Items within the same 
> view. It does not matter whether I move Child Item A below Child Item B or if 
> I move it to another Top Level item, for example below Child Item C.
> 
> Moving the block into a call to dispatch_async(dispatch_get_main_queue(), ^{ 
> }); did also not help.
> 
> Has anyone any idea what the problem is?
> Best regards,
> Michael Kloske
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to parse a log file

[Rob Petrovec via Cocoa-dev]

> On Oct 26, 2020, at 10:00 PM, Steven Mills via Cocoa-dev 
>  wrote:
> 
> 
>> On Oct 26, 2020, at 17:49:59, James Walker via Cocoa-dev 
>>  wrote:
>> 
>> I don't see any "Download Debug Symbols" in the Organizer.  I don't think it 
>> exists for macOS apps.
>> 
>> However, one can right-click on an archive and select "Show In Finder", then 
>> once in Finder right-click again and Show Package Contents, and drill down 
>> to find dSyms.  (Usually just one, but if your app builds with a private 
>> framework, there could be more.)
> 
> Yes, Apple needs to remember when writing docs that not all apps are for 
> mobile! I have to refer to that doc every time I get a user crashlog, once or 
> twice a year, and it always take the same amount of time to figure out what 
> they're talking about. I really hope they make this a more automatic feature 
> in Xcode: Open the project, open a crashlog, choose a menu item to 
> symbolicate, and let Xcode do the confusing part about loading the dsym from 
> the archives.
While I agree this would be a good thing to have, I don’t see how Xcode 
could find the dSYM to use given that they are typically ephemeral.  The dSYM 
is tied to the build.  So if you build your project twice you will have two 
different dSYMs. Only the dSYM for the build that generated the crash log file 
will be able to symbolicate it.  So, if you want to symbolicate your crash logs 
you need to save your dSYM files & resulting app bundle somewhere for each 
build of your app you publish.  Then you can use them to symbolicate user logs.
What Xcode could do, however, is (given a path to a directory 
containing all the dSYMs for your published builds) parse the log to figure out 
which dSYM/app bundle pair in the directory to use (probably based on build 
info and/or version) and symbolicate.  You would also need to take the 
additional step of properly updating these values in your project for each 
published build.

Either way, that sounds like a reasonable request to make. You should 
write up a bug report and send it to Apple.

—Rob


> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: How to reposition subviews without Auto Layout

[Rob Petrovec via Cocoa-dev]

As was pointed out by an earlier reply, even if you use -layout or 
setAutoresizingMask you are still using auto layout. The frame changes get 
converted to auto layout constraints under the hood.  If you said “without 
using Autolayout API” that would be more correct.

—Rob


> On Oct 17, 2020, at 9:46 AM, Andreas Falkenhahn via Cocoa-dev 
>  wrote:
> 
> Thanks, out of curiosity I've tried to override the "layout" method and see 
> if it works and it indeed does. So it looks like simply overriding the 
> "layout" method and doing the positioning and sizing there is also possible 
> without using any Auto Layout features whatsoever...
> 
> On 17.10.2020 at 16:30 Richard Charles wrote:
> 
>> You could call this method on your three views.
> 
>> -[NSViewView setAutoresizingMask:]
> 
>> --Richard Charles
> 
> 
>>> On Oct 17, 2020, at 6:57 AM, Andreas Falkenhahn via Cocoa-dev 
>>>  wrote:
> 
>>> Hi,
> 
>>> I have an NSView that I set as the content view of my NSWindow. The NSView 
>>> has three subviews. Where should I reposition and resize those three 
>>> subviews when the NSWindow size changes? 
> 
>>> I see that NSView has a "layout" method that can be overridden but AFAIU 
>>> this is only to be used for Auto Layout. I don't want to use Auto Layout 
>>> because my whole layout is very simplistic and just involves those three 
>>> subviews which I can easily position and size manually. I just need to know 
>>> where to put the code that sets their new position and size... anyone?
> 
>>> -- 
>>> Best regards,
>>> Andreas Falkenhahn
> 
> 
> 
> 
> -- 
> Best regards,
> Andreas Falkenhahnmailto:andr...@falkenhahn.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: App store question regarding Big Sur

[Rob Petrovec via Cocoa-dev]

I don’t know the answer to your question.  However,I would move your time table 
up significantly on testing your app with Big Sur if I were you.  There are a 
lot of changes in Big Sur that will definitely effect your app.  Most notably 
drastic UI changes, not to mention the API & behavior changes that come with 
all new releases.

—Rob


> On Sep 18, 2020, at 5:43 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I've got an app on the Mac app store (MAS) which works under Catalina.
> 
> My question is: when Big Sur becomes official,
> will my app also show up in the MAS for people who's Mac runs under Big Sur?
> 
> I'm asking because I haven't had the time to test my app under Big Sur, yet,
> and I probably won't have time until early next year.
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Finding all paths to copies of app ?

[Rob Petrovec via Cocoa-dev]

You want LSCopyApplicationURLsForBundleIdentifier

—Rob


> On Jul 16, 2020, at 6:24 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Is there a way to find the paths/URLs to all app bundles that have the same 
> bundle ID?
> 
> I have a user who likes to make duplicates of my app (it does make sense, to 
> some extent).
> So, in my launcher app, I'd like to to launch all of these copies.
> 
> I have checked the docs on NSWorkspace and the doc for urlForApplication(),
> but AFAICT they will just pick one of the copies.
> 
> On the web I found this solution:
> mdfind "kMDItemCFBundleIdentifier == 'com.domain.coolapp'"
> 
> I was wondering if there is a simpler solution that would not require 
> launching a Process and parsing its output.
> 
> Thanks a lot in advance.
> 
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Points vs pixels in a bash script

[Rob Petrovec via Cocoa-dev]

I don’t have an answer to your question, but to add some clarity Points are 
scale factor independent unit of measurement.  On a retina display there are 2 
pixels per point.  On a non-retina display there is 1 pixel per point.  Say 
Apple comes out with a display with a scale factor of 17.  That would mean that 
there are 17 pixels per point.  Hope that helps.

—Rob



> On Jun 8, 2020, at 3:43 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I know this mailing list might not be the perfect fit for my question,
> but maybe someone has an idea.
> 
> I have a problem converting points (I think) to pixels in a bash script.
> I'd rather not write an extra C/Cocoa utility for that.
> 
> Using
>   system_profiler SPDisplaysDataType
> I can retrieve the size of a Mac's display in pixels. 
> 
> However, the command
> 
>   tell application "System Events" to get the size of every window of every 
> process
> 
> (which I execute from my bash script using osascript) apparently does NOT 
> return window sizes in pixels. I guess it's the strange "Apple points" units. 
> According to my experiments, on my MacBook Pro Retina, for instance, a 
> fullscreen app (e.g., Keynote presentation) has a window size of 1680 x 1050.
> By contrast, system_profiler reports 2880 x 1800.
> 
> So, the question is: how can I determine the screen size of a Mac from my 
> bash script in the same units like "System Events" uses? 
> Or, how can I determine the factor by which I have to convert pixels into 
> those other units?
> 
> 
> Many thanks in advance for any insights or hints.
> 
> Best regards, Gabriel
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Localization under Catalina

[Rob Petrovec via Cocoa-dev]

> On May 27, 2020, at 2:37 PM, Martin Wierschin  wrote:
> 
>> Auto layout (not auto-resizing) is independent of localization.  You don’t 
>> need to switch to auto layout to support Base localization
> 
> It's true that autolayout has many benefits aside from localization. But I'd 
> say it's only partially true that you can switch to Base.lproj for 
> localization without converting to autolayout. 
> 
> Without autolayout the translated text from your strings files probably won't 
> look very good injected into your Base UI. You might be able to finagle it if 
> you use certain control placements, or make your controls really wide so 
> longer translated text doesn't overlap adjacent controls and that kind of 
> thing, but it's going to be awkward and finicky. Autolayout is really the key 
> to making a single set of source xibs from Base.lproj work for all 
> localizations.
True.  I had forgotten about different length strings in different 
locs.  I switched to auto layout & base loc years ago, so my memory is a little 
rusty on the conversion process. 

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Localization under Catalina

[Rob Petrovec via Cocoa-dev]

Auto layout (not auto-resizing) is independent of localization.  You don’t need 
to switch to auto layout to support Base localization.  So you can convert your 
nibs over to Base Localization with a couple clicks in Xcode, and then you just 
need .strings and .stringdict files in your .lprojs instead of a TON of 
duplicate .nibs that constantly need updating.  If you make a change in the 
base nib all the localizations will pick it up.

With that said, Auto Layout is leaps & bounds better than the old autoresizing 
mask stuff.  Make sure you read & understand the auto layout documentation 
before starting of course.  But once you do convert over you will wish you had 
done it earlier.  It is SO much better.  Plus it handles positioning views 
automagically between Left-To-Right localizations like English and 
Right-To-Left localizations like Hebrew.

—Rob


> On May 27, 2020, at 1:26 PM, Eyal Redler via Cocoa-dev 
>  wrote:
> 
> AppleGlot used to work fine for me but I agree, I should move to Base.lproj 
> etc. But now I need to ship a new version of the app and I can't really 
> afford to spend the time converting everything to auto-resizing.
> I foolishly upgraded to Catalina only this week, and this put me in a very 
> delicate situation.
> 
> Eyal
> 
>> On 27 May 2020, at 22:14, Martin Wierschin  wrote:
>> 
>> I remember AppleGlot. I also remember how terrible it was, at least way back 
>> when it was first around. In the intervening years I preferred loc-suite. As 
>> Georg said, it's a very good tool. But all that's obsolete now.
>> 
>> You ultimately should convert your nibs to Base.lproj. The current Xcode 
>> localization process is way better than the bad old days where you had to 
>> keep endless translated nibs in sync. The conversion job is a good amount of 
>> busy work, and autolayout may give you pain initially, but ultimately using 
>> Base.lproj + autolayout + translated .strings files is much cleaner.
>> 
>> ~Martin Wierschin
>> Nisus Software / Developer
>> Solana Beach ☀️ California
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Is CGImage... thread-safe?

[Rob Petrovec via Cocoa-dev]

> On May 27, 2020, at 1:08 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
>>> 
>>> I've just had a crash in
>>> CGImageSourceCreateThumbnailAtIndex( new_image, 0, imageOpts );
>> 
>> We went through this quite a while ago in private emails. 
>> CGImageSourceCreateThumbnailAtIndex is fine to use from any thread. Are you 
>> sure the image source even has an image at index 0? Not all do. What's the 
>> crashed stack look like?
> 
> I can't recall/reproduce, but it was definitely *inside* 
> CGImageSourceCreateThumbnailAtIndex().
> 
> If there is no image a tinder 0, shouldn't it just return NULL gracefully?
There can be valid arguments going either way.  If you think it’s 
acting inappropriately I’d suggest filing a bug with Apple.  

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Localization under Catalina

[Rob Petrovec via Cocoa-dev]

I have never used AppleGlot.  However, I’m curious why you don’t set up a 
.lproj for each localization you support containing .strings files with your 
translated strings inside?

—Rob


> On May 27, 2020, at 10:04 AM, Eyal Redler via Cocoa-dev 
>  wrote:
> 
> Hi,
> 
> It looks like Apple has dropped support for AppleGlot under Catalina. The 
> latest version (from 2017) will not install on Catalina and links and 
> mentions to AppleGlot have been removed from their localisation page 
> (https://developer.apple.com/localization/).
> 
> It looks like Apple wants us to use Xcode's localisation tools which is OK 
> but it doesn't seem to address at all the issue of incremental localization, 
> my app is already localized in 14 languages and I just need to add the new 
> strings/nibs and update the changed nibs, not create a localisation from 
> scratch.
> 
> I think that for now I'll switch back to Mojave to build this localisation 
> using my workflow with AppleGlot but it would be great if I could run 
> AppleGlot on Catalina, was anyone successful in doing that?
> Also, is there some support for incremental localisation using the xcode 
> localization tools? Maybe I'm missing something here
> 
> Thanks,
> 
> 
> Eyal Redler
> 
> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
> way."
> --James Randi
> www.eyalredler.com
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

> On May 22, 2020, at 8:42 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
> 
>> If what you say is correct then everyone would be seeing a delay since most 
>> people don’t have blazing fast internet connections.  I do not think this is 
>> the normal behavior.  I think it is specific to your system, otherwise there 
>> would be TONS of people complaining about slowness.
> 
> Episode 379 of ATP has just been released and both Marco Arment and John 
> Siracusa are complaining about significant delays after upgrading to macOS 
> 10.15, though for John Siracusa I think only one of his machines has the 
> problem.
> 
> Also, I think I already mentioned it, but I had a friend of mine run tests on 
> his machine in another geographical zone, and he saw delays as well.
> 
>> Either way, did you file a bug with a sysdiagnose taken during the delay?  
>> If so, do you have the bug number?
> 
> Several people in this thread were asking for bug numbers: I do not 
> understand this, no-one outside of Apple can read these bugs, right?
Correct, however, you are presuming that no apple engineers reads this 
mailing list. That would be an incorrect assumption.

—Rob




___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Finding memory leaks

[Rob Petrovec via Cocoa-dev]

Yes, there is more than one way to skin a cat.  Use whatever methods work for 
you.  But keep in mind that your experiences may not be the same as others 
because your code base is obviously going to be different.  So I would not 
recommend avoiding one tool over another just because it didn’t work for you.  
It just might work for someone else.

—Rob


> On May 20, 2020, at 2:44 PM, Alex Zavatone  wrote:
> 
> For iOS, I’ve found that setting up a test to replicate the memory leak, or 
> simply running tests is a great idea.  Here’s where Instruments sucks.  
> Running on the Simulator, Instruments often drops the connection to the 
> target.  Also, I’ve gotten Instruments files that are 30 GB, while just 
> setting a breakpoint in a test and invoking the memory graph debugger lets 
> you see the relationship between objects and save a .memgraph document so 
> that you can open it again.
> 
> Here are some of the horror stories caused by my former team.
> 
> We had 1400 of them.
> 
> https://imgur.com/Pq0eEkf <https://imgur.com/Pq0eEkf>
> https://imgur.com/mavOyOT <https://imgur.com/mavOyOT>
> https://imgur.com/3mnRUa1 <https://imgur.com/3mnRUa1>
> https://imgur.com/4nksFco <https://imgur.com/4nksFco>
> 
> So much easier than walking the stack backtrace, but when you enable logging 
> in the scheme Diagnostics, you also have your stack backtrace, so you can see 
> where objects have multiple references causing the retain cycles and examine 
> the backtrace if you want to.
> 
> Simply select the object and the backtrace is in the right Inspector pane.
> 
> - Alex Zavatone
> 
>> On May 20, 2020, at 2:58 PM, Rob Petrovec > <mailto:petr...@mac.com>> wrote:
>> 
>> I’ve had a lot of success with Instruments leaks traces.  In the 
>> retain/release world we live in, knowing the backtrace to where the object 
>> was created isn’t enough.  Instruments gives a nice UI to walk the 
>> retain/release history of an object, and the backtrace of each 
>> retain/autorelease/release.  Using a memgraph as Alex suggested is also 
>> good, but can sometimes be hard to parse when the map is HUGE!  Either way, 
>> both Instruments and memgraphs are tools you should definitely learn & use.
>> 
>> My only real gripe is that both Instruments & memgraphs don’t handle C++ 
>> objects very well.  It would be nice if they understood shared_ptr & 
>> unique_ptr.
>> 
>> —Rob
>> 
>> 
>>> On May 20, 2020, at 9:16 AM, Alex Zavatone via Cocoa-dev 
>>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> Also, in your run scheme, enable the Diagnostics for Logging > Malloc Stack 
>>> > Live Allocations Only.
>>> 
>>>> On May 20, 2020, at 10:08 AM, Georg Seifert via Cocoa-dev 
>>>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>>> 
>>>> You need to check the backtrace where the leaking object was created. 
>>>> Sometimes it points to a line that has nothing to do with the leak, it is 
>>>> just triggering it.
>>>> 
>>>> g
>>>> 
>>>>> On 20.05.2020, at 16:03, Gabriel Zachmann via Cocoa-dev 
>>>>> mailto:cocoa-dev@lists.apple.com> 
>>>>> <mailto:cocoa-dev@lists.apple.com <mailto:cocoa-dev@lists.apple.com>>> 
>>>>> wrote:
>>>>> 
>>>>> I have a few stupid questions regarding (potential) memory leaks,
>>>>> so please bear with me.
>>>>> First of all, my code is ARC managed.
>>>>> 
>>>>> I tried the Leaks tool of Instruments.
>>>>> 
>>>>> It tells me, if i understand correctly, that I have a leak at this line 
>>>>> of my code:
>>>>> 
>>>>> CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex( 
>>>>> new_image, 0, NULL ); 
>>>>> 
>>>>> This line is in a method I declared like that:
>>>>> 
>>>>> - (void) loadNextImageWithIndex: (unsigned long) next_index image: 
>>>>> (CGImageRef *) next_image
>>>>>   withProps: (CFDictionaryRef *) next_props
>>>>> 
>>>>> and at the end of the function, I pass fileProps back like so
>>>>> 
>>>>> *next_props = fileProps;
>>>>> 
>>>>> The caller then makes a copy of next_props for later use, and CFRelease's 
>>>>> next_props.
>>>>> (That copy is also released later.)
>>>>> 
>>>>> So it is uncl

Re: Finding memory leaks

[Rob Petrovec via Cocoa-dev]

I’ve had a lot of success with Instruments leaks traces.  In the retain/release 
world we live in, knowing the backtrace to where the object was created isn’t 
enough.  Instruments gives a nice UI to walk the retain/release history of an 
object, and the backtrace of each retain/autorelease/release.  Using a memgraph 
as Alex suggested is also good, but can sometimes be hard to parse when the map 
is HUGE!  Either way, both Instruments and memgraphs are tools you should 
definitely learn & use.

My only real gripe is that both Instruments & memgraphs don’t handle C++ 
objects very well.  It would be nice if they understood shared_ptr & unique_ptr.

—Rob


> On May 20, 2020, at 9:16 AM, Alex Zavatone via Cocoa-dev 
>  wrote:
> 
> Also, in your run scheme, enable the Diagnostics for Logging > Malloc Stack > 
> Live Allocations Only.
> 
>> On May 20, 2020, at 10:08 AM, Georg Seifert via Cocoa-dev 
>>  wrote:
>> 
>> You need to check the backtrace where the leaking object was created. 
>> Sometimes it points to a line that has nothing to do with the leak, it is 
>> just triggering it.
>> 
>> g
>> 
>>> On 20.05.2020, at 16:03, Gabriel Zachmann via Cocoa-dev 
>>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> I have a few stupid questions regarding (potential) memory leaks,
>>> so please bear with me.
>>> First of all, my code is ARC managed.
>>> 
>>> I tried the Leaks tool of Instruments.
>>> 
>>> It tells me, if i understand correctly, that I have a leak at this line of 
>>> my code:
>>> 
>>>  CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex( new_image, 
>>> 0, NULL ); 
>>> 
>>> This line is in a method I declared like that:
>>> 
>>> - (void) loadNextImageWithIndex: (unsigned long) next_index image: 
>>> (CGImageRef *) next_image
>>>withProps: (CFDictionaryRef *) next_props
>>> 
>>> and at the end of the function, I pass fileProps back like so
>>> 
>>> *next_props = fileProps;
>>> 
>>> The caller then makes a copy of next_props for later use, and CFRelease's 
>>> next_props.
>>> (That copy is also released later.)
>>> 
>>> So it is unclear to me why the Leaks tool thinks that the above line leaks 
>>> memory.
>>> 
>>> 
>>> 
>>> Another area of questions is around CALayer's and images.
>>> I create images like so:
>>> 
>>>  CGImageRef newImageRef = CGImageSourceCreateThumbnailAtIndex( new_image, 0,
>>> (__bridge 
>>> CFDictionaryRef) imageOpts );
>>> I store newImageRef in an array (history_of_images).
>>> Then, I assign newImageRef to a CALayer like this:
>>> 
>>>  imgLayer.contents = (__bridge id)(newImageRef);
>>> 
>>> At some point later, when the layer is no longer part of the layer 
>>> hierarchy, I release it like this:
>>> 
>>> CGImageRelease( history_of_images[k].img );
>>> 
>>> Can you spot any point in this sequence where there could be a memory leak?
>>> Does any of the assignments I described create a copy?
>>> Should I release CALayer's myself after I have removed it from its super 
>>> layer?
>>> By the growth of the memory usage of my app I suspect that the images I've 
>>> been loading keep lingering on somewhere in memory.
>>> 
>>> 
>>> Another area of questions centers around dispatch queues.
>>> The above stuff (loading, thumbnail creation) is, mostly, done in a 
>>> background thread via dispatch_async.
>>> I have tried to put an @autoreleasepool around the code that runs in the 
>>> background thread, to no avail.
>>> (My code is under ARC.)
>>> 
>>> But in Instruments, all indications (e.g., Heaviest stack trace) point to 
>>> CGImageSourceCreateThumbnailAtIndex, that shows a stack trace like that:
>>> 
>>> 13 libdispatch.dylib  269.42 KB _dispatch_client_callout
>>> 12 ArtSaverApp  269.42 KB -[ArtSaverView loadNextImage] 
>>> /Users/zach/Code/ArtSaver/ArtSaverView.m:2045
>>> 11 ArtSaverApp  269.42 KB -[ArtSaverView 
>>> loadNextImageWithIndex:image:withProps:] 
>>> /Users/zach/Code/ArtSaver/ArtSaverView.m:2083
>>> 10 ImageIO  248.44 KB CGImageSourceCopyPropertiesAtIndex
>>> 9 ImageIO  248.44 KB IIOImageSource::copyPropertiesAtIndex(unsigned 
>>> long, IIODictionary*)
>>> 8 ImageIO  248.30 KB 
>>> IIOImageSource::getPropertiesAtIndexInternal(unsigned long, IIODictionary*)
>>> 7 ImageIO  244.78 KB IIOImageSource::makeImagePlus(unsigned long, 
>>> IIODictionary*)
>>> 6 ImageIO  100.08 KB 
>>> IIO_Reader_AppleJPEG::initImageAtOffset(CGImagePlugin*, unsigned long, 
>>> unsigned long, unsigned long)
>>> 5 ImageIO   97.58 KB IIOReadPlugin::callInitialize()
>>> 4 ImageIO   93.64 KB AppleJPEGReadPlugin::initialize(IIODictionary*)
>>> 3 ImageIO   52.00 KB AppleJPEGReadPlugin::appleJPEGDecodeSetup()
>>> 2 AppleJPEG   52.00 KB applejpeg_decode_create
>>> 1 libsystem_malloc.dylib   52.00 KB malloc
>>> 0 libsystem_malloc.dylib   52.00 KB malloc_zone_malloc
>>> 
>>> (ArtSaverApp is, of course, my code.)
>>> Similar backtraces show up when I click on 

Re: Concurrent loading of images ?

[Rob Petrovec via Cocoa-dev]

> On May 8, 2020, at 12:19 PM, Jens Alfke via Cocoa-dev 
>  wrote:
> 
> 
> 
>> On May 8, 2020, at 9:53 AM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> So, I was thinking, maybe it helps to load the next image concurrently, 
>> while the current one is still being displayed.
> 
> Sure. Just be aware that if you're using NSImage, simply loading an NSImage 
> does not rasterize it; the class tries to be 'lazy' about doing work. So your 
> background task should explicitly render it, e.g. into an NSBitmapImageRep.
> 
>> I also read about the GCD's dispatch queues, but it seems to me that this 
>> would not be the suitable approach since I always only have one task running 
>> concurrently to the main thread.
> 
> Why not? Dispatch queues are always available. (The main thread is simply a 
> special queue.) You can run the background task by creating a single dispatch 
> queue and then using dispatch_async to call a block that does the work. The 
> end of the block would call dispatch_async back to the main queue and pass 
> the image as a parameter.
I second the use of GCD.  Its also considerably simpler than NSThread, 
NSOperationQueue/NSOperation et al.  This is the kind of operation that GCD was 
invented for.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Xcode Build Location

[Rob Petrovec via Cocoa-dev]

Have you considered using a workspace to handle building all of your individual 
projects?  That should solve your file path & linking problem.

btw, the 28 character string is a UUID.  I’m not sure about its lifetime.

—Rob


> On May 7, 2020, at 9:57 PM, Richard Charles via Cocoa-dev 
>  wrote:
> 
> I have a project that has several large dynamically linked libraries which 
> are located in the application bundle. Each linked library is a separate 
> project.
> 
> The setting in Xcode > Preferences > Locations > Advanced > Build Location is 
> set to use Shared Folder > Build. Historically has worked well but now with 
> Xcode 11 there are some drawbacks. For example Clean Build Folder cleans the 
> entire shared build folder not just the target. Also archiving has never 
> worked and still does not work with this configuration.
> 
> So now I have changed the Xcode setting from Shared Folder to Unique which 
> apparently is the default.
> 
> When using the Unique setting a 28 character string is appended to the 
> project name in DerivedData. The string appears to be random characters but 
> most likely is not.
> 
> During build when linking to the dynamic libraries this 28 character string 
> is in the file path. So if it ever changes then linking will fail.
> 
> So my question is will this 28 character unique string always remain constant 
> for a given project?
> 
> Any insight would be appreciated.
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTimer +timerWithTimeInterval:

[Rob Petrovec via Cocoa-dev]

I thought when everything goes wonky you zap the PRAM and rebuild the Desktop?

—Rob


> On Apr 29, 2020, at 3:45 PM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> When everything goes wonky... it's time to reinstall all of Xcode...!
> 
> *sigh*
> -Carl
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

> On Apr 23, 2020, at 8:35 PM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 24 Apr 2020, at 2:28, Gabriel Zachmann via Cocoa-dev wrote:
> 
>>> I believe that is why you are supposed to staple notarization tickets to 
>>> your apps.
>> Then, why would it "phone home" in case there is an internet connection?
> 
> Also weird, why would it phone home for a shell script which has neither been 
> stapled nor even code-signed?
I think you answered the question just then…  a "shell script which has 
neither been stapled nor even code-signed”.  Google XProtect & Gatekeeper.

—Rob




___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

> On Apr 23, 2020, at 7:30 PM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 24 Apr 2020, at 2:18, Rob Petrovec wrote:
> 
>> I get a 1 second time for the first run and then a much quicker time for the 
>> second.  I did some sampling and the longer time due to is Apple’s check for 
>> malware on first run of a process.  This is a known, documented and 
>> advertised behavior.
> 
> I would be very interested in documentation about what low-level APIs (like 
> execve) do malware checks (network access), under which conditions they are 
> performed, what servers are contacted, and what sort of caching of good/bad 
> results are done.
> 
> Is any of that documented?
Here is some from a quick Google search.  I think the feature in 
question is XProtect.  With a little more time I could probably find more 
in-depth docs.

https://www.apple.com/macos/security/  See the 'Protection starts at 
the core’ section

https://support.apple.com/guide/mac-help/protect-your-mac-from-malware-mh40596/mac

https://www.howtogeek.com/217043/xprotect-explained-how-your-macs-built-in-anti-malware-works/


> There is also blacklisting going on: I can get an executable locally 
> blacklisted which will cause it to terminate instantly when executed. This 
> seems to be about some run-time code signature validation, and when it 
> happens, it appears to be the inode that gets blacklisted until next reboot, 
> but more info about this would be nice.
Depending on where the app is being terminated, I would suspect it is 
the same “Allow apps downloaded from” feature in the General section of the 
Security & Privacy Pref pane.


>> […] So I don’t think this test is analogous to your initial issue of a delay 
>> opening a file every time.
> 
> I said I get a similar delay the first time my app obtains URL properties¹ 
> for ~/Desktop, ~/Documents, and, ~/Downloads, and I included sample code for 
> this issue.
Sorry I forgot what your initial problem was.  However, my statement 
still applies.  Getting the localized string for a folder is completely 
different then the launching app.


> Perhaps you would be willing to add this sample code to a GUI application and 
> see if you can reproduce? I re-attached it below, and have the result written 
> to /tmp/duration.txt so you don’t have to fiddle with capturing log output.
I tried it (although I changed it from writing a file to disk to 
NSLog() and it spit out:

default 19:58:53.343324-0600Test FooDuration 0.003

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

> On Apr 23, 2020, at 9:10 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 23 Apr 2020, at 21:15, Rob Petrovec wrote:
> 
>> If what you say is correct then everyone would be seeing a delay since most 
>> people don’t have blazing fast internet connections.  I do not think this is 
>> the normal behavior.
> 
> Please try run this in a terminal and report the times:
> 
>rm -f /tmp/test.sh && echo $'#!/bin/sh\necho hello' > /tmp/test.sh && 
> chmod a+x /tmp/test.sh && time /tmp/test.sh && time /tmp/test.sh
> 
> For this particular issue, it appears the lookup is cached by inode, so only 
> first run should take > 50ms, where second one would be < 5ms.
> 
> Then maybe also try it with Apple’s Network Link Conditioner and set it to 
> simulate lousy internet, and try it also with WiFi disabled.
> 
> I have seen the issue on multiple systems, so I do not think this is limited 
> to my system, but more data would be great.
I get a 1 second time for the first run and then a much quicker time 
for the second.  I did some sampling and the longer time due to is Apple’s 
check for malware on first run of a process.  This is a known, documented and 
advertised behavior.  It is a one time cost and only effects applications, not 
regular files.  For a developer though, yeah you get the cost after ever 
rebuild.  So I don’t think this test is analogous to your initial issue of a 
delay opening a file every time.



>> Sending an email to a developer mailing list doesn’t count.  Just sayin’...
> 
> My email was to ask for help, i.e. whether others have seen this issue, can 
> reproduce, have any idea what could cause this, etc.
> 
> Of course I am aware that this is not a place to report bugs to Apple…
So did you file a bug?  Would you mind posting the bug number?  Thanks.

—Rob

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

If what you say is correct then everyone would be seeing a delay since most 
people don’t have blazing fast internet connections.  I do not think this is 
the normal behavior.  I think it is specific to your system, otherwise there 
would be TONS of people complaining about slowness.  A couple second delay 
opening a file or app like you describe would be all over the internet.  I 
don’t remember from your previous emails on this subject, but did you try 
creating a new partition and installing a fresh OS with a brand new user on it 
(nothing migrated) to see if the problem reproduced?  That would be an 
interesting data point.

Either way, did you file a bug with a sysdiagnose taken during the delay?  If 
so, do you have the bug number?  Something like this doesn’t get fixed if you 
don’t report it.  Sending an email to a developer mailing list doesn’t count.  
Just sayin’...

—Rob


> On Apr 22, 2020, at 11:16 PM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 20 Apr 2020, at 0:11, Allan Odgaard via Cocoa-dev wrote:
> 
>> Unfortunately though I can’t figure out *what* the problem is; running 
>> `tccutil reset All` (and rebooting) did not fix it.
> 
> It appears the problem is not with a local service, but that Apple actually 
> “phones home” when a program asks for display name.
> 
> I don’t know if this is common knowledge, but with notarization, Apple now 
> validates executables on your system before they are executed, and it does so 
> in calls like execve(), where it will actually stall execution, contact 
> Apple’s servers, and then proceed once the executable got validated.
> 
> I *thought* this was the only place it did it, and that the result got cached 
> (based on inode).
> 
> But it seems Apple added this to other places, because since I have upgraded 
> to macOS 10.15, I see *many* delays.
> 
> This is because I am currently in South East Asia where the connection to 
> Apple’s servers is not good.
> 
> For example I have a script that takes a video file as argument, it launches 
> VLC with this video file, and then deletes the file when VLC terminates.
> 
> It can take more than 5 seconds just until VLC is launched, and then VLC will 
> be “thinking” for another 5 seconds, before the video actually starts.
> 
> Today the delays were extra bad, so it was easy to reproduce the VLC issue, 
> obtaining display name (which today took 7 seconds for 3 names), and a few 
> other things.
> 
> Now, if I disable internet, no delays at all!!!
> 
> Enable it again, and all the delays are back.
> 
> It is so utterly frustrating that Apple is not only going down this path of 
> locking down our machines, but they do it in ways that are so crippling for 
> our productivity :(
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

>> I think you are right about this being a permission / “sandbox” issue, 
>> because the 3 folders in question are all folders that macOS 10.15 now 
>> require special permission to read (even though in my case, I just request 
>> their display name).
Yes, this is because of iCloud.  Log out of iCloud and it should go 
away as I suggested in my first reply.  You could also grant your app full disk 
access and that might ‘fix’ it for you too.  But your users would probably not 
want to do that.


>> That’s 181 milliseconds spent __WAITING_ON_APPROVAL_FROM_SANDBOXD__ in a 
>> non-sandboxed app obtaining display name for 3 folders in the user’s home 
>> directory.
Its actually worse then that.  At the top of the spindump file it says 
was the numbers represent.  Something like:

Duration: 10.00s
Steps:1001 (10ms sampling interval)

So 181 actually represents 1810ms, or 1.81 seconds.  So this is a sandbox 
performance issue.  Please file a bug and include a sysdiagnose as I suggested 
in my first reply.

—Rob



> On Apr 19, 2020, at 11:11 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 19 Apr 2020, at 22:54, David M. Cotter wrote:
> 
>> i have discovered it may have to do with permissions / entitlements that 
>> have been granted the app by the user, and that resetting all perms to 
>> default will "fix" the problem
> 
> I think you are right about this being a permission / “sandbox” issue, 
> because the 3 folders in question are all folders that macOS 10.15 now 
> require special permission to read (even though in my case, I just request 
> their display name).
> 
> Furthermore, it could explain why there is no delay when launched from 
> terminal, as the process will inherit the entitlements of the terminal, which 
> may have some special entitlements for the full disk access.
> 
> Unfortunately though I can’t figure out *what* the problem is; running 
> `tccutil reset All` (and rebooting) did not fix it.
> 
> I have tried the code in question in a signed and notarized app that has been 
> granted full disk access, yet it still has the delay.
> 
> A spindump does indicate it is a “sandbox” issue:
> 
>   *182   getattrlist + 136 (kernel + 3512472) [0xff8000559898]
> *182   ??? (kernel + 3512820) [0xff80005599f4]
>   *181   ??? (kernel + 3501529) [0xff8000556dd9]
> *181   ??? (kernel + 3490836) [0xff8000554414]
>   *181   mac_vnode_check_access + 154 (kernel + 9093082) 
> [0xff8000aabfda]
> *181   hook_vnode_check_access + 167 (Sandbox + 39552) 
> [0xff7f823a7a80]
>   *181   sb_evaluate + 5004 (Sandbox + 67658) [0xff7f823ae84a]
> *181   approval_response_wait + 142 (Sandbox + 154851) 
> [0xff7f823c3ce3]
>   *181   __WAITING_ON_APPROVAL_FROM_SANDBOXD__ + 23 (Sandbox 
> + 155134) [0xff7f823c3dfe]
> *181   ??? (kernel + 6855402) [0xff8000889aea]
>   *181   thread_block_reason + 175 (kernel + 1317935) 
> [0xff8000341c2f]
> *181   ??? (kernel + 1324017) [0xff80003433f1]
>   *181   machine_switch_context + 200 (kernel + 
> 2388456) [0xff80004471e8]
> 
> That’s 181 milliseconds spent __WAITING_ON_APPROVAL_FROM_SANDBOXD__ in a 
> non-sandboxed app obtaining display name for 3 folders in the user’s home 
> directory.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Performance issue on macOS 10.15 obtaining display name for ~/Desktop, ~/Documents, and ~/Downloads

[Rob Petrovec via Cocoa-dev]

I assume you have iCloud enabled.  If so, these three folders are ’special’.  
Try logging out of iCloud & rebooting and see if the problem persists.

I would also recommend filing a bug with Apple and include a sysdiagnose taken 
while the problem was reproducing (sudo sysdiagnose).  Or at least a spindump 
(sudo spindump) while the problem is reproducing.

—Rob



> On Apr 19, 2020, at 9:54 AM, David M. Cotter via Cocoa-dev 
>  wrote:
> 
> this may be difficult for other to repro
> 
> i have discovered it may have to do with permissions / entitlements that have 
> been granted the app by the user, and that resetting all perms to default 
> will "fix" the problem
> 
> in the terminal, do this:
>> tccutil reset All
> i expect that after that, your delay will disappear.
> 
> however, you'll have to manually re-authorize all apps in the system 
> prefs->security & privacy->privacy tab
> 
> i realize this is a "sweep the problem under the rug" rather than "fix the 
> problem" approach
> but hopefully this should give someone else a clue as to WHY this is 
> happening?
> 
> -dave
> 
>> On Apr 19, 2020, at 8:08 AM, Allan Odgaard via Cocoa-dev 
>>  wrote:
>> 
>> Starting with macOS 10.15 I have noticed that obtaining 
>> NSURLLocalizedNameKey, NSURLTagNamesKey, and even calling getxattr(), can 
>> cause a significant delay.
>> 
>> The code below, which gets NSURLLocalizedNameKey for 3 folders, takes 1.9 
>> seconds to execute on my system.
>> 
>> It appears though that it is only these 3 specific folders that has the 
>> problem.
>> 
>> Furthermore, the problem only happens when I include the code below in a GUI 
>> application which is launched via launch services. If I run the executable 
>> directly from a terminal then the code is near instant.
>> 
>> I tried to sample the code, and it appears that it calls out to some OS 
>> service/daemon. Presumably it never gets a response, and a timeout is 
>> triggered.
>> 
>> I wonder if anyone else has come across this? And maybe have discovered more 
>> info?
>> 
>> This is btw macOS 10.15.4 and a fairly stock system (new computer without 
>> migrating old data), and I noticed the problem some time ago, so it 
>> definitely existed before 10.15.4, but I never saw anything like this before 
>> upgrading to Catelina.
>> 
>>   NSTimeInterval startTime = NSDate.timeIntervalSinceReferenceDate;
>> 
>>   NSArray* urls = @[]
>>   [NSFileManager.defaultManager URLForDirectory:NSDesktopDirectory 
>> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil],,
>>   [NSFileManager.defaultManager URLForDirectory:NSDocumentDirectory 
>> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil]
>>   [NSFileManager.defaultManager URLForDirectory:NSDownloadsDirectory 
>> inDomain:NSUserDomainMask appropriateForURL:nil create:NO error:nil,
>>   ];
>> 
>>   NSString* localizedName;
>>   for(NSURL* url in urls)
>>   [url getResourceValue: forKey:NSURLLocalizedNameKey 
>> error:nil];
>> 
>>   NSLog(@"Duration %.03f", NSDate.timeIntervalSinceReferenceDate - 
>> startTime);
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Open a panel in secondary thread?

[Rob Petrovec via Cocoa-dev]

> On Mar 23, 2020, at 8:01 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
 I would not do this.  It is widely documented that AppKit API that produce 
 UI elements, like NSOpenPanel, are _not_ thread safe.  
>>> 
>>> Right, and that is why I have to execute any UI code in the main thread,
>>> or so I thought.
>>> As far as I understand, the dispatch_get_main_queue is executed by the main 
>>> thread, isn't it?
>> Yes
> 
> So, why is 
>   dispatch_sync( dispatch_get_main_queue(),  block opening a NSOpenPanel )
> a bad idea?
It’s not a bad idea.  I misread the code.   I didn’t see 
dispatch_get_main_queue.  Sorry about that.  This will invoke the open panel on 
the main thread and not return until the panel is dismissed.


>>> When the user selects a directory, I collect all files in that sub-tree 
>>> (aka "scan").
>>> That might involve aliases. which means I need to ask the user to open the 
>>> directory that alias points to.
>>> Because that scan can take several seconds (10-20),
>>> I wanted to do that scan in a secondary thread so that it can update 
>>> progress info in the UI.
>> 
>> This is all reasonable…  I guess there may be two options, ask the user on 
>> the main thread, before you are on your background thread,
> 
> Would be doable, but would complicate the code, because I would first need to 
> scan
> the whole directory tree for aliases, get user permission , then pass the 
> array of directories to a secondary thread.
> 
> Also, I would like to give the user progress info while the secondary thread 
> is collecting.
> 
>> and only start the background thread after the user answers, or dispatch the 
>> UI work to the main thread from your background thread as your code sample 
>> showed.
> 
> So my solution is viable ?
Yes.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Open a panel in secondary thread?

[Rob Petrovec via Cocoa-dev]

I would not do this.  It is widely documented that AppKit API that produce UI 
elements, like NSOpenPanel, are _not_ thread safe.  So you may find your app 
hitting some memory stomping issues or strange crashes/exceptions due to this.  
Specifically what problems you will hit are anyones guess, but its just a 
matter of time.  There is a reason Xcode has the Main Thread Checker to catch 
UI elements being used on secondary threads.

Lets come at  this from a different direction: What are you trying to do? Why 
do you think you need to use the open panel on a secondary thread?

—Rob
 

> On Mar 22, 2020, at 1:11 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
>> 
>> Don't know if this helps you but you can look into dispatch_sync
>> and  dispatch_async.
>> 
> 
> Thanks a lot!
> That made things very easy.
> 
> I am opening the panel now with this piece of code:
> 
>__block NSURL * user_permitted_url;
>__block long int result;
>// UI stuff must be executed in the main thread
>dispatch_sync( dispatch_get_main_queue(), ^(void)
>{
>result = [self askUserToOpenDirectory: resolvedurl 
> newURL: & user_permitted_url];
>}
>);
> 
> (where my method askUserToOpenDirectory opens the NSOpenPanel and gets the 
> URL.)
> 
> BTW:
> just in case others stumble over this:
> in my case, I am opening the NSOpenPanel with the directory set to 
> resolvedurl, for which I am asking permission. So the user is just supposed 
> to click "OK".
> So, I thought, I don't need to do anything else;
> but it turns out I get permission from the OS really only if I actually get 
> the URL using 
>oPanel.URL 
> , even if it is the same as resolvedurl!
> 
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Open a panel in secondary thread?

[Rob Petrovec via Cocoa-dev]

No you can’t one an NSOpenPanel on a secondary thread.  UI elements must be on 
the main thread.

—Rob


> On Mar 21, 2020, at 1:05 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Is it possible to open an NSOpenPanel in a secondary thread?
> 
> I create the thread like this:
> 
>directoryScanThread_ = [[NSThread alloc] initWithTarget: self
>   selector: 
> @selector(scanDirectory:)
> object: nil];
>[directoryScanThread_ start];
> 
> 
> But when I do:
> 
>NSOpenPanel *oPanel = [NSOpenPanel openPanel];
> 
> it crashes at this point.
> 
> In the docs, I found a hint that one should use
> 
>lockFocusIfCanDraw
> 
> but that is deprecated now.
> 
> Any ideas will be highly appreciated.
> 
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Questions about sandboxing under Catalina

[Rob Petrovec via Cocoa-dev]

> On Jan 10, 2020, at 6:36 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Steve, thanks a lot for your response!
> 
>>> 
>>> In my screensaver, I try to search the Pictures directory in the user's 
>>> home.
>>> It is OK - for now - if my app cannot access any .photoslibrary, but I'd 
>>> like to pick up
>>> any other images in ~/Pictures.
>>> 
>>> I get the path using this line of code:
>>> [NSHomeDirectory() stringByAppendingPathComponent: @"Pictures/"]
>>> 
>>> However, when I print the actual path to the system log, it says it is 
>>> accessing this path:
>>> /Users/me/Library/Containers/com.apple.ScreenSaver.Engine.legacyScreenSaver/Data/Pictures
>>> 
>>> Is this directory somehow linked to ~/Pictures ?
>>> Or how can I access the true ~/Pictures directory ?
>> 
>> That's how sandboxing works.
> 
> So, is .../Containers/.../Data/Pictures linked to ~/Pictures automatically?
No.  The user has to give your app permission to see the contents of 
~/Pictures.

https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html

—Rob


> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Catalina scroll view issues

[Rob Petrovec via Cocoa-dev]

> On Dec 31, 2019, at 1:34 AM, Eyal Redler  wrote:

> Nothing old fashioned or unorthodox in what I'm doing.
drawRect is not deprecated. Correct. However, it is technically old 
fashioned. It is much more efficient to use layers.  Layers can take better 
advantage of the video card especially during animations, and don’t require 
unnecessary redraws if (part of) your view is covered up and then uncovered 
(e.g. during scrolling or windows moving around etc).


> turning it on did not cause the issue to show up on Mohave
> ...
>  I, for one, wasn't able to reproduce it on the 5 machines I was able to put 
> my hands on.
Curious, how were you able to verify that turning on copyOnScroll in 
your app and running it on Mojave did not reproduce the problem if you couldn’t 
reproduce the problem on Catalina on the machines you had access to?  Just 
curious.

—Rob


> On Dec 31, 2019, at 1:34 AM, Eyal Redler  wrote:
> 
>> 
>> On 30 Dec 2019, at 2:09, Rob Petrovec via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>> I honestly think this is fall out from copiesOnScroll being deprecated and 
>> the clip view always behaving as if it was set to true.  My guess is you 
>> will see the same problems in your apps if you ran them on Mojave with 
>> copiesOnScroll set to true.  In which case you need to update your app to 
>> work with copiesOnScroll set to true.  E.g. use layers instead of drawRect.
> 
> I agree that this is probably connected to the changes that led to 
> copiesOnScroll to be deprecated but turning it on did not cause the issue to 
> show up on Mohave nor did it fix the issue on Catalina. AFAIK drawRect is not 
> deprecated (yet?) and so my drawing the views, on a mac, using drawRect is 
> compatible Apple's current guidelines. Nothing old fashioned or unorthodox in 
> what I'm doing.
> 
> My understanding (and hopefully those in the know will correct me if I'm 
> wrong), with responsive scrolling, copiesOnScroll is not relevant, drawRect 
> is not called to paint the newly exposed area as you scroll but rather is 
> called ahead of time for the visible area plus some extra content above and 
> below. When the user scrolls, the system just copies the bits to the screen 
> from some offscreen buffer. I believe that since responsive scrolling was 
> introduced, copiesOnScroll was ignored anyway and was relevant only when 
> responsive scrolling was turned off.
> 
> Last thing to point out, the problem is exclusive to Catalina but it doesn't 
> effect all users, I don't have any statistics but gathering from the 
> relatively few reports I've received, it seems to effect only a minority of 
> users (thank God, this bug really makes me look really bad and I'm completely 
> helpless against it). I, for one, wasn't able to reproduce it on the 5 
> machines I was able to put my hands on.
> 
> Eyal
> 
> 
> 
>> 
>> —Rob
>> 
>> 
>>> On Dec 29, 2019, at 4:08 PM, Jerome Krinock via Cocoa-dev 
>>>  wrote:
>>> 
>>> Since installing macOS 10.15, I see blocks of empty text view lines or 
>>> table view rows often when scrolling through many apps, including file 
>>> browser windows in Path Finder (cocoatech.com) and, for heaven’s sake, even 
>>> in BBEdit.
>>> 
>>> Conclusion: This is not “our” faults.  Thank you, Eyal for submitting this 
>>> issue to Apple as FB7509033.  Maybe someday… [rant omitted].
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
>>> 
>>> This email sent to petr...@mac.com
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/eyal%40mellel.com 
>> <https://lists.apple.com/mailman/options/cocoa-dev/eyal%40mellel.com>
>> 
>> This email sent to e...@mellel.com <mailto:e...@mellel.com>
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Catalina scroll view issues

[Rob Petrovec via Cocoa-dev]

I honestly think this is fall out from copiesOnScroll being deprecated and the 
clip view always behaving as if it was set to true.  My guess is you will see 
the same problems in your apps if you ran them on Mojave with copiesOnScroll 
set to true.  In which case you need to update your app to work with 
copiesOnScroll set to true.  E.g. use layers instead of drawRect.

—Rob


> On Dec 29, 2019, at 4:08 PM, Jerome Krinock via Cocoa-dev 
>  wrote:
> 
> Since installing macOS 10.15, I see blocks of empty text view lines or table 
> view rows often when scrolling through many apps, including file browser 
> windows in Path Finder (cocoatech.com) and, for heaven’s sake, even in BBEdit.
> 
> Conclusion: This is not “our” faults.  Thank you, Eyal for submitting this 
> issue to Apple as FB7509033.  Maybe someday… [rant omitted].
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Catalina scroll view issues

[Rob Petrovec via Cocoa-dev]

From 
https://developer.apple.com/documentation/appkit/nsclipview/1532142-copiesonscroll?language=objc
copiesOnScroll
A Boolean value that indicates if the clip view copies rendered images while 
scrolling.
Discussion
When the value of this property is YES, the clip view copies its existing 
rendered image while scrolling (only drawing exposed portions of its document 
view); when it is NO, the view forces its contents to be redrawn each time.

From NSClipView.h:
@property BOOL copiesOnScroll API_DEPRECATED("NSClipView will always 
minimize the area of the document view that is invalidated.  To force 
invalidation of the document view, use -[NSView setNeedsDisplayInRect:].", 
macos(10.0, API_TO_BE_DEPRECATED));

The way I read that is that the clip view now always behaves as if copyOnScroll 
is YES.  So even though you have it set to NO, the scroll/clip view will behave 
as if it was true.  That may be your problem here and explain the difference in 
behavior for you between Mojave and Cataline.  Good luck.

—Rob



> On Dec 14, 2019, at 12:20 PM, Gary L. Wade via Cocoa-dev 
>  wrote:
> 
> I see from your personal web site you know Hebrew. Is it possible the 
> affected/non-drawing pages contain some RTL text while those that don’t only 
> contain LTR? I have seen some bugs with RTL text within NSTextView where the 
> text was/wasn’t drawing in a similar manner. Do you operate at a CoreText 
> level?
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Dec 14, 2019, at 6:17 AM, Redler Eyal via Cocoa-dev 
>>  wrote:
>> 
>> Hi All,
>> 
>> I'm getting reports from users complaining about a strange display issue on 
>> Catalina with my app.
>> My app is a word-processor (not based on the cocoa text system) whose main 
>> display shows the pages of the document. Every page is a separate view and 
>> all the pages are subviews of one big view which resides inside a scroll 
>> view.
>> 
>> The problem is that when with some documents, sometimes, when the user 
>> scrolls down the document, some pages are not drawn or even partially drawn. 
>> When the user clicks the place where the page is supposed to appear, it 
>> shows up.
>> Another interesting bit is seems that while the scroll view background is 
>> drawn, the document views (the view containing the page views) drawRect is 
>> not called or at least not taking effect, I can tell because the pages on 
>> this view cast a shadow which is drawn by drawing blank squares on the 
>> document view with a transparency layer.
>> Last bit of info, copiesOnScroll set to NO for this view and I see that this 
>> property is deprecated on Catalina.
>> 
>> So far I'm struggling with this for a couple of weeks, I wasn't able to 
>> reproduce this at all on my machine.
>> I'm really desperate for an answer and while I'm not expecting anyone here 
>> to provide me with one (wouldn't object, of course :-)) I would love if 
>> people reading this might try to speculate to the causes of this or perhaps 
>> if you have any direction as to what to test on my users machines in order 
>> to be able to reproduce this.
>> 
>> Thanks
>> 
>> Eyal Redler
>> 
>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>> way."
>> --James Randi
>> www.eyalredler.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

> On Nov 20, 2019, at 9:28 AM, Pier Bover  wrote:
> 
> > Its not Apples fault if you were not aware.  They were both highly talked 
> > about during their respective WWDC events.
> 
> The vast majority of developers do not go to the WWDC and do not have time to 
> watch the dozens (hundreds?) of hours of videos to maybe find something 
> relevant about the future of macOS dev. If that's how Apple communicates 
> their future plans then Apple has a communication problem.
32 bit being deprecated & it being killed were both announced during 
their respective WWDC keynote, if memory services, to a lot of fan fair.  If 
you only watch one WWDC video a year the keynote is the one to watch.  Its 
where most big future plans are announced.  There were also a bunch of WWDC 
sessions/videos and developer pages on how to move your products away from 32 
Bit too.  It was also covered on a bunch of Apple Developer web pages.  If you 
search around you can still find them.  It was also highly talked about on this 
and other mailing lists and forums as well as many mac news sites etc.  The 
information was there in many locations, you just had to pay attention.  Again, 
its not Apple’s fault if you were not aware.


> Companies like Adobe, Microsoft, etc, announce their plans publicly years in 
> advance. They have dedicates pages, blog posts, social media announcements 
> with dates of when these EOL changes will happen. For example Adobe announced 
> in 2017 it would kill the Flash Player by 2020.
Adobe only have you 3 years to move away from Flash Player.  Apple gave 
you 7 to move away from 32 Bit, yet you still complain?


> Personally I didn't know about 32 bits EOL until I heard about it with Mojave 
> user alerts, less than 2 years before Catalina was released. It didn't impact 
> me, but it did impact many companies that are still struggling with it. For 
> example the vast majority of audio software companies are still communicating 
> to its users to not update to Catalina. Huge audio companies like Native 
> Instruments are still struggling with this.
They had 7 years to get things in order.  I have sympathy for their 
users, but not for the company.  They either have mac developers with their 
heads in the sand, or they made a conscious business decision not to put 
resources towards moving away from 32 Bit.  In either case, again, its not 
Apple’s fault.


> Do you know for certain when Apple will stop shipping OpenGL with macOS? 
> Probably not. Most likely it will be announced less than a year before it 
> happens.
No I don’t know when OpenGL is being killed.  But Apple announced it is 
being deprecated which is your first, and very large, clue to start moving away 
from OpenGL in your products sooner rather than later.  Again, you have been 
told its going away, and historically it takes a few years for Apple to kill 
things like that.  If your products still use OpenGL by the time OpenGL is 
killed in a few years then it is totally on you, not Apple.  Just sayin’...

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

> On Nov 19, 2019, at 6:24 PM, Pier Bover  wrote:
> 
> > When/if Apple decides to deprecate Cocoa they will announce it many years 
> > ahead of time 
> 
> Like they did with 32 bits and OpenGL deprecation?
Yes, exactly.  32Bit was deprecated in 2012 and officially killed in 
2019.  OpenGL was deprecated in 2018 and has not been killed yet.  Its not 
Apples fault if you were not aware.  They were both highly talked about during 
their respective WWDC events.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

The sky is not falling.  When/if Apple decides to deprecate Cocoa they will 
announce it many years ahead of time, like they did for Carbon back in 2012 
(which was only officially killed in 2019).  They typically make announcements 
like that at a WWDC.  They aren’t going to stop supporting it and stop letting 
apps built with it from launching out of the blue.  That would be a PR 
nightmare.  So everyone please take a breath.

—Rob


> On Nov 19, 2019, at 5:26 PM, Gerald Henriksen via Cocoa-dev 
>  wrote:
> 
> On Tue, 19 Nov 2019 13:51:14 -0700, you wrote:
> 
>> When committing to 64 bit Apple said NO to Carbon but YES to Cocoa and YES 
>> to Core Foundation and YES to a lot of other stuff. The OS still has the XNU 
>> (Mach) Kernel and FreeBSD (written in C & C++), the Cocoa frameworks (base 
>> layer written in Objective-C), Swift and lots of other stuff. From my point 
>> of view I do not see Apple sweeping away Objective-C and the Cocoa 
>> frameworks any time soon. 
> 
> Just because Apple may need to keep Objective-C around for the
> frameworks doesn't mean they will continue to allow applications to be
> written in it.
> 
> All they need to do is either eliminate the option (stop shipping the
> Objective-C compiler), or do so by requiring all applications to have
> something that is only available via Swift.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Future of Cocoa

[Rob Petrovec via Cocoa-dev]

+1

Also, the reference docs can be toggled between Obj-C & Swift via the 
“Language” popup at the top of the page.

—Rob


> On Nov 19, 2019, at 9:48 AM, Steve Mills via Cocoa-dev 
>  wrote:
> 
> You should use an external poll site for this rather than filling the list 
> with yet another thread full of discussions and arguments.
> 
> Steve via iPhone
> 
>> On Nov 19, 2019, at 10:42, Turtle Creek Software via Cocoa-dev 
>>  wrote:
>> 
>> Before I email comments to Apple, it would help to know more about how
>> other developers use Cocoa. Is it OK to run an informal poll?  I'll
>> consolidate it into a spreadsheet, and won't share any details without
>> consent.  Email me direct if you want more privacy.
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cocoa-dev Digest, Vol 16, Issue 144

[Rob Petrovec via Cocoa-dev]

> On Nov 14, 2019, at 1:13 PM, Pier Bover  wrote:
> 
> > I wouldn’t be so pessimistic about macOS or even iOS update rates.
> 
> According to StatCounter Mojave never went above 52% or market share, which 
> means at its peak 48% of users were still on previous versions.
> 
> https://gs.statcounter.com/macos-version-market-share/desktop/worldwide 
> <https://gs.statcounter.com/macos-version-market-share/desktop/worldwide>
> 
> I think it will be worse for Catalina. It's anecdotal, but every Mac user I 
> know will remain in Mojave or even previous macOS versions for the 
> foreseeable future. Also, every audio software developer I know has been 
> sending emails to its users to not update to Catalina. Audio forums are full 
> of people not being able to use their hardware with Catalina because of some 
> driver problem or something else.
Market Share is not necessarily the same as upgrade rates.  Either way, 
the chart you linked to kind of proves my point though.  It shows that the 
majority of users are using the latest released OS after less than a year.  And 
at least 25% have adopted Catalina in two months (assuming Catalina is listed 
under “Other”).  Thats pretty quick, IMO.

—Rob


> On Thu, Nov 14, 2019 at 1:52 PM Rob Petrovec  <mailto:petr...@mac.com>> wrote:
> I wouldn’t be so pessimistic about macOS or even iOS update rates.  Its 
> considerably quicker than you think.  IMS, they announce upgrade rates during 
> public earnings report conference calls typically to brag about how well a 
> new OS is being received by the public over previous releases or competing 
> OSs.
> 
> re Cocoa being deprecated: I think you have some time.  A lot of 
> apps/components in the OS are written in Obj-C and it is a big undertaking to 
> convert them all.  Not something that can feasibly be done in a year or two.  
> Remember how long it took Finder to switch from Carbon to Cocoa?  And even 
> then it was half Carbon & half Cocoa.  It took a couple releases for it be 
> all Cocoa.  Not to mention Carbon was officially deprecated in 10.8 (back in 
> 2012) and is only now dead in 10.15 (2019).  So I think Cocoa still has a 
> good number of years of life left before it is deprecated and even more years 
> before it is dead.
> 
> —Rob
> 
> 
> > On Nov 14, 2019, at 12:30 PM, Pier Bover via Cocoa-dev 
> > mailto:cocoa-dev@lists.apple.com>> wrote:
> > 
> >> Well I think the point is to go SwiftUI
> > 
> > What if you want to support previous macOS versions older than Catalina?
> > 
> > I doubt the majority of users will update to Catalina for at least 1-2
> > years.
> > ___
> > 
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> > <mailto:Cocoa-dev@lists.apple.com>)
> > 
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> > <http://lists.apple.com/>
> > 
> > Help/Unsubscribe/Update your Subscription:
> > https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com 
> > <https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com>
> > 
> > This email sent to petr...@mac.com <mailto:petr...@mac.com>
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cocoa-dev Digest, Vol 16, Issue 144

[Rob Petrovec via Cocoa-dev]

I wouldn’t be so pessimistic about macOS or even iOS update rates.  Its 
considerably quicker than you think.  IMS, they announce upgrade rates during 
public earnings report conference calls typically to brag about how well a new 
OS is being received by the public over previous releases or competing OSs.

re Cocoa being deprecated: I think you have some time.  A lot of 
apps/components in the OS are written in Obj-C and it is a big undertaking to 
convert them all.  Not something that can feasibly be done in a year or two.  
Remember how long it took Finder to switch from Carbon to Cocoa?  And even then 
it was half Carbon & half Cocoa.  It took a couple releases for it be all 
Cocoa.  Not to mention Carbon was officially deprecated in 10.8 (back in 2012) 
and is only now dead in 10.15 (2019).  So I think Cocoa still has a good number 
of years of life left before it is deprecated and even more years before it is 
dead.

—Rob


> On Nov 14, 2019, at 12:30 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
>> Well I think the point is to go SwiftUI
> 
> What if you want to support previous macOS versions older than Catalina?
> 
> I doubt the majority of users will update to Catalina for at least 1-2
> years.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Thoughts on productivity

[Rob Petrovec via Cocoa-dev]

> On Oct 24, 2019, at 5:16 PM, James Walker via Cocoa-dev 
>  wrote:
> 
> On 10/24/19 3:57 PM, Rob Petrovec via Cocoa-dev wrote:
>>> On Oct 24, 2019, at 4:50 PM, Stephane Sudre  wrote:
>>> 
>>> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev
>>>  wrote:
>>>> If its a ranty bug report, which apparently happens a lot, it goes into a 
>>>> black-hole never to see the light of day if it doesn’t just get closed 
>>>> right off the bat.  So try to keep opinions & criticisms out of it.  Just 
>>>> the facts and keep it professional.
>>> 
>>> Not fixing an issue because the bug report is ranty is definitely not
>>> professional.
>>  Apple Engineers aren’t in the service industry.  So they don’t have to 
>> sit there and take it with a smile.
> 
> When Apple engineers deal with bug reports, they're not just doing it as a 
> favor to the person who filed the report.  Bugs may affect many developers 
> and end users, only a few of whom have the ability and the time to file a bug 
> report.  So I agree that it would be unprofessional to ignore a report just 
> because it's not worded calmly.
Most ranty bugs don’t have any actionable content in them though. They 
are just complaining and being insulting with no content of value, like most 
rants.  They typically don’t have steps to reproduce or logs or video or 
anything like that.  If there is anything actionable in it the engineers will 
typically copy/paste that actionable content into a new bug and send the 
original back to be closed.
Put yourself in the Apple Engineers shoes.  If someone sent you a long 
ranty, critical, & insulting email, or came up to you and started screaming at 
you about something, would you want to continue to interact with that person?  
I seriously doubt it.  That person will probably continue to respond in the 
same way as their initial correspondence and provide nothing of value.

—Rob



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Thoughts on productivity

[Rob Petrovec via Cocoa-dev]

> On Oct 24, 2019, at 4:50 PM, Stephane Sudre  wrote:
> 
> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev
>  wrote:
>> If its a ranty bug report, which apparently happens a lot, it goes into a 
>> black-hole never to see the light of day if it doesn’t just get closed right 
>> off the bat.  So try to keep opinions & criticisms out of it.  Just the 
>> facts and keep it professional.
> 
> Not fixing an issue because the bug report is ranty is definitely not
> professional.
Apple Engineers aren’t in the service industry.  So they don’t have to 
sit there and take it with a smile.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Thoughts on productivity

[Rob Petrovec via Cocoa-dev]

> On Oct 24, 2019, at 4:01 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
>>> 
>>> 
>>> 
>>> https://developer.apple.com/account/#/feedback-assistant
>>> 
>>> https://developer.apple.com/account/#/forums
>> 
>> 
>> Good luck with that. I've been using OSX/macOS since the Panther days and
>> quite frankly I don't think Apple cares.
> 
> Occasionally, I send a bugreport via https://feedbackassistant.apple.com/
> And occasionally, I do get a response, usually they ask for additional 
> information.
> 
> So, i think, they do listen to the feedback on that channel, at least.
> 
> Best regards, Gabriel
My experience is similar.  I’ve had numerous bug reports I’ve written 
fixed over the years.  Some took longer than others, but they do get fixed.  
From talking to some Apple engineers I’m friends with, the key is to write an 
actionable bug (e.g. provide screen shots, screen recordings, logs and most 
importantly reproducible steps).  If you write a bug that isn’t actionable then 
there isn’t much they can do with it.  If its a ranty bug report, which 
apparently happens a lot, it goes into a black-hole never to see the light of 
day if it doesn’t just get closed right off the bat.  So try to keep opinions & 
criticisms out of it.  Just the facts and keep it professional.  If you run 
with any haxies and system mods then that makes it even harder for them to 
diagnose & fix issues.  Especially if it uses code injection to do it’s thing.  
Chances are high the bug is in the haxie/system mod not the OS.  Otherwise they 
would likely have gotten more reports about it and have fixed it.
As for forums & mailing lists, some Apple engineers do lurk on them and 
do reply from time to time.  But it isn’t part of their job.  They do it on 
their own.  So I agree that if you want to provide feedback, do it via a bug 
report not via the forums & mailing lists.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Questions regarding release

[Rob Petrovec via Cocoa-dev]

> On Sep 26, 2019, at 5:43 PM, James Walker via Cocoa-dev 
>  wrote:
> 
> On 9/26/19 4:20 PM, Gabriel Zachmann via Cocoa-dev wrote:
>>> The issue in the below code to my eye is that you allocate a path with 
>>> CGPathCreateWithRect (+1) but then don't release it.
>>> 
>>> In that case, I am wondering:
>>> doesn't ownership pass to the textlayer ?
>>> If yes, shouldn't textlayer release the path when it gets destroyed by the 
>>> ARC?
>>> 
>>> CALayer will indeed release shadowPath when it’s deallocated. However, 
>>> CALayer.setShadowPath doesn’t expect to be passed a +1 reference, so it 
>>> will retain/copy its argument, and it’s that retain which will be balanced 
>>> by the release during object destruction. Functions and methods generally 
>>> do not expect to be passed +1 objects.
>> So, if I understand you correctly, I should do this:
>> textlayer.shadowPath = CGPathCreateWithRect( textlayer.bounds, NULL );
>>CFRelease( textlayer.shadowPath )
>> ?
>> Is that correct?
> 
> That's not completely clear.  The documentation on shadowPath says "The value 
> of this property is retained using the Core Foundation retain/release 
> semantics".  However, a comment in CALayer.h says "Upon assignment the path 
> is copied."  If that's true, you'd be releasing the copy, not the original.  
> It would be safer to say:
> 
> CGPathRef thePath = CGPathCreateWithRect( textlayer.bounds, NULL );
> textlayer.shadowPath = thePath;
> CFRelease( thePath );
If the path returned by CGPathCreateWithRect is immutable, which I 
think it is, then the copy made by shadowPath would likely be just a retain.  
However, I agree that assigning it to a variable is the better, less fragile, 
and more readable method.

—Rob



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Questions regarding release

[Rob Petrovec via Cocoa-dev]

> On Sep 26, 2019, at 5:20 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
>> The issue in the below code to my eye is that you allocate a path with 
>> CGPathCreateWithRect (+1) but then don't release it.
>> 
>> In that case, I am wondering:
>> doesn't ownership pass to the textlayer ?
>> If yes, shouldn't textlayer release the path when it gets destroyed by the 
>> ARC?
>> 
>> CALayer will indeed release shadowPath when it’s deallocated. However, 
>> CALayer.setShadowPath doesn’t expect to be passed a +1 reference, so it will 
>> retain/copy its argument, and it’s that retain which will be balanced by the 
>> release during object destruction. Functions and methods generally do not 
>> expect to be passed +1 objects.
> 
> So, if I understand you correctly, I should do this:
> 
>textlayer.shadowPath = CGPathCreateWithRect( textlayer.bounds, NULL ); 
>   CFRelease( textlayer.shadowPath )
> 
> ?
> Is that correct?
From a memory perspective, yes.

—Rob



> __
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Questions regarding release

[Rob Petrovec via Cocoa-dev]

> On Sep 25, 2019, at 2:52 PM, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
>> Is it safe to do it after assigning the nsimage to the layer, but before 
>> deleting the layer?
>   I would think so, but it is hard to say without knowing what 
> convertToNSImage:withOrientation actually does under the hood.  It likely 
> either retains or copies it.  In either case, your release is safe & correct.
With that said, CALayer.contents will convert the NSImage into a 
CGImageRef under the hood.  So even your NSImage won’t live for very long.

—Rob


>> Is the IOObjectRelease() right or wrong ?
>   I’m not entirely sure since I can’t find the docs for 
> IOServicePortFromCGDisplayID.  But just from the name of 
> IODisplayCreateInfoDictionary alone, info needs to be released via 
> CFRelease(info).
> 
> —Rob
> 
> 
>> On Sep 25, 2019, at 1:31 PM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> A few years ago, I switched my code to ARC.
>> 
>> Now, I have this in my code:
>> 
>>   CGImageRef imageRef = CGImageSourceCreateImageAtIndex( sourceRef, 0, NULL 
>> );
>>   ...
>>  NSImage * nsimage = [self convertToNSImage: img withOrientation: 
>> img_orientation];
>>assign nsimage to a layer
>>   ...
>>   CGImageRelease( imageRef );
>>   ...
>>   use the layer with the nsimage
>> 
>> The doc for CGImageSourceCreateImageAtIndex() that I need to release 
>> imageRef myself.
>> Is it safe to do it after assigning the nsimage to the layer, but before 
>> deleting the layer?
>> Or should I keep the imageRef until the layer itself gets removed from its 
>> super layer?
>> 
>> 
>> Also, I have some more release's in my code, and I would appreciate your 
>> advice 
>> whether or not I still need them.  (Sometimes, I still get confused.)
>> 
>>   io_service_t serv = [self IOServicePortFromCGDisplayID: displayID];
>>   CFDictionaryRef info = IODisplayCreateInfoDictionary(serv, 
>> kIODisplayOnlyPreferredName);
>>   IOObjectRelease(serv);
>> 
>> Is the IOObjectRelease() right or wrong ?
>> 
>> 
>> Thanks a lot in advance.
>> 
>> Best regards, Gabriel
>> 
>> 
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
>> 
>> This email sent to petr...@mac.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Questions regarding release

[Rob Petrovec via Cocoa-dev]

> Is it safe to do it after assigning the nsimage to the layer, but before 
> deleting the layer?
I would think so, but it is hard to say without knowing what 
convertToNSImage:withOrientation actually does under the hood.  It likely 
either retains or copies it.  In either case, your release is safe & correct.

> Is the IOObjectRelease() right or wrong ?
I’m not entirely sure since I can’t find the docs for 
IOServicePortFromCGDisplayID.  But just from the name of 
IODisplayCreateInfoDictionary alone, info needs to be released via 
CFRelease(info).

—Rob


> On Sep 25, 2019, at 1:31 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> A few years ago, I switched my code to ARC.
> 
> Now, I have this in my code:
> 
>CGImageRef imageRef = CGImageSourceCreateImageAtIndex( sourceRef, 0, NULL 
> );
>...
>   NSImage * nsimage = [self convertToNSImage: img withOrientation: 
> img_orientation];
> assign nsimage to a layer
>...
>CGImageRelease( imageRef );
>...
>use the layer with the nsimage
> 
> The doc for CGImageSourceCreateImageAtIndex() that I need to release imageRef 
> myself.
> Is it safe to do it after assigning the nsimage to the layer, but before 
> deleting the layer?
> Or should I keep the imageRef until the layer itself gets removed from its 
> super layer?
> 
> 
> Also, I have some more release's in my code, and I would appreciate your 
> advice 
> whether or not I still need them.  (Sometimes, I still get confused.)
> 
>io_service_t serv = [self IOServicePortFromCGDisplayID: displayID];
>CFDictionaryRef info = IODisplayCreateInfoDictionary(serv, 
> kIODisplayOnlyPreferredName);
>IOObjectRelease(serv);
> 
> Is the IOObjectRelease() right or wrong ?
> 
> 
> Thanks a lot in advance.
> 
> Best regards, Gabriel
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cocoa window messages in app being ported from Carbon

[Rob Petrovec via Cocoa-dev]

> On Aug 10, 2019, at 3:38 PM, Uli Kusterer  
> wrote:
> 
>> On 10. Aug 2019, at 19:03, Rob Petrovec via Cocoa-dev 
>> mailto:cocoa-dev@lists.apple.com>> wrote:
>> 
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>>> mailto:cocoa-dev@lists.apple.com>> wrote:
>>> 
>>> The NSView subclasses involved are receiving drawRect: messages but are not 
>>> receiving mouseDown:.
>>  You need to implement NSView -hitTest: to get mouseDown events.
>> 
>> —Rob
> 
> 
> No, the default implementation does all you need and is perfectly fine.
I’ll repeat myself, the OP is not getting mouseDown on his NSView 
subclass.  So it isn’t perfectly fine in this case.  If he wants mouseDown 
events in his NSView subclass he needs to override hitTest to return self, or 
whatever subview he wants to get mouseDown.  There is no avoiding it.

The default implementation of NSView hitTest just loops through it’s 
visible subviews and calls hitTest on each one that the passed in point is 
inside.  It is obviously recursive.  If any of the subviews return a valid view 
from their implementations of -hitTest: then that valid view is returned up the 
call stack. Whatever view is returned from -hitTest: at the top of the call 
stack will get first crack at the mouseDown event.  Since NSViews don’t have 
subviews by default, let alone one that returns a valid view from hitTest, then 
the default implementation of an NSView -hitTest will return nil.  Semantics, I 
know...

Either way, instead of going back & forth on this, why don’t you try 
implementing an NSView subclass without hitTest returning self and see if that 
view gets -mouseDown:.  Then override -hitTest in the view to return self and 
see that the view does get -mouseDown.  Then you will see that I am correct.  
Thanks.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cocoa window messages in app being ported from Carbon

[Rob Petrovec via Cocoa-dev]

> On Aug 10, 2019, at 3:12 PM, Kurt Bigler  wrote:
> 
> On 8/10/19 10:03:00 AM, Rob Petrovec wrote:
>>> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>>>  wrote:
>>> 
>>> The NSView subclasses involved are receiving drawRect: messages but are not 
>>> receiving mouseDown:.
> 
>>  You need to implement NSView -hitTest: to get mouseDown events.
> 
> I have 5 working Cocoa apps, and none implement hitTest.  It is apparently 
> needed for special circumstances, per the docs "to have a view object hide 
> mouse-down events from its subviews”.
The OP said NSView subclasses.  Not NSControl.  So he needs to 
implement hitTest to get mouseDown events.  If you read the sentence before the 
line you quoted:  "This method is used primarily by an NSWindow object to 
determine which view should receive a mouse-down event.”.  NSView returns nil 
from hitTest by default, so raw NSViews don’t get mouseDown events.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Cocoa window messages in app being ported from Carbon

[Rob Petrovec via Cocoa-dev]

> On Aug 10, 2019, at 12:24 AM, Kurt Bigler via Cocoa-dev 
>  wrote:
> 
> The NSView subclasses involved are receiving drawRect: messages but are not 
> receiving mouseDown:.
You need to implement NSView -hitTest: to get mouseDown events.

—Rob


___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Hide badge of NSDraggingSession

[Rob Petrovec via Cocoa-dev]

I would not recommend using those deprecated API.  They are not long for this 
world.  With that said, I don’t have a better solution.

—Rob


> On Jul 25, 2019, at 7:03 PM, Dragan Milić via Cocoa-dev 
>  wrote:
> 
>> On pet 26.10.2019,. at 02.37, Steve Mills via Cocoa-dev wrote:
>> 
>> Use the single image methods instead of adding multiple items.
> 
> Do you think of deprecated (as of Lion) one:
> 
> -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] ??
> 
> -- Dragan
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSTableView

[Rob Petrovec]

Because dragImage is the old (and likely soon to be deprecated), single image 
style drag setup and the pasteboardWriter version is the modern multi-image 
drag set up.  Ever notice how when you drag a file around in the Finder the 
drag image will morph as the drag moves between windows with different view 
styles etc?  Or how the drag images change positions relative to the mouse as 
you drag multiple files around.  That is the multi-image drag setup.  Single 
image drags can’t do that.

—Rob


> On Apr 20, 2019, at 12:14 AM, Arved von Brasch  wrote:
> 
> Hello list,
> 
> Anyone know if it is intentionally the case that NSTableView doesn’t call
> 
> dragImageForRows(with dragRows: IndexSet, tableColumns: [NSTableColumn], 
> event dragEvent: NSEvent, offset dragImageOffset: NSPointPointer) -> NSImage
> 
> if you implement
> 
> func tableView(NSTableView, pasteboardWriterForRow: Int) -> 
> NSPasteboardWriting?
> 
> instead of
> 
> func tableView(NSTableView, writeRowsWith: IndexSet, to: NSPasteboard) -> Bool
> 
> I can’t see a reason for it not to in the documentation, but it doesn’t in my 
> code.
> 
> Kind regards,
> Arved
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Trouble assigning datasource and delegate to an instance of NSTableView

[Rob Petrovec]

Yes, this.

—Rob


> On Mar 28, 2019, at 5:39 PM, Quincey Morris 
>  wrote:
> 
> On Mar 28, 2019, at 15:58 , Peter Hudson  wrote:
>> 
>> @interface  ImportTool > NSEncoding> : NSObject
> 
> You’re Doing It Wrong™. You mean:
> 
>> @interface  ImportTool : NSObject > NSTableViewDelegate, NSEncoding>
> 
> 
> I don’t know what it means the way you wrote it. Something about lightweight 
> generic syntax, perhaps? 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Setting the tag of an NSCell

[Rob Petrovec]

It probably just sets it on the NSControl that the NSCell lives in, or eats the 
exception when setting it on the cell.  You could set a breakpoint on Obj-C 
exceptions in Xcode and see if it fires when loading your nib.

—Rob


> On Mar 16, 2019, at 7:13 PM, Carl Hoefs  
> wrote:
> 
> Thanks Howard and Rob. I will try both approaches and see what works best.
> 
> But, it makes me wonder how Xcode is able to set the tag of NSCells?
> 
> -Carl
> 
> 
>> On Mar 16, 2019, at 6:10 PM, Howard Moon  wrote:
>> 
>> Either use NSActionCell, or derive your own class from NSCell and implement 
>> it.
> 
> 
>> On Mar 16, 2019, at 6:08 PM, Rob Petrovec  wrote:
>> 
>> This is expected and documented behavior.  From 
>> https://developer.apple.com/documentation/appkit/nscell/1532348-tag?language=objc
>> 
>> Setting the value of this property raises with 
>> NSInternalInconsistencyException. Subclasses are expected to override this 
>> property if they support tags
>> 
>> If you want to use tags, you should subclass NSImageCell and implement -tag 
>> & -setTag: to return your own ivar.  Hope that helps.
>> 
>> —Rob
>> 
>> 
>>> On Mar 16, 2019, at 7:03 PM, Carl Hoefs  
>>> wrote:
>>> 
>>> macOS 10.12, ObjC
>>> 
>>> Is it not possible to set the tag of an NSImageCell at runtime? 
>>> 
>>> At runtime when I do "myCell.tag = val;" I get a warning:  
>>>  Stub implementation of -setTag by NSCell does nothing.
>>> 
>>> I have an array of 48 NSImageCells. I can't hard-code them in Xcode because 
>>> don't know the tag values until runtime.
>>> How can I accomplish this? 
>>> 
>>> -Carl
>>> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Setting the tag of an NSCell

[Rob Petrovec]

This is expected and documented behavior.  From 
https://developer.apple.com/documentation/appkit/nscell/1532348-tag?language=objc

Setting the value of this property raises with NSInternalInconsistencyException 
.
 Subclasses are expected to override this property if they support tags

If you want to use tags, you should subclass NSImageCell and implement -tag & 
-setTag: to return your own ivar.  Hope that helps.

—Rob


> On Mar 16, 2019, at 7:03 PM, Carl Hoefs  
> wrote:
> 
> macOS 10.12, ObjC
> 
> Is it not possible to set the tag of an NSImageCell at runtime? 
> 
> At runtime when I do "myCell.tag = val;" I get a warning:  
>   Stub implementation of -setTag by NSCell does nothing.
> 
> I have an array of 48 NSImageCells. I can't hard-code them in Xcode because 
> don't know the tag values until runtime.
> How can I accomplish this? 
> 
> -Carl
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Silly question on extending NSObject.

[Rob Petrovec]

> On Feb 19, 2019, at 7:23 PM, Alex Zavatone  wrote:
> 
> 
>> On Feb 19, 2019, at 4:15 PM, Jens Alfke  wrote:
>> 
>> 
>> 
>>> On Feb 19, 2019, at 1:23 PM, Alex Zavatone >> > wrote:
>>> 
>>> In most Objective-C projects I add an autodescribe category on NSObject and 
>>> put the import for the category header into a .pch for the project so that 
>>> it will be available for every class in the project.
>>> This lets me dump an object’s properties and values at Will in the debugger.
>> 
>> 
>> I’m not sure what this does that the existing -description and 
>> -debugDescription methods don’t do?
> 
> This.
> 
> (lldb) po self.data
> 
> 
> (lldb) po [self.data description]
> 
> 
> (lldb) po [self.data autoDescribe]
If you override -debugDescription in your custom classes to spew 
whatever you want them to spew, you can just do ‘po self.data’ in the debugger 
and it will spew out your custom data.

—Rob

 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Silly question on extending NSObject.

[Rob Petrovec]

Why not use/override -description or -debugDescription instead of re-inventing 
the wheel?

—Rob

> On Feb 19, 2019, at 2:23 PM, Alex Zavatone  wrote:
> 
> Sorry.  Second try.
> 
> In most Objective-C projects I add an autodescribe category on NSObject and 
> put the import for the category header into a .pch for the project so that it 
> will be available for every class in the project.
> 
> This lets me dump an object’s properties and values at Will in the debugger.
> 
> Is there a more modern way to do this than using a .pch?
> 
> I’ll also be adding one for Swift and am interested in approaches for both.  
> 
> Put the import in Settings.xcconfig files?
> 
> Thanks in advance
> 
> Sent from my iPhone
> 
>> On Feb 19, 2019, at 3:15 PM, Alex Zavatone  wrote:
>> 
>> In most Objective-C projects I add an autodescribe category and put the
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Diagnosing memory problems

[Rob Petrovec]

Actually, you want the Zombies tool.  That finds overreleased objects like ones 
that cause the spew you are seeing.

—Rob


> On Nov 27, 2018, at 4:52 PM, Rob Petrovec  wrote:
> 
> Check out the Leaks tool in Instruments (inside Xcode.app)
> 
> —Rob
> 
> 
>> On Nov 27, 2018, at 3:56 PM, Casey McDermott  wrote:
>> 
>> Our main window has a tool bar across the top, an outline view on the left, 
>> and a tab view on the right.  Choosing an item from the outline view fills a 
>> data entry screen into a new tab on the right. 
>> 
>> We started out using OS 10.11, but just switched to newer OS versions.  
>> 10.12 has a couple display quirks but runs OK.  In 10.13 and newer, 
>> switching tabs often crashes.  It gives a warning about releasing a data 
>> entry field that is already released.
>> 
>> In C++, we would diagnose this with a breakpoint in the destructor and then 
>> check the stack trace.  But with ARC, a breakpoint at dealloc just shows 
>> performDelayedCleanup and then main.  No clues to what's wrong.
>> 
>> Is there lore or are there tools for tracking object lifetimes in Obj-C/ARC?
>> 
>> Anything that changed in 10.13 that might be biting us?
>> 
>> Thanks,
>> 
>> Casey McDermott
>> TurtleSoft.com
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
>> 
>> This email sent to petr...@mac.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Diagnosing memory problems

[Rob Petrovec]

Check out the Leaks tool in Instruments (inside Xcode.app)

—Rob


> On Nov 27, 2018, at 3:56 PM, Casey McDermott  wrote:
> 
> Our main window has a tool bar across the top, an outline view on the left, 
> and a tab view on the right.  Choosing an item from the outline view fills a 
> data entry screen into a new tab on the right. 
> 
> We started out using OS 10.11, but just switched to newer OS versions.  10.12 
> has a couple display quirks but runs OK.  In 10.13 and newer, switching tabs 
> often crashes.  It gives a warning about releasing a data entry field that is 
> already released.
> 
> In C++, we would diagnose this with a breakpoint in the destructor and then 
> check the stack trace.  But with ARC, a breakpoint at dealloc just shows 
> performDelayedCleanup and then main.  No clues to what's wrong.
> 
> Is there lore or are there tools for tracking object lifetimes in Obj-C/ARC?
> 
> Anything that changed in 10.13 that might be biting us?
> 
> Thanks,
> 
> Casey McDermott
> TurtleSoft.com
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: iCloud does not appear on open, save or move to dialogs for Mac Document based app

[Rob Petrovec]

Does it show up in the Finder’s Sidebar?  Do you have the iCloud Drive checkbox 
checked in the Finder Preferences -> Sidebar section?  If it is disabled there 
it won’t show up in the Finder or open/save dialogs.

—Rob


> On Nov 19, 2018, at 1:16 AM, Jim McGowan  wrote:
> 
> Hi,
> 
> I posted this on the Developer Forums a week ago, but unfortunately i didn’t 
> receive any replies.  Perhaps someone here can help.
> 
> I have an existing Core Data document based app, my document class is a 
> sublcass of NSPersistentDocument, and I use an XML store type.  My next 
> update will move to being Mac App Store exclusive, so I can take advantage of 
> iCloud features and I want to add iCloud Documents.
> 
> I turned on the iCloud Capability in XCode, and checked the "iCloud 
> Documents" option under "Services:"  I'm using the default container option.  
> I can see the container has been created in the local file system, and I can 
> also see in listed on developer.apple.com under my account > Certifiates, 
> Identifiers & Profiles > iCloud Containers.
> 
> In my App Delegate's +initialize method I use GCD to dispatch a call to 
> [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil] on a 
> background queue.  This method correctly returns the URL for the container.
> 
> However, when I run my app, I don't see the iCloud container listed in either 
> the sidebar or popup menu in open and save dialogs, and neither do I see it 
> in popup menu in the Move To... dialogue.
> 
> Am I missing some additional steps?
> 
> Thanks,
> Jim
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Bothersome "NSView-Encapsulated-Layout-Height" constraint?

[Rob Petrovec]

You need to implement -outlineView:heightOfRowByItem: to return the height you 
want for each row.  Hope that helps.

—Rob


> On Aug 30, 2018, at 6:23 PM, Demitri Muna  wrote:
> 
> Hi,
> 
> I’ve been hitting my head against a wall for more time than I’d like to admit 
> on what should be a simple problem - maybe someone can spot it immediately…
> 
> I’m implementing a view-based source list style NSOutlineView (I’m trying to 
> mimic the Finder sidebar). My header items are a different row height than 
> the items underneath. I’ve implemented outlineView:rowViewForItem: (returns 
> 24 for headers, 20 for items).
> 
> The rows are spaced as expected in the column, but they are not drawn 
> correctly. The cell is cropped to 12 pixels, as seen here:
> 
> https://imgur.com/a/7KKgtZX
> 
> I expect the highlighting to extend to the full height of the row. I tried to 
> force this by adding two constraints, 2 pixels above and below the image, 
> then got this:
> 
> 2018-08-30 14:55:36.807612-0400 Nightlight[78272:15775715] [Layout] Unable to 
> simultaneously satisfy constraints:
> (
>" 16   (active)>",
>" (active, names: DE_DataCell:0x60c000188470, '|':DE_DataCell:0x60c000188470 
> )>",
>" (active, names: DE_DataCell:0x60c000188470, '|':DE_DataCell:0x60c000188470 
> )>",
>" DE_DataCell.height == 12   (active, names: DE_DataCell:0x60c000188470 )>"
> )
> 
> This shows where the problem is: a height constraint on the row of 12 with 
> the name "NSView-Encapsulated-Layout-Height”. This is the exact height I see 
> being drawn. I have no idea where this is coming from or how to fix it 
> though. Any help welcome - it’s annoying because this seems like such simple 
> thing!
> 
> Demitri
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSComboBox

[Rob Petrovec]

I was going to suggest the same thing.  NSPopUpButton should do what you want.

—Rob


> On Jul 25, 2018, at 12:51 PM, Jens Alfke  wrote:
> 
> 
> 
>> On Jul 25, 2018, at 10:45 AM, Casey McDermott  wrote:
>> 
>> The goal is to auto-fill an account from what they type, and ignore typing 
>> if not a match.
> 
> That sounds like the regular behavior of NSPopUpButton: after clicking to pop 
> up the menu, you can type-select items from it. 
> 
> (Although it doesn't ignore mismatches, it just selects the closest item.)
> 
> —Jens
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Deleting files extremely slow since OSX High sierra

[Rob Petrovec]

> On Apr 25, 2018, at 9:32 AM, Vojtěch Meluzín  
> wrote:
> apple forcing devs to change stuff all the time (wasting our time) is just sad
FSDeleteObject was deprecated in 10.8. That was 5 releases & 5 years 
ago.  So I don’t know what you mean by “forcing devs to change stuff all  the 
time”.  You’ve had 5 years to update your code.  They also haven’t killed the 
API yet.  It still works, just slower then you would like.  You can’t expect 
them to keep a deprecated API running perfectly in perpetuity.  That would be 
silly and a waste of Apple’s engineering resources.  Its time for you to poop 
or get off the pot, so to speak.


> On Apr 25, 2018, at 10:45 AM, MeldaProduction  
> wrote:
> If you have a function to "delete a
> file", it will still be a function to delete a file, there's no
> improvement! Apple is simply covering badly designed APIs, which do work,
> they are far from ideal, but they work
Its not a design issue here.  FSDeleteObject uses FSRef’s.  FSRefs were 
a big improvement over FSSpecs from back in the day, but FSRefs have been 
deprecated in favor of URLs for years.  URLs are leaps and bounds better then 
FSRef’s.  So that is what Apple improved by introducing new API that uses URLs 
and deprecating the older FSRef equivalents.


> On Apr 25, 2018, at 10:25 AM, Dave  wrote:
> Well if you consider the use of “gasoline” as an “update” on steam power,
Fine, then use solar power vs coal, Calculators vs an Abacus, or a 
MacBook Pro vs a IBM 026  Keypunch 
(google it) as an analogy.  They all apply just as well.


> On Apr 25, 2018, at 11:45 AM, David Young  wrote:

> This hateful stuff doesn't really belong on this list, does it?
Agreed.

—Rob


> On Apr 25, 2018, at 9:32 AM, Vojtěch Meluzín  
> wrote:
> 
> Thanks Mike,  i'll probably try. I am reluctant to do that, because api is
> api and apple forcing devs to change stuff all the time (wasting our time)
> is just sad. Plus i just cannot imagine how it could cause things to be
> that bad. And finally people here seem to report general problems... Well
> apple... Anyways i'll try.
> 
> Cheers!
> Vojtech
> www.meldaproduction.com
> 
> Dne po 23. 4. 2018 13:36 uživatel Mike Throckmorton <
> mike1throckmor...@gmail.com> napsal:
> 
>> Try replacing FSDeleteObject with [[NSFileManager defaultManager]
>> removeItemAtPath: pth error: ];
>> 
>> Worked for me.
>> 
>> Delete of folder containing 7500 files went from reay slow down to
>> nice and quick.
>> 
>> I also found that other older FSRef based api's got slow.
>> 
>> Sandboxing? Discouraging use of elderly API's?
>> 
>> Time to ditch the old stuff anyway.
>> 
>> Vojtûch Meluzín Sunday, April 22, 2018 9:55 PM
>> 
>>> Hi,
>>> 
>>> I have a custom installer, which places various audio plugins (bundles)
>>> onto the target system and as an uninstaller it removes them. It manages
>>> them the same way as any other folder (containing folders and files).
>> Since
>>> OSX High sierra deleting these files became extremely slow, almost like
>> the
>>> OSX is checking the bundles after every change. On some computers it also
>>> blocks write access to the files inside these bundles (e.g. if the
>>> installer is used again). It almost seems like some pseudosecurity
>> measure
>>> gone wrong, not the first time on OSX after all...
>>> 
>>> Any ideas what is going on? For the record I'm using FSDeleteObject to
>>> delete files/folders, I know deprecated, but I don't see a reason for
>>> messing up with new API if the old one works.
>>> 
>>> Thanks in advance.
>>> Vojtech
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> 
>> https://lists.apple.com/mailman/options/cocoa-dev/mike1throckmorton%40gmail.com
>>> 
>>> This email sent to mike1throckmor...@gmail.com
>> ---
>> Mike Throckmortonmike1throckmor...@gmail.com
>> Software Engineer
>> My Mac running Mac OS X has been up 4 days,
>> 
>> running Mac OS X and it's starting to drift.
>> 
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator 

Re: Persistent User Defaults

[Rob Petrovec]

> On Apr 24, 2018, at 11:42 AM, Richard Charles  wrote:
> 
> On macOS an applications user defaults are stored in a preference plist file 
> located in ~/Library/Preferences.
Thats not entirely accurate.  They can be in various locations, 
including but not limited to ~/Library/Preferences/ByHost, /Library/Preferences 
& /Library/Preferences/ByHost


> If this file is deleted, user preferences for the application still persist 
> until the machine is rebooted. In other words if you want to start with a 
> clean set of user preferences not only must you delete the preference plist 
> file but you must also restart the machine.
> 
> Can anyone shed light on this behavior?
You should use the ‘defaults’ command in Terminal to do modifications 
like this (see 'man defaults’ for more info).  It will cause CFPreferences to 
reload the prefs for the effected app automagically.  If you want to blow away 
all the prefs for an app use ‘defaults delete ’.  If you 
want to load a pre-configured .plist use 'defaults import  ’.

Hope that helps.

—Rob



___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Deleting files extremely slow since OSX High sierra

[Rob Petrovec]

> On Apr 23, 2018, at 1:30 AM, Alex Zavatone <z...@mac.com> wrote:
> 
> 
>> On Apr 22, 2018, at 11:22 PM, Rob Petrovec <petr...@mac.com> wrote:
>> 
>>> VTDecodedXPCservice takes 147% of the processor cores on one of my boxes. 
>>  That is to be expected if you are playing any video or audio, and is 
>> not new to High Sierra.  There are tons of reports online about it taking 
>> alot of CPU.
>> 
>> 
>> I am not hitting these issues and I use APFS on all my partitions.  I don’t 
>> have any third party system mods installed on my machine.  Maybe its not the 
>> file system, but some app you have installed that is effecting the OS?  
>> Wouldn’t be the first time that has happened.
> 
> I’ve got 5 Macs.  These errors are common across many of them.
> 
>> 
>> Have any of you filed bug reports about the issues you are seeing, including 
>> but not limited to a sysdiagnose,
> 
> No, because historically, all the time I have spent on reporting issues has 
> been an utter waste of my time.  
For the most part, I have had the opposite experience over the years.  
Typically, the bugs either gets duped to one they already have, or they ask for 
additional information which I provide.  Sometimes the bug sits for a while, 
but they all have gotten resolved one way or another.  From talking to some 
Apple Engineers at WWDC over the years, the bar to get a bug fixed in a 
software update is pretty high. They would rather allow a bug to continue to 
exist then possibly introduce a regression.  Its the devil you know vs the 
devil you don’t kind of thing with a serious risk vs reward evaluation.  It is 
much easier for them to get a fix into a major release (e.g. 10.13(.0)), so the 
wait to see a fix is typically over a year.
If you report it and they don’t fix it after a major release, then you 
have all the right in the world to complain. However, if you don’t report it, 
IMO, you don’t have any right to complain.


> Recently I reported a text failure in Mail, added instructions and a sample 
> to reproduce it.  They reported it fixed.  I spent my time to check on the 
> latest Mac OS and it’s not fixed.  I marked the bug as Still Open As Written. 
>  Nothing’s been done about it since.  My time has been triply wasted as a 
> result.  
How long ago did you mark it SOAW?  No offense but if there hasn't been 
a full OS release cycle since then I think you may be a little overly critical, 
cynical and impatient.  As I said above, getting a bug into a software update 
is very difficult.  The reward has to be significantly higher then the risk.  
So maybe it will get fixed in the next major release or they are having trouble 
reproducing or something benign like that?


> I don’t have time to professionally do Apple’s job for them and they aren’t 
> paying me to.
I agree.  However, you also can’t expect Apple to be able to test all 
possible configurations or scenarios.  That would be physically & statistically 
impossible.  That is one reason they have the beta program, to get a wider 
audience before the public release.  Without (well written) bug reports from 
devs, they may never know about issues like this.  Especially since issues like 
this are highly configuration dependent.


> Maybe one issue has been fixed, but the point is that our time is wasted when 
> something fails.  We have to spend more of our time to find a workaround.  I 
> don’t have time to do that, report their bugs with no guarantee that it may 
> get addressed.
So by that logic, you are saying that in the products you work on, 
every single issue reported by users is addressed & fixed in a timely manor?  
If not, with your relatively small app compared to their huge OS, how could you 
expect Apple too?  If you can’t guarantee that every single user issue is fixed 
in your products how could you possibly expect Apple?  Seriously.

—Rob


>> spindump, Instruments System Trace taken _while_ the slowness was occurring. 
>> If your issue is related to being connected to an SMB share, you should 
>> include info about the server you are connecting to (e.g. OS on the Server, 
>> WiFi or Ethernet, large or small network etc etc)?  If your issue is I/O 
>> bound, then an lsof run taken during the slow I/O session is also useful.  
>> Without that kind of info there isn’t any way they can possibly fix it.  
>> Just sayin’…  Maybe reply to this thread with the bug numbers you’ve filed 
>> in case an Apple Engineer sees this thread.
>> 
>> —Rob
> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Deleting files extremely slow since OSX High sierra

[Rob Petrovec]

> VTDecodedXPCservice takes 147% of the processor cores on one of my boxes. 
That is to be expected if you are playing any video or audio, and is 
not new to High Sierra.  There are tons of reports online about it taking alot 
of CPU.


I am not hitting these issues and I use APFS on all my partitions.  I don’t 
have any third party system mods installed on my machine.  Maybe its not the 
file system, but some app you have installed that is effecting the OS?  
Wouldn’t be the first time that has happened.

Have any of you filed bug reports about the issues you are seeing, including 
but not limited to a sysdiagnose, spindump, Instruments System Trace taken 
_while_ the slowness was occurring. If your issue is related to being connected 
to an SMB share, you should include info about the server you are connecting to 
(e.g. OS on the Server, WiFi or Ethernet, large or small network etc etc)?  If 
your issue is I/O bound, then an lsof run taken during the slow I/O session is 
also useful.  Without that kind of info there isn’t any way they can possibly 
fix it.  Just sayin’…  Maybe reply to this thread with the bug numbers you’ve 
filed in case an Apple Engineer sees this thread.

—Rob


> On Apr 22, 2018, at 11:26 PM, Richard Charles  wrote:
> 
>> On Apr 22, 2018, at 8:48 PM, Steve Mills  wrote:
>> 
>> There’s definitely something rotten in 10.13. After a few days of using 
>> Safari, closing windows or doing new searches will take around 30 seconds. 
>> Quicklooking jpgs in Finder will become sluggish. Only a robot seems to fix 
>> it for a few days, then everything starts slowing down again, getting worse 
>> and worse as the days go on.
> 
> It looks like others are also experiencing slow issues with High Sierra.
> 
> https://discussions.apple.com/thread/8155686
> 
>> On Nov 10, 2017 thadwald wrote:
>> 
>> imac unusably slow after high sierra upgrade 
>> 
>> i have a 2014 27" i7 retina imac. it has slowed to the point of being 
>> unusable after upgrading to high sierra. simply opening finder takes more 
>> than 5 minutes before the files are done displaying and the beachball stops.
> 
> This sounds exactly like what happened to my High Sierra machine on Friday (2 
> days ago). This was a clean machine. Very little had been done on the machine 
> since a clean install of High Sierra about one month ago. It happened all of 
> a sudden when I was messing around with file sharing. It was so bad that the 
> only thing I could think of doing was another clean install.
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Pasteboard and NSImage and Finder

[Rob Petrovec]

Nope.  Pasteboard does not support ‘promised' data like drags do.  Sorry.  You 
could write them to a temporary folder (e.g. NSTemporaryDirectory()) and then 
stuff the URLs on the pasteboard.

—Rob


> On Apr 10, 2018, at 12:44 PM, Daniel Santos <daniel.d...@gmail.com> wrote:
> 
> That thought crossed my mind. I don’t want to write the file to disk, just 
> have a NSFile object in memory, is that possible ?
> 
> Daniel
> 
>> On 9 Apr 2018, at 23:25, Rob Petrovec <petr...@mac.com> wrote:
>> 
>> You need to put files on the pasteboard.  Finder only plays with files, not 
>> raw image data.
>> 
>> —Rob
>> 
>> 
>>> On Apr 9, 2018, at 4:12 PM, Daniel Santos <daniel.d...@gmail.com> wrote:
>>> 
>>> Hello all,
>>> 
>>> I am pasting an array of NSImage to the general pasteboard. (using 
>>> pasteboard .writeObjects())
>>> I would like to be able to paste the images onto Finder. What do I need to 
>>> do ?
>>> 
>>> Thanks in advance
>>> ___
>>> 
>>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>> 
>>> Please do not post admin requests or moderator comments to the list.
>>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>> 
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
>>> 
>>> This email sent to petr...@mac.com
>> 
> 

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Pasteboard and NSImage and Finder

[Rob Petrovec]

You need to put files on the pasteboard.  Finder only plays with files, not raw 
image data.

—Rob


> On Apr 9, 2018, at 4:12 PM, Daniel Santos  wrote:
> 
> Hello all,
> 
> I am pasting an array of NSImage to the general pasteboard. (using pasteboard 
> .writeObjects())
> I would like to be able to paste the images onto Finder. What do I need to do 
> ?
> 
> Thanks in advance
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: assertion failure

[Rob Petrovec]

It’s saying that you are doing it wrong.  Utility windows cannot go full 
screen.  You have yours set to go full screen.  It shouldn’t be.

—Rob


> On Apr 7, 2018, at 10:24 AM, Alan Snyder  wrote:
> 
> I am getting an assertion failure notice on the console when running a small 
> test program:
> 
> Assertion failure in -[AWTWindow_Panel _validateCollectionBehavior:], 
> /Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1504.83.101/AppKit.subproj/NSWindow.m:14741
> 
> (This message is on 10.12.6, the details are different on 10.13.)
> 
> When run under Xcode, there is more information: utility panels cannot be 
> fullscreen primary
> 
> My question—does this represent a bug in AppKit that I should report, or is 
> it trying to help me by explaining that my program provided an unsupported 
> set of style bits when creating a window?
> 
>  Alan
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: problem getting CALayer to draw an image

[Rob Petrovec]

If you take out the setNeedsDisplay it draws ok.

—Rob


> On Apr 5, 2018, at 11:53 AM, James Walker  wrote:
> 
> I have a generic NSView that contains some subviews, and I'd like to add a 
> background image.  I tried code like this:
> 
> NSImage* backgroundImage = [NSImage imageNamed: @"blueprint controls.png"];
> CALayer* holderLayer = [CALayer layer];
> _throttleHolder.layer = holderLayer;
> _throttleHolder.wantsLayer = YES;
> holderLayer.zPosition = 4.0f;
> holderLayer.contents = backgroundImage;
> holderLayer.hidden = NO;
> holderLayer.bounds = NSRectToCGRect( _throttleHolder.bounds );
> [holderLayer setNeedsDisplay];
> 
> But no background image shows up.  On the other hand, if I add the line
> 
> holderLayer.backgroundColor = CGColorGetConstantColor( kCGColorWhite );
> 
> then I get a white background, so apparently the layer is there and capable 
> of drawing.  And yes, I have made sure that backgroundImage is not nil.
> 
> At this point, it probably would have been quicker to just go ahead and 
> subclass NSView, but I'm curious about what dumb mistake I'm making.
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: tooltip on nscollection view item

[Rob Petrovec]

Or just use NSView -toolTip

—Rob


> On Feb 7, 2018, at 7:26 AM, Pier Bover  wrote:
> 
> You could use an NSPopover:
> 
> let myPopover = NSPopover()
>> let storyboard = NSStoryboard(name: NSStoryboard.Name(rawValue: "Main"),
>> bundle: nil)
>> let identifierPopover = NSStoryboard.SceneIdentifier(rawValue:
>> "MyPopoverViewController")
>> myPopover.contentViewController =
>> storyboard.instantiateController(withIdentifier: identifierPopover) as?
>> MyPopoverViewController
>> myPopover.show(relativeTo: myView.bounds, of: myView, preferredEdge:
>> NSRectEdge.minY)
> 
> 
> On Wed, Feb 7, 2018 at 7:39 AM, Daniel Santos  > wrote:
> 
>> Hello all,
>> 
>> I have a resizable collection view where each element is an NSImageView.
>> I want to show a tooltip with some information on each item.
>> 
>> How do I accomplish this ?
>> Thanks in advance
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/pierbover11%40gmail.com 
>> 
>> 
>> This email sent to pierbove...@gmail.com 
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
> )
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
> 
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com 
> 
> 
> This email sent to petr...@mac.com 
___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Creating NSTableView programmatically

[Rob Petrovec]

Not for nothin', but I don’t think bindings have died. They are still supported 
and used all over the OS.  I use them all the time in my code too.  They are 
very useful.  Bindings are built onto of KVO, which is a fundamental technology.

—Rob


> On Dec 20, 2017, at 3:40 PM, Richard Charles  wrote:
> 
> 
>> On Dec 20, 2017, at 3:23 AM, Quincey Morris 
>>  wrote:
>> 
>> In effect, the whole thing with bindings died at 10.5, except for the part 
>> where they were used within IB to hook up specific controls to specific 
>> properties. That part is really all we use today.
> 
> It does seem like bindings died but I have found them very useful.
> 
> https://stackoverflow.com/questions/1169097/can-you-manually-implement-cocoa-bindings
> 
> https://www.tomdalling.com/blog/cocoa/implementing-your-own-cocoa-bindings/
> 
>> On Dec 20, 2017, at 3:07 PM, Charles Srstka  wrote:
>> 
>> I doubt I would have gone to the trouble of making it do that if I’d had to 
>> write the glue code manually.
> 
> For me it was a trade off. Do I invest time in learning bindings or become 
> really good at writing glue code. I suppose it would have worked either way 
> but for some reason I choose bindings.
> 
> --Richard Charles
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/petrock%40mac.com
> 
> This email sent to petr...@mac.com

___

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

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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