Re: Full-screen not working

[Gary L. Wade via Cocoa-dev]

I would suggest asking your user for a system report or sysdiagnose.  It might 
glean some details about their environment.
--
Gary

> On Aug 15, 2023, at 3:30 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I have one user of my macOS app (under macOS 13.4.1) 
> where the app does not want to go into full-screen mode.
> 
> It is a pretty plain app.
> 
> In the AppDelegate's method -applicationWillFinishLaunching,
> I switch to full screen like this:
> 
>   [self.window toggleFullScreen: nil];  
> 
> It works, of course, all the time on my Mac; 
> also, as far as I know, there is only one user where it does not work.
> 
> After toggleFullScreen, I could check if the window is in full-screen, but I 
> don't see I would gain anything from that.
> The toggleFullScreen does not seem to provide any error value.
> 
> I have already googled, but it seems like what that user reports does not 
> happen anywhere else.
> 
> Is there anything that could prevent a window from going into fullscreen mode?
> 
> 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: Retrieving the EXIF date/time from 250k images

[Gary L. Wade via Cocoa-dev]

You don’t seem to understand modern filesystems or modern hardware like some of 
us.
--
Gary L. Wade
https://www.garywade.com/ 

> On Jan 7, 2023, at 3:29 PM, Gabriel Zachmann  wrote:
> 
> *Maybe* ...
> that would mean that the filesystem performs predictive caching like the 
> CPU's cache / memory management does ... 
> 
> Also, I think you might even get worse performance: imagine several threads 
> reading different files *at the same time* - those files could lie on 
> different HD cylinders far apart from each other, so the disk heads would 
> have to move back and forth during those concurrent read operations, wouldn't 
> it? unless the disk would do some very clever caching / batching / prediction 
> itself ...
> 
> G.
> 
>> Since file systems and the associated hardware are designed to be efficient 
>> by caching data and knowing things like where one file or block is in 
>> relation to another, there’s a possibility these mechanisms could work to 
>> your advantage, pulling in the data while “in the neighborhood.” There’s no 
>> guarantee, of course, but I feel it’s worth considering.
>> --
>> Gary L. Wade
>> http://www.garywade.com/
>> 
>>> On Jan 7, 2023, at 10:37 AM, Gabriel Zachmann via Cocoa-dev 
>>>  wrote:
>>> 
>>> So, why would would several threads loading those images in parallel help 
>>> here? In my thinking, they will just compete for the same resource, i.e., 
>>> hard disk.
>>> 
>> 
> 

___

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: Retrieving the EXIF date/time from 250k images

[Gary L. Wade via Cocoa-dev]

Since file systems and the associated hardware are designed to be efficient by 
caching data and knowing things like where one file or block is in relation to 
another, there’s a possibility these mechanisms could work to your advantage, 
pulling in the data while “in the neighborhood.” There’s no guarantee, of 
course, but I feel it’s worth considering.
--
Gary L. Wade
http://www.garywade.com/

> On Jan 7, 2023, at 10:37 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> So, why would would several threads loading those images in parallel help 
> here? In my thinking, they will just compete for the same resource, i.e., 
> hard disk.
> 

___

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: Retrieving the EXIF date/time from 250k images

[Gary L. Wade via Cocoa-dev]

You should do any whitespace trimming first and be sure your date formatter is 
set correctly as any deviation will almost always fail.
--
Gary

> On Aug 15, 2022, at 2:51 AM, Gabriel Zachmann  wrote:
> 
> A detail I left out in-between: whitespace trimming.
> 
> Or, does anyone know if dateFromString will handle trailing/leading 
> whitespaces gracefully?

___

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: Retrieving the EXIF date/time from 250k images

[Gary L. Wade via Cocoa-dev]

I noticed you release the fileProps but didn’t release the image, but I don’t 
know if that’s one of those details you left out for clarity.  Also, depending 
on some factors like mutability, while the initWithString call with a 
CFStringRef might essentially be a no-op, you can just do the typecast on the 
dateref and pass it directly into dateFromString.

One thing I’d suggest is to do the work for each image asynchronously on a 
background queue and have that block (essentially all of your for-loop code) 
report its completion by some asynchronous way like posting a notification on 
the original queue along with the result you care about, the parsed date 
associated with the particular file.  Let the original queue handle how to 
store each parsed date; it would probably be best to use a dictionary where the 
key was the filename and value is the date.  To prevent memory pressure, 
allocate your background queue so that it’s concurrent and autorelease 
frequency is set to be workItem.  If you want to be sure to know when 
everything’s done, you could use a DispatchGroup to track those and you could 
choose to pass back NSNull or nil for the parsed result if the date could not 
be parsed.

Of course, this will depend on if your file system is non-network-based and 
whether it’s SSD vs HD as well as other physical system factors.
--
Gary

> On Aug 14, 2022, at 2:22 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> I would like to collect the date/time stored in an EXIF tag in a bunch of 
> images.
> 
> I thought I could do so with the following procedure
> (some details and error checking omitted for sake of clarity):
> 
> 
>NSMutableArray * dates_and_times = [NSMutableArray arrayWithCapacity: 
> [imagefiles count]];
>CFDictionaryRef exif_dict;
>CFStringRef dateref = NULL;
>for ( NSString* filename in imagefiles )
>{
>NSURL * imgurl = [NSURL fileURLWithPath: filename isDirectory: NO];
> // escapes any chars that are not allowed in URLs (space, &, etc.)
>CGImageSourceRef image = CGImageSourceCreateWithURL( (__bridge 
> CFURLRef) imgurl, NULL );
>CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex( image, 
> 0, NULL );
>bool success = CFDictionaryGetValueIfPresent( fileProps, 
> kCGImagePropertyExifDictionary, (const void **) & exif_dict );
>success = CFDictionaryGetValueIfPresent( exif_dict, 
> kCGImagePropertyExifDateTimeDigitized, (const void **) & dateref );
>NSString * date_str = [[NSString alloc] initWithString: (__bridge 
> NSString * _Nonnull)( dateref ) ];
>NSDate * iso_date = [isoDateFormatter_ dateFromString: date_str];
>if ( iso_date )
> [dates_and_times addObject: iso_date ];
>CFRelease( fileProps );
>}
> 
> 
> But, I get the impression, this code actually loads each and every image.
> On my Macbook, it takes 3m30s for 250k images (130GB).
> 
> So, the big question is: can it be done faster?
> 
> I know the EXIF tags are part of the image file, but I was hoping it might be 
> possible to load only those EXIF dictionaries.
> Or are the CGImage functions above already clever enough to implement this 
> idea?
> 
> 
> Best regards, 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: Exception not being caught in try statement

[Gary L. Wade via Cocoa-dev]

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

Re: How to parse a log file

[Gary L. Wade via Cocoa-dev]

Line 7 appears to show your app allocating an array with one of its objects 
being nil.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 26, 2020, at 3:02 PM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> From a user, I received a log file that contains an error (see below)
> and a stack trace of my macOS app.
> 
> Is it possible to determine the exact line in the source code where the error 
> occurred?
> 
> Best regards, Gabriel
> 
> 
> Encl:
> excerpt from log.
> "ArtSaverApp"  is my macOS app.
> 
> 
> 2020-10-23 10:47:30.410560-0400 0x2318dError   0x0  
> 6750   0ArtSaverApp: (AppKit) [com.apple.AppKit:General] *** 
> -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object 
> from objects[0]
> 2020-10-23 10:47:30.433412-0400 0x2318dError   0x0  
> 6750   0ArtSaverApp: (AppKit) [com.apple.AppKit:General] (
>0   CoreFoundation  0x7fff2d796b57 
> __exceptionPreprocess + 250
>1   libobjc.A.dylib 0x7fff664475bf 
> objc_exception_throw + 48
>2   CoreFoundation  0x7fff2d84559e -[__NSCFString 
> characterAtIndex:].cold.1 + 0
>3   CoreFoundation  0x7fff2d8438c4 
> -[__NSPlaceholderArray initWithCapacity:].cold.1 + 0
>4   CoreFoundation  0x7fff2d69a8ae 
> -[__NSPlaceholderArray initWithObjects:count:] + 154
>5   CoreFoundation  0x7fff2d6fff7e __createArray + 
> 47
>6   CoreFoundation  0x7fff2d6fff41 +[NSArray 
> arrayWithObject:] + 25
>7   ArtSaverApp 0x000109f12466 ArtSaverApp + 
> 46182
>8   ArtSaverApp 0x000109f1598d ArtSaverApp + 
> 59789
>9   AppKit  0x7fff2abcd7a7 
> -[NSApplication(NSResponder) sendAction:to:from:] + 299
>10  AppKit  0x7fff2abcd642 -[NSControl 
> sendAction:to:] + 86
>11  AppKit  0x7fff2abcd574 __26-[NSCell 
> _sendActionFrom:]_block_invoke + 136
>12  AppKit  0x7fff2abcd476 -[NSCell 
> _sendActionFrom:] + 171
>13  AppKit  0x7fff2abcd3bd -[NSButtonCell 
> _sendActionFrom:] + 96
>14  AppKit  0x7fff2abc969b 
> NSControlTrackMouse + 1745
>15  AppKit  0x7fff2abc8fa2 -[NSCell 
> trackMouse:inRect:ofView:untilMouseUp:] + 130
>16  AppKit  0x7fff2abc8e61 -[NSButtonCell 
> trackMouse:inRect:ofView:untilMouseUp:] + 691
>17  AppKit  0x7fff2abc81dd -[NSControl 
> mouseDown:] + 748
>18  AppKit  0x7fff2abc65f0 
> -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4914
>19  AppKit  0x7fff2ab30e21 
> -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 2612
>20  AppKit  0x7fff2ab301c9 
> -[NSWindow(NSEventRouting) sendEvent:] + 349
>21  AppKit  0x7fff2ab2e554 
> -[NSApplication(NSEvent) sendEvent:] + 352
>22  AppKit  0x7fff2a97b5bf -[NSApplication 
> run] + 707
>23  AppKit  0x7fff2a94d396 
> NSApplicationMain + 777
>24  libdyld.dylib   0x7fff675efcc9 start + 1
> )
> 

___

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: Relieving memory pressure

[Gary L. Wade via Cocoa-dev]

The vast majority of data used by a CGImageRef for any sufficiently 
representable image is going to be its bitmap data (a 1x1 pixel image 
wouldn’t), and you can calculate that by using CGImageGetBytesPerRow and its 
neighbor APIs.  If I recall from your previous posts, you are showing very 
detailed scans of artwork.  I believe NASA has a similar conundrum with their 
telescope data; perhaps there’s some open source solutions there that might 
help with your particular needs?  Just a thought.  Another thing I’d consider 
(which I haven’t personally done) is looking at what Metal can provide; you 
might have to drop down to that level for your needs.  And it may be just as 
important if you have a system with multiple large-format screens with so much 
data.
--
Gary L. Wade
http://www.garywade.com/ 

> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Good question.
> 
> Well, some users want to feed my app with image files of 100 MB, even up to 
> 400 MB (mostly jpeg compressed).
> Those images have resolutions of over 8k, sometimes over 10k.
> 
> The slideshow app needs to be able to zoom into those images with at least a 
> factor 2x scaling.
> 
> So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
> resolution maximum should be sufficient.
> 
> An 8k x 8k image needs at least 200 MB (1 byte per channel).
> I don't know how CGImage stores the uncompressed images internally,
> but my experience seems to indicate that it uses significantly more memory 
> than that.
> (maybe it uses two bytes per channel, or even floats, or there is some other 
> aux data)
> 
> 
>> 
>> What do you need a 1GB thumbnail for? There is no screen that can display 
>> that. For a slideshow app you could scale your thumbnails at creation time 
>> to the users biggest screen pixel size, don’t you think?
>> 
>> Christos Konidaris
>> 
> 
> ___
> 
> 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/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.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

[Gary L. Wade via Cocoa-dev]

Be sure you use leading and trailing rather than left and right for things that 
can change in direction for RTL. There are some small set of cases where you 
want left and right, but unless you’re aware of those, it’s best to always use 
leading and trailing.
--
Gary L. Wade
http://www.garywade.com/

> On May 27, 2020, at 12:51 PM, Rob Petrovec via Cocoa-dev 
>  wrote:
> 
> Plus it handles positioning views automagically between Left-To-Right 
> localizations like English and Right-To-Left localizations like Hebrew.

___

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

[Gary L. Wade via Cocoa-dev]

Also, did you take advantage of one of your free tech support incidents?
--
Gary L. Wade
http://www.garywade.com/

> On Apr 24, 2020, at 8:26 AM, Gary L. Wade via Cocoa-dev 
>  wrote:
> 
> That’s a very narrow view of reality, which I know to be far broader.
> 
> What’s the feedback number?
> --
> Gary
> 
>>> On Apr 24, 2020, at 8:01 AM, Allan Odgaard via Cocoa-dev 
>>>  wrote:
>> That said, I *have* filed a report about this, but I still seek more 
>> information about the issue, which I had hoped to get from this list, 
>> because I sure as hell am not going to get it via Apple’s bug reporting 
>> system.

___

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

[Gary L. Wade via Cocoa-dev]

That’s a very narrow view of reality, which I know to be far broader.

What’s the feedback number?
--
Gary

> On Apr 24, 2020, at 8:01 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> That said, I *have* filed a report about this, but I still seek more 
> information about the issue, which I had hoped to get from this list, because 
> I sure as hell am not going to get it via Apple’s bug reporting system.

___

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

[Gary L. Wade via Cocoa-dev]

Here’s two web sites that should help you get the answer you want. Try one or 
both:

https://feedbackassistant.apple.com/welcome
https://www.apple.com/jobs/us/
--
Gary
___

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

[Gary L. Wade via Cocoa-dev]

Have you tried a speed check with just iCloud turned off but internet on?
--
Gary
___

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

[Gary L. Wade via Cocoa-dev]

Regardless of whatever workaround you find, I would second Rob’s suggestion to 
go ahead and file a bug with a sysdiagnose and/or spindump along with a sample 
app that reproduces it.  This isn’t expected behavior, and the teams at Apple 
are still working and would be very interested in seeing this.  Once filed, if 
you do find a workaround, you can append that to the bug.
--
Gary L. Wade
http://www.garywade.com/ 

> On Apr 19, 2020, at 10:58 AM, Allan Odgaard via Cocoa-dev 
>  wrote:
> 
> On 20 Apr 2020, at 0:37, Rob Petrovec wrote:
> 
>> >> 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.
> 
> As written previously, there is no delay when running from terminal, and 
> ~/Downloads is also causing a delay, which is not stored on iCloud.
> 
> So this very much seems to be about Apple’s file system access policies where 
> permission must be obtained to access certain folders.
> 
> But as mentioned, I have given my app full disk access, reset permissions, 
> and I have even signed and notarized the app: Still no fix for the delay.
> 
> To indulge you, I have now also tried to log out of iCloud: Still a delay.
> 
> Now I would very much appreciate if someone would try the code I included in 
> my original email to see if this is a general problem, or something limited 
> to my system.
> 
> As I think I mentioned, I am running a fairly clean install of macOS 10.15.

___

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

[Gary L. Wade via Cocoa-dev]

Interesting.  This could be a layering issue then, and it could be due to a 
configuration unique to your customer’s setup.  Since you’re doing things on a 
lower level than expected, there may be some nuance you need to add or 
something Apple needs to fix that may work fine using higher level frameworks.  
Since there’s lots of little things going on, it definitely warrants a feedback 
report.  Please add its number to your reply when you submit it.

FYI, Apple has been putting a lot of effort to support RTL better; in one of 
this year’s early general presentations at WWDC, you might have seen an 
engineer talking about RTL support within the App Store on all devices (well, 
maybe not the HomePod, of course), and the labs definitely had staff there to 
help.  Where you may find your implementation better than what you see in the 
frameworks, please write as many feedback reports as needed so all developers 
can benefit from the desired changes.
--
Gary L. Wade
http://www.garywade.com/ 

> On Dec 19, 2019, at 6:09 AM, Redler Eyal  wrote:
> 
>>> 
>>> OK, I'll try to get the sysdiagnose from my users before submitting. I must 
>>> say I'm really skeptic regarding the relation with my use of CG. It is not 
>>> that CG is not used by CT and everything else is also using CG.
>> 
>> CG may not be the issue… and I cannot offer a better suggestion, but when I 
>> rule out a possibility without proof, it usually turns out that I over look 
>> the solution to the problem.  Good luck!
> 
> You're right, and I wasn't ruling it out. I actually sent my user a special 
> build with an defaults option to turn off page drawing (so the page views are 
> not doing any drawing CG or otherwise), the issue persists.
> 
> I also tried to see this issue while doing remote access using anyDesk, for 
> some reason, the issue never showed up, when I disconnected, it showed up 
> again.
> 
> Eyal
> 
> 
> 
>> Sandor
>> 
>>> The way it looks it seems very much related to the scrolling mechanism, the 
>>> pre-rendered portion is not rendered but for some reason the scrolling 
>>> mechanism thinks that it is. I really don't see how a core-graphic issue, 
>>> and certainly not a misuse on my part could cause a view to be partially 
>>> rendered.
>>> BTW, do you think this type of issue is appropriate for a DTS incident?
>>> 
 Here’s the developer release notes for Catalina:
 https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes
>>> 
>>> Thanks. I saw that but I recall that in the past you used to have app-kit 
>>> specific release notes which were usually more detailed. 
>>> 
 As an aside, it would be helpful to know why you chose CG for text 
 rendering. CT has gotten better with RTL and bidi text, but if you saw 
 particular issues there, reports about those can help everyone.
>>> 
>>> When I started developing this app (2002), there was no choice other then 
>>> CG since core text didn't exist and the other technologies didn't support 
>>> Hebrew and RTL well, if at all. So I wrote my own text engine and this was 
>>> very good for me commercially as my app was the the first and only 
>>> word-processor to support Hebrew (and later Arabic) properly on Max OS X. I 
>>> had a similar experience with OpenType which was not initially supported 
>>> and that also gave me an edge. As time passed Apple did improve the RTL 
>>> support and was offering more APIs so theoretically I could have rewritten 
>>> my code to use the new APIs but in reality I actually did the opposite and 
>>> relied less on Apple's APIs (for example, parsing 'cmap' tables) because 
>>> there were always bugs and even regressions which could render my app 
>>> unusable upon an OS upgrade. Beyond the bugs, I think my RTL is better, or 
>>> at least as far as I'm concerned as a native Hebrew speaker and having such 
>>> low-level control over something that is core to my app is essential IMO.
>>> 
>>> Eyal Redler
>>> 
>>> "If Uri Geller bends spoons with divine powers, then he's doing it the hard 
>>> way."
>>> --James Randi
>>> www.eyalredler.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 Gary L. Wade
 http://www.garywade.com/
 
>> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
> 
> I am drawing using core graphics. I tried turning copiesOnScroll and 
> this didn't seem to help.
> 
> I'll gladly write a feedback report but I'm not able to reproduce this so 
> I can't give an xcode project that will reproduce this... Isn't that a 
> requirement?
> 
> BTW, perhaps you know: Are there no release notes for app kit with 
> Catalina? All I can find are very general notes without mention of any 
> specific API. I could not find, for example, any mention of the 
> deprecation of copiesOnScroll and what it means (is is not always on, 
> 

Re: Catalina scroll view issues

[Gary L. Wade via Cocoa-dev]

Since you’re using CoreGraphics, it’s very likely there’s an edge case with 
your customers’ systems that you aren’t encountering.  CG is pretty much the 
lowest practical level in the graphics stack. Since your app does reproduce the 
issue but in other configurations than yours, you could still add it, but if 
you can include the system configuration data from About This Mac and data 
files from those affected customers, as well as screen shots, it can help. You 
might be asked for a sysdiagnose after the problem happens, so consider asking 
your customers to provide that as well.

Here’s the developer release notes for Catalina:
https://developer.apple.com/documentation/macos_release_notes/macos_catalina_10_15_release_notes

As an aside, it would be helpful to know why you chose CG for text rendering. 
CT has gotten better with RTL and bidi text, but if you saw particular issues 
there, reports about those can help everyone.
--
Gary L. Wade
http://www.garywade.com/

> On Dec 17, 2019, at 2:12 AM, Redler Eyal  wrote:
> 
> I am drawing using core graphics. I tried turning copiesOnScroll and this 
> didn't seem to help.
> 
> I'll gladly write a feedback report but I'm not able to reproduce this so I 
> can't give an xcode project that will reproduce this... Isn't that a 
> requirement?
> 
> BTW, perhaps you know: Are there no release notes for app kit with Catalina? 
> All I can find are very general notes without mention of any specific API. I 
> could not find, for example, any mention of the deprecation of copiesOnScroll 
> and what it means (is is not always on, always off etc)
> 
> Thanks,
> 
> Eyal
> 
>> On 16 Dec 2019, at 16:07, Gary L. Wade  wrote:
>> 
>> If you’re not involving a higher level class like NSTextView or a medium 
>> level one like CoreText, it sounds like you might be going all the way down 
>> to CoreGraphics? If so, you might find your disparity between your system 
>> and your users in things like retina choice for a particular display and 
>> changes with respect to layers, especially things like the copiesOnScroll. 
>> If these don’t lead you to a solution where you say, “Oh, I really should’ve 
>> done this rather than that,” (20/20 hindsight) then write up a feedback 
>> report and add its URL here.
>> --
>> Gary L. Wade
>> http://www.garywade.com/
>> 
 On Dec 16, 2019, at 1:03 AM, Redler Eyal via Cocoa-dev 
  wrote:
>>> 
>>> Thanks!
>>> I don't use CoreText or NSTextView. I pretty much ruled out RTL vs LTR 
>>> issues since this is showing up in documents containing either and both. 
>>> I'm also unable to imagine how some text drawing code could produce such 
>>> artifacts as splitting a subview in the middle.
>>> (http://eyalredler.com/stuff/catalina_glitch.png)
>>> 
>>> Eyal
>>> 
>>> 
>>> 
>>> 
 On 14 Dec 2019, at 21:20, Gary L. Wade  
 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
> 

Re: Catalina scroll view issues

[Gary L. Wade via Cocoa-dev]

If you’re not involving a higher level class like NSTextView or a medium level 
one like CoreText, it sounds like you might be going all the way down to 
CoreGraphics? If so, you might find your disparity between your system and your 
users in things like retina choice for a particular display and changes with 
respect to layers, especially things like the copiesOnScroll. If these don’t 
lead you to a solution where you say, “Oh, I really should’ve done this rather 
than that,” (20/20 hindsight) then write up a feedback report and add its URL 
here.
--
Gary L. Wade
http://www.garywade.com/

> On Dec 16, 2019, at 1:03 AM, Redler Eyal via Cocoa-dev 
>  wrote:
> 
> Thanks!
> I don't use CoreText or NSTextView. I pretty much ruled out RTL vs LTR issues 
> since this is showing up in documents containing either and both. I'm also 
> unable to imagine how some text drawing code could produce such artifacts as 
> splitting a subview in the middle.
> (http://eyalredler.com/stuff/catalina_glitch.png)
> 
> Eyal
> 
> 
> 
> 
>> On 14 Dec 2019, at 21:20, Gary L. Wade  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/archive%40mail-archive.com

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

Re: Catalina scroll view issues

[Gary L. Wade via Cocoa-dev]

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/archive%40mail-archive.com

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

Re: Difficulties with recovering NSAttributedString attachments from saved RTFD

[Gary L. Wade via Cocoa-dev]

While it may seem redundant, what if you specify the document type in the 
document attributes?  Also, you’re storing UTF8 data in the contents but 
specifying plain text; what if you specify it as UTF8 plain text?

Also, the source code for TextEdit is available somewhere; maybe try seeing 
what it’s doing.
--
Gary L. Wade
http://www.garywade.com/ <http://www.garywade.com/>

> On Nov 27, 2019, at 11:35 AM, Gary L. Wade via Cocoa-dev 
>  wrote:
> 
> You want to use a file wrapper rather than data and specify the document type 
> in the attributes as RTFD.
> --
> Gary L. Wade
> http://www.garywade.com/ <http://www.garywade.com/>
> 
>> On Nov 27, 2019, at 10:18 AM, Jeff Younker via Cocoa-dev 
>>  wrote:
>> 
>> I am having some difficulty with saving NSAttributedStrings as RTFD and
>> then recovering
>> them with attachments intact.  I generate a string containing an attachment
>> and turn that into
>> RTFD. When I turn that RTFD back into an NSAttributedString, I get the
>> .string back, and I
>> get an attachment, but the attachment's .contents is empty.
>> 
>> This is the smallest example I can come up with:
>> 
>> func testSaveAndRestoreAttachment() {
>> // Build up the string "deadbeefdeadbeef"
>> let originalContent = "foobar".data(using: .utf8)
>> let originalAttachment = NSTextAttachment(
>>   data: originalContent, ofType: "public.plain-text")
>> let originalString = NSMutableAttributedString(string: "deadbeef")
>> originalString.append(NSMutableAttributedString(attachment:
>> originalAttachment))
>> originalString.append(NSMutableAttributedString(string: "deadbeef")
>> 
>> // save string as RTFD (note that generated RTFD contains "foobar"
>> inside.)
>> let savedRtfd = originalString.rtfd(from:
>> NSRange(0..> 
>> // Recover string
>> let recoveredString = NSAttributedString(rtfd: savedRtfd,
>> documentAttributes: nil)!
>> // Implementation of attachments() can be found below.
>> let recoveredAttachments = attachments(from: recoveredString)
>> // There *is* an attachment!
>> let recoveredAttachment = recoveredAttachments[0]
>> // Want to get Data("foobar") but actually get nil :(
>> XCTAssertNotNil(recoveredAttachment.contents)
>> }
>> 
>> When I print out the RTFD I can see the document includes the attachment
>> "foobar".
>> 
>> I'm assuming that I need to pass some additional information when I
>> call NSAttributedString(rtfd:,
>> documentAttributes:)
>> but I'm at a loss here.
>> 
>> Am I missing something simple? Perhaps a magical setting to be passed in
>> documentAttributes?
>> 
>> -jeff
>> 
>> 
>> 
>> ** This is the attachments() function used above:
>> 
>> func attachments(from s: NSAttributedString) -> Array {
>>   var attachments: Array = []
>>   s.enumerateAttribute(.attachment, in: NSRange(0..>   value, range, stop in
>>   guard let a = value else {
>>  return
>>   }
>>   attachments.append(a as! NSTextAttachment)
>>   }
>>   return attachments
>> }
> 

___

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: Difficulties with recovering NSAttributedString attachments from saved RTFD

[Gary L. Wade via Cocoa-dev]

You want to use a file wrapper rather than data and specify the document type 
in the attributes as RTFD.
--
Gary L. Wade
http://www.garywade.com/ 

> On Nov 27, 2019, at 10:18 AM, Jeff Younker via Cocoa-dev 
>  wrote:
> 
> I am having some difficulty with saving NSAttributedStrings as RTFD and
> then recovering
> them with attachments intact.  I generate a string containing an attachment
> and turn that into
> RTFD. When I turn that RTFD back into an NSAttributedString, I get the
> .string back, and I
> get an attachment, but the attachment's .contents is empty.
> 
> This is the smallest example I can come up with:
> 
> func testSaveAndRestoreAttachment() {
>  // Build up the string "deadbeefdeadbeef"
>  let originalContent = "foobar".data(using: .utf8)
>  let originalAttachment = NSTextAttachment(
>data: originalContent, ofType: "public.plain-text")
>  let originalString = NSMutableAttributedString(string: "deadbeef")
>  originalString.append(NSMutableAttributedString(attachment:
> originalAttachment))
>  originalString.append(NSMutableAttributedString(string: "deadbeef")
> 
>  // save string as RTFD (note that generated RTFD contains "foobar"
> inside.)
>  let savedRtfd = originalString.rtfd(from:
> NSRange(0.. 
>  // Recover string
>  let recoveredString = NSAttributedString(rtfd: savedRtfd,
> documentAttributes: nil)!
>  // Implementation of attachments() can be found below.
>  let recoveredAttachments = attachments(from: recoveredString)
>  // There *is* an attachment!
>  let recoveredAttachment = recoveredAttachments[0]
>  // Want to get Data("foobar") but actually get nil :(
>  XCTAssertNotNil(recoveredAttachment.contents)
> }
> 
> When I print out the RTFD I can see the document includes the attachment
> "foobar".
> 
> I'm assuming that I need to pass some additional information when I
> call NSAttributedString(rtfd:,
> documentAttributes:)
> but I'm at a loss here.
> 
> Am I missing something simple? Perhaps a magical setting to be passed in
> documentAttributes?
> 
> -jeff
> 
> 
> 
> ** This is the attachments() function used above:
> 
> func attachments(from s: NSAttributedString) -> Array {
>var attachments: Array = []
>s.enumerateAttribute(.attachment, in: NSRange(0..value, range, stop in
>guard let a = value else {
>   return
>}
>attachments.append(a as! NSTextAttachment)
>}
>return attachments
> }

___

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

[Gary L. Wade via Cocoa-dev]

INCREDIBLY ridiculous! If I weren’t paid well and have a great, fulfilling job 
working on all of Apple’s platforms, I’d be tempted to make a competitive 
version of some of these develops’ apps to show how the difficulty in doing so 
is blown so out of proportion!

It sounds like some people need to join a weekend hackathon to exercise their 
skills! For a fun one, do a search for Flickr SharkFeed.
--
Gary L. Wade
http://www.garywade.com/

> On Nov 21, 2019, at 6:02 PM, Jim Crate via Cocoa-dev 
>  wrote:
> 
> On Nov 21, 2019, at 5:43 PM, Pascal Bourguignon via Cocoa-dev 
>  wrote:
> 
>> The Apple ecosystem implies an extraordinary maintenance load. 
>> Specifically, your application must provide enough revenue to pay for a 
>> couple of developpers only to track the changes Apple makes to the API, and 
>> update it on each new version of the system (which occur about yearly).
>> So, count about 100,000 €/year to 200,000 €/year.
>> If your application doesn’t provide this profit, then you cannot follow, 
>> and it will quickly be dropped from the the AppStore.
> 
> This is pretty ridiculous.

___

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

[Gary L. Wade via Cocoa-dev]

I find the arguments here interesting. If I were to develop an OpenGL-based 
app, I would probably need at least a week to get something basic working, and 
I’m sure that applies to pretty much anyone. If someone can spend time learning 
an SDK like OpenGL, then I don’t see what’s the problem with studying anything 
else important for one’s work.
--
Gary L. Wade
http://www.garywade.com/

> On Nov 21, 2019, at 12:21 PM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> I won't respond each of you one by one but here are a couple of
> observations.
> 
> Metal is not a cross platform technology hence why so many projects still
> rely on OpenGL in macOS (eg: Firefox).
> 
> I don't understand those "the writing was in the wall" type of comments.
> Even if you think something was obvious all along the indisputable truth is
> we only have guesses and rumors. It's mind blowing that anyone making
> business decisions would be ok with this uncertainty.
> 
> If someone can afford days/weeks to do watch WWDC sessions consistently
> every year it's great. That's not a luxury all of us can afford and it's
> ridiculous to think this should be a requirement.
> 
> Some will argue "just jump on SwiftUI". Well a) SwiftUI is not mature and
> b) best case scenario it will take 2-3 years before it has support for more
> than 60-70% of macOS users. In certain industries (such as audio) the
> majority of users will not update past Mojave for many years because that
> would imply letting go of expensive hardware.
> 
> Anyway, I won't be annoying you anymore with what I believe are valid
> concerns. It's time for me to leave this mailing list.
> 
> I wish you all the best.

___

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

[Gary L. Wade via Cocoa-dev]

> On Nov 20, 2019, at 8:29 AM, Pier Bover via Cocoa-dev 
>  wrote:
> 
> 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.

In that case, scan through the online transcripts, which are searchable, and 
the keynotes of the presentations.

Really, no one has any excuse. Either use what’s available and submit feedback 
when something isn’t clear or quit developing software.
--
Gary L. Wade
http://www.garywade.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

[Gary L. Wade via Cocoa-dev]

There seems to be a misunderstanding that just because the word “Cocoa” doesn’t 
appear, nor "Objective-C” in the latest WWDC videos to a great extent, that 
they are no longer relevant.  If you watch any of the videos to the end, you’ll 
notice that rather than repeating every detail every year, the sessions instead 
reference previous years’ videos.  Since previous WWDC conferences have covered 
a lot more Objective-C and core Cocoa frameworks and they’re all available and 
free, why would anyone spend time repeating things when there’s plenty of new 
things to discuss?  An enterprising user would go back and watch the previous 
years’ sessions if they need that information.

By the way, the WWDC app on iOS, tvOS, and watchOS has been updated to be the 
Apple Developer App.

Introducing the Apple Developer App 

View on the App Store 

--
Gary L. Wade
http://www.garywade.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

[Gary L. Wade via Cocoa-dev]

You seem to be overlooking the fact that many of these current and past years’ 
videos talk about Cocoa by referencing their constituent components like 
AppKit, MapKit, Collection View, etc. You would benefit greatly by sitting down 
and watching as many of these videos as possible.
--
Gary L. Wade
http://www.garywade.com/

> On Nov 14, 2019, at 10:41 AM, Turtle Creek Software  
> wrote:
> 
> 
> >> Here’s your free advice and prognostications:
> 
> https://developer.apple.com/videos/wwdc2019/
> https://developer.apple.com/develop/
> 
> Neither of those mention Cocoa at all, just SwiftUI.  Only slight mention of 
> Objective-C in a couple of video descriptions about Clang/LLVM and profiling. 
>  That does seem like a useful prognostication.  Thanks for the links!
> 
> Casey McDermott
> TurtleSoft.com
> 
> On Thu, Nov 14, 2019 at 11:39 AM Gary L. Wade  
> wrote:
>>> On Nov 14, 2019, at 8:29 AM, Turtle Creek Software via Cocoa-dev 
>>>  wrote:
>>> 
>>> I think this gets back to the transparency issue.  If Apple were more open
>>> about the future, it would be easier to know which cliffs are real.
>>> 
>> 
>> 
>> Here’s your free advice and prognostications:
>> 
>> https://developer.apple.com/videos/wwdc2019/
>> https://developer.apple.com/develop/
>> 
>> If you choose to ignore what is available to you, you have no one to blame 
>> but yourself.
>> 
>> Oh, and by the way, if you use DeRez right, the output is very useful.  In 
>> the terminal, type this command:
>> 
>> man DeRez
>> 
>> We’ve said this before, but now it’s definitely time to move on from this 
>> non-related topic.  If you have Cocoa-related questions, please feel free to 
>> submit those.  Otherwise, find another email list.
>> --
>> Gary L. Wade
>> http://www.garywade.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

[Gary L. Wade via Cocoa-dev]

> On Nov 14, 2019, at 8:29 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> I think this gets back to the transparency issue.  If Apple were more open
> about the future, it would be easier to know which cliffs are real.
> 


Here’s your free advice and prognostications:

https://developer.apple.com/videos/wwdc2019/ 

https://developer.apple.com/develop/ 

If you choose to ignore what is available to you, you have no one to blame but 
yourself.

Oh, and by the way, if you use DeRez right, the output is very useful.  In the 
terminal, type this command:

man DeRez

We’ve said this before, but now it’s definitely time to move on from this 
non-related topic.  If you have Cocoa-related questions, please feel free to 
submit those.  Otherwise, find another email list.
--
Gary L. Wade
http://www.garywade.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 Objective-C++

[Gary L. Wade via Cocoa-dev]

If it takes you that long, then you need to hire new developers rather than 
wasting your time posting complaints on an email list.
--
Gary L. Wade
http://www.garywade.com/

> On Nov 13, 2019, at 11:32 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> We have to plan 5 or 10 years ahead, because it takes that long to create
> an app and sell it for long enough to get payback.

___

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 Objective-C++

[Gary L. Wade via Cocoa-dev]

If you wish to solve the problems you perceive to exist, you should join an 
Objective-C/Objective-C++ email list or hire developers experienced in those 
nuances.
--
Gary

> On Nov 11, 2019, at 10:47 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> 
>> 
>>> Obj-C++ *is* a superset of C++, so I’m not sure what you’re wishing for.
> 
> In source files Obj-C++ works great.  No complaints there. But headers and
> method declarations are Obj-C, which is C plus its own additions.
> 
> That means no use of const. All pointers instead of & references.  Both of
> those are good at turning run-time errors into compile-time.  No multiple
> inheritance, so we had to duplicate code in several places.  No
> initializing members in headers, so mystery bugs if you initialize in the
> wrong type of init.  No public/private to manage access. Etc. It was like
> going back to the early 90s. Doing without features we learned to use the
> hard way.
> 
> Make Objective-C a complete superset of C++ rather than C and it gains all
> the fantastic work that has gone into C++ over the past 20 years. Take
> advantage of folks from many places working on the language, not just half
> or 1/4 of the engineers at Apple.
> 
> 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/archive%40mail-archive.com

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

Re: Thoughts on productivity

[Gary L. Wade via Cocoa-dev]

On Oct 24, 2019, at 6:08 AM, Turtle Creek Software via Cocoa-dev 
 wrote:

> Is there a way to fix this stuff?
…
> For the rest, Apple really needs to listen to developers more.

This is how you move towards a solution.

https://developer.apple.com/account/#/feedback-assistant

https://developer.apple.com/account/#/forums
--
Gary L. Wade
http://www.garywade.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 Cocoa source code

[Gary L. Wade via Cocoa-dev]

The hard thing to make work best with NSComboBox is what to have its data 
source return when a user enters something not available in the list, so there 
is that decision to make, especially if your list is very sparse. You could 
also just use a pop up button that allows both mouse selection and text 
selection of a menu item when opened.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 10:10 AM, Turtle Creek Software  
> wrote:
> 
> NSComboBox was almost perfect, but we needed it to only allow existing items.

___

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 Cocoa source code

[Gary L. Wade via Cocoa-dev]

Clarification: For long-time Mac and now available in SwiftUI, you can even 
write “no” code to do some things with bindings.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 8:31 AM, Gary L. Wade  
> wrote:
> 
> For Mac and SwiftUI, you can even write “no” code to do some things with 
> bindings.

___

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 Cocoa source code

[Gary L. Wade via Cocoa-dev]

I’m one of the few on the list who has experienced every growing pain you’ve 
mentioned from 680x0 Macintosh now up to SwiftUI, and not only supporting a US 
English environment but even RTL UI (Arabic and Hebrew scripts) mixed with LTR 
languages across every current platform, and I will admit it’s hard.

The way I found Cocoa development to be easier was to change my way of 
thinking. In almost every case, it was better to completely separate the 
business logic from the UI handling logic. In other frameworks, the paradigm is 
to subclass a view; in Cocoa, everything is built to be as MVC as possible. Of 
course, there are exceptions, but if you find yourself wanting to subclass a 
view, think hard and look around—it might be better to compose a view of other 
views or there is a better, more Cocoa way of doing it. For Mac and SwiftUI, 
you can even write “no” code to do some things with bindings.

It’s possible to do a progressive port, but in many cases, you might find it 
easier to re-model (pun intended) your design.

True, the classes you mentioned are difficult, but I’ve seen many of their 
difficulties in thinking of them as a 1-1 replacement for comparable 
affordances in other frameworks or platforms.

Definitely use your tech support incidents, and if you find something not 
behaving as defined or not defined well, submit feedback to Apple and feel free 
to post those here. There’s also a site where you can voluntarily add your 
feedback requests to Apple, but I don’t recall it right now.
--
Gary L. Wade
http://www.garywade.com/

> On Oct 11, 2019, at 8:00 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> I checked the GNUstep project, and it does seem decently clear and
> well-commented. If Apple made it possible to see and step through some of
> the basic Cocoa classes, that would be a good starting point.  The hard
> parts for us were NSView and its subclasses (especially NSTableView &
> associates, NSTabView and NSComboBox in that order).  The whole constraint
> system.  ARC.  Getting nibs to work properly when one little setting was
> wrong.
> 
> In general, we weren't curious at all about the inner implementations of
> Cocoa.  The problems that held us back were in getting it to work for our
> app. Something is drawing solid black.  Why?
> 
> Rather than crown jewels, I think the best analogy for Cocoa should be an
> excavator or a backhoe. Some people run one full-time, but some pick it up
> from the rental place, and just want to get some stuff done over a
> weekend.  What's the best way to make it productive, quickly?  The
> long-time operators on this list know all the tricks, but Cocoa should also
> allow the rest of us to build apps relatively quickly. In our case, that
> means less than 3 years.
> 
> Casey McDermott
> TurtleSoft.com
> 
>> On Fri, Oct 11, 2019 at 9:47 AM Saagar Jha  wrote:
>> 
>> I’m sure much of the Cocoa code is quite old, but it’s mostly all
>> Objective-C. If you’re curious how it might work, but don’t want to use a
>> disassembler, the GNUstep project has a somewhat decent (though
>> incomplete) reimplementation  that
>> you can look at.
>> 
>> Saagar Jha
>> 
>> On Oct 11, 2019, at 06:18, Turtle Creek Software via Cocoa-dev <
>> cocoa-dev@lists.apple.com> wrote:
>> 
>> If you combine otool, classdump and Hopper Disassembler, you can find
>> 
>> how some Cocoa methods are working in any Obj-C executable pretty easily.
>> 
>> Here's the thing.  We started out as construction folks who learned Excel.
>> Then HyperTalk.  Then C++. As a business, our main strength is knowing the
>> construction business, and how to talk to folks in it. Our time is best
>> spent solving business-related problems.  Along the way we have learned
>> many programming and human-interface skills, but the less time we need to
>> spend on that, the better.
>> 
>> If a programming environment requires zombies, disassemblers and other BS
>> just to make it work, that is a big problem. It's too much extra overhead.
>> Our company can't afford it.
>> 
>> I'd agree that the documentation for Cocoa is deficient.
>> 
>> CodeWarrior included a huge Inside PowerPlant book, modeled on our
>> well-worn copies of Inside Macintosh. But we rarely used it.  Having
>> clearly-written source code and good comments is probably the best form of
>> documentation. Being able to step through it easily and see it in action is
>> a huge plus.
>> 
>> I suspect that Cocoa source code is ancient C that is badly in need of a
>> refactoring. Making it open, understandable and self-documenting would be a
>> great way to improve it.  Based on our refactoring experiences, it would
>> end up being faster, safer and less buggy.
>> 
>> There probably are some parts of Cocoa that are extremely proprietary- but
>> even then, plain old patents are better than hiding the code, as a way to
>> protect the jewels. Competitors can always disassemble, as you suggest.
>> 
>> Speaking of 

Re: A question in regards to AddInstanceForFactory

[Gary L. Wade via Cocoa-dev]

Are you running on Mojave or Catalina beta? I’ve found some things in some 
simulators work better when under Catalina beta.
--
Gary L. Wade
http://www.garywade.com/

> On Sep 26, 2019, at 5:37 AM, Eric E. Dolecki via Cocoa-dev 
>  wrote:
> 
> FYI: This only appears when running in a simulator.
> 
>> On Thu, Sep 26, 2019 at 8:31 AM Eric E. Dolecki  wrote:
>> 
>> I am using Xcode 11.0 (11420a), targeting iOS 13, Swift 5, and playing
>> back a local audio file. Seems simple enough, but I am getting a console
>> print:
>> 
>>let path = Bundle.main.path(forResource:
>> "Tchaikovsky_Rococo_Var_orch.mp3", ofType:nil)!
>>let url = URL(fileURLWithPath: path)
>>do {
>>player = try AVAudioPlayer(contentsOf: url)
>>player?.volume = 0.5
>>player?.numberOfLoops = -1
>>player?.play()
>>} catch {
>>print("Could not load the audio file.")
>>}
>> 
>> *[plugin] AddInstanceForFactory: No factory registered for id ...*
>> 
>> Everything runs fine, but how do I silence this? I've googled and haven't
>> seen anything.
>> 
>> Thanks,
>> Eric
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.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: CGImageSourceCopyPropertiesAtIndex fails sometimes

[Gary L. Wade via Cocoa-dev]

I don’t recall if the URL can be a remote URL in addition to a file URL, but 
regardless, check the status of the source ref with CGImageSourceStatus first. 
The index value is used for compound images like animated GIFs and PNGs.
--
Gary L. Wade
http://www.garywade.com/

> On Sep 25, 2019, at 8:10 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> 
> I have this piece of code in my program:
> 
>CGImageSourceRef sourceRef = CGImageSourceCreateWithURL( (CFURLRef) url, 
> NULL );
>if ( sourceRef == NULL )
>{
>... display error message 1
>return;
>}
>CFDictionaryRef fileProps = CGImageSourceCopyPropertiesAtIndex( sourceRef, 
> 0, NULL );
>if ( ! fileProps )
>{
>... display error message 2
>return;
>}
> 
> Now, occasionally, I get "error message 2" but not "error message 1",
> i.e.,  CGImageSourceCopyPropertiesAtIndex() apparently fails, while 
> CGImageSourceCreateWithURL() retuned a valid(?) image source ref.
> 
> I am wondering, how this could happen.  Does anyone have a clue?
> 
> Furthermore, when I run the program a few minutes later, without any changes 
> whatsoever, 
> both function calls work just fine, with the same image files!
> 
> 
> Puzzled, Gabriel.
> 
> PS:
> I never understood what the index in CGImageSourceCopyPropertiesAtIndex() is 
> meant for,
> and I could not find a clue in the docs, and every example uses just 0 ‒
> but probably, this is not related to the problem described above.

___

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

[Gary L. Wade via Cocoa-dev]

Sometimes the best approach when something seems magical or extremely 
unexpected is to step away to the marker board and draw pictures and a “movie” 
storyboard of what’s going on, tallying up visually everything. Unilaterally 
using strong or weak references is not the answer. Often when I go through that 
exercise, without cutting corners or assuming stuff, a solution usually 
presents itself.
--
Gary L. Wade
http://www.garywade.com/

> On Aug 24, 2019, at 4:44 AM, Turtle Creek Software via Cocoa-dev 
>  wrote:
> 
> Our app delegate class is not deallocated.  The window controller is
> deallocated
> despite the member reference there.  If we keep the second strong reference
> to the controller,
> then the outline view is deallocated instead.  Nothing references the view
> except being in the .xib file for the window controller.
> 
> We had similar problems with a NSTabViewer.  When we futzed the build
> settings to allow
> breakpoints on retain and release, it was being retained 34 times and
> released 35 times-
> all inside Apple code.  The only way we found to fix that was to stop using
> a NSTabViewController
> and just manage it directly.
> 
>> On Fri, Aug 23, 2019 at 8:27 PM Jens Alfke  wrote:
>> 
>> 
>> 
>> On Aug 23, 2019, at 2:17 PM, Casey McDermott via Cocoa-dev <
>> cocoa-dev@lists.apple.com> wrote:
>> 
>> After we finished, the controller for our main window started being
>> deallocated some random time after launch.
>> Apparently the erroneous strong references were keeping it alive.
>> 
>> 
>> AppKit delegates, like NSWindow.delegate, are unsafe-unretained
>> references; this might be giving you trouble.
>> 
>> We allocate the controller in our app delegate class. It's a member but
>> apparently that is not a
>> strong enough reference, so the controller is released at the end of the
>> scope.
>> 
>> 
>> A member variable is a strong reference by default, so that should suffice
>> to keep it alive. Is your app delegate itself being dealloced?
>> 
>> —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/archive%40mail-archive.com

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

Re: NSLog displays inconsistent format for NSDate

[Gary L. Wade via Cocoa-dev]

If you want to output a date in a predictable format, you should use a date 
formatter.  When I ran a sample app under the simulator for tvOS 13 in Xcode 11 
beta 5, I got these results for the specified locales:

2019-08-20 19:51:05.637667-0700 TestDateDescription[32894:2579867] ar_AE: The 
date is now 2019-08-21 02:51:05 +
2019-08-20 19:51:42.350744-0700 TestDateDescription[32899:2580909] fr_FR: The 
date is now 2019-08-21 02:51:42 +
2019-08-20 19:52:13.121429-0700 TestDateDescription[32905:2581496] en_US: The 
date is now 2019-08-21 02:52:13 +

This was the line of Swift I used:

NSLog("%@: The date is now %@", Locale.current.identifier, NSDate())

For a predictable format in logs, I’d suggest using NSISO8601DateFormatter.
--
Gary L. Wade
http://www.garywade.com/ 

> On Aug 20, 2019, at 12:50 PM, Carl Hoefs via Cocoa-dev 
>  wrote:
> 
> When printing out an NSDate using NSLog from within Xcode I get:
> 
> "Tue Aug 20 12:32:40 2019"
> 
> When the same program is run from within a shell (bash) window:
> 
> "2019-08-20 19:32:48 +"
> 
> Is the NSDate output format somehow determined by the environment? My system 
> is set to Local Time Zone (America/Los_Angeles (PDT) offset -25200 
> (Daylight)).
> 
> A code snippet that reproduces the issue follows. 
> 
> -Carl
> 
> 
> 
> - (void) testDate
> {
>NSCalendar *calendar = [NSCalendar currentCalendar];
>unsigned unitFlags = 
> NSCalendarUnitYear|NSCalendarUnitMonth|NSCalendarUnitDay|NSCalendarUnitHour|NSCalendarUnitMinute|NSCalendarUnitSecond|NSCalendarUnitTimeZone;
>NSDateComponents *dateComponents = [calendar components:unitFlags 
> fromDate:[NSDate date]];
>dateComponents.timeZone = NSTimeZone.localTimeZone;
>NSDate *configuredDate = [calendar dateFromComponents:dateComponents];
>NSLog(@"Configured date: %@",configuredDate);
> }
> 
> Xcode:
> 2019-08-20 12:32:40.828863-0700 tester[3926:1353] Configured date: Tue Aug 20 
> 12:32:40 2019
> 
> Shell:
> 2019-08-20 12:33:08.356 tester[3928:1359] Configured date: 2019-08-20 
> 19:32:48 +
> 

___

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