Re: 12 hr vs 24 hr time display

[Alex Zavatone]

OK.  All that NSLocale stuff seemed like "The right way to do it™" but…

Let's see if this gets you what you want.

Read this file:

~/Library/Preferences/
com.apple.menuextra.clock.plist

And you'll see…


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>

EEE h:mm 



Or


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>

EEE h:mm a


Or


http://www.apple.com/DTDs/PropertyList-1.0.dtd;>

EEE H:mm


The differences here are:

EEE h:mm – 12 hour clock, no AM/PM shown
EEE h:mm a – 12 hour clock, AM/PM shown
EEE H:mm – 24 hour clock

Hope that helps.

- Z
___

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: 12 hr vs 24 hr time display

[Alex Zavatone]

On Jan 3, 2017, at 8:02 PM, Sandor Szatmari wrote:

> Alex,
> 
> On Jan 3, 2017, at 19:51, Alex Zavatone  wrote:
> 
>> 
>> On Jan 3, 2017, at 3:02 PM, Sandor Szatmari wrote:
>> 
>>> Gary,
>>> 
 On Jan 3, 2017, at 14:52, Gary L. Wade  
 wrote:
 
 Is there a problem with using +[NSDateFormatter 
 localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, 
 you might also consider +[NSCalendar autoupdatingCurrentCalendar].
>>> 
>>> I am looking for detecting whether or not the system defaults to 12 or 24 
>>> hr time.  The obj-c method I'm already 'parsing', 
>>> -dateFormatFromTemplate:::, returns a template string with well defined 
>>> formatting tokens that are easy to detect.  Plus they directly reflect the 
>>> user's Locale & Region settings.
>> 
>> I'd expect that would be a function of the language and the locale, possibly 
>> just the locale.  Do you care what it defaults to or what it's currently set 
>> to?
> 
> That's correct and I only care so far as I can determine it as being either 
> 12 or 24.  
> 
> The relevant methods are, -dateFormatFromTemplate::: returns a format string 
> which -localizedStringFromDate:dateStyle:timeStyle: consumes to produces a 
> human readable Date string.  I am not doing the second step described here.  
> Producing he actual string the view is separate from this state stored in my 
> model.
> 
> The relevant bits are: -dateFormatFromTemplate::: with a template of 'j' 
> returns the default format string for the Locale passed as the Locale 
> argument.  I am passing [NSLocale currentLocale].  
> 
> It is my understanding that any Locale which supports the 12 hr time format 
> must represent the AM/PM as 'a' in the format string provided to 
> -localizedStringFromDate:dateStyle:timeStyle:.  So therefore the presence of 
> 'a' indicates that the Locale is configured for 12 hr time.  Otherwise, it's 
> 24 hr time.  What I am relying on is the behavior of 
> -dateFormatFromTemplate::: when passed the 'j' template.  This behavior is 
> documented here 
> http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns.
>   It specifically mentions using 'j' to determine the presence AM/PM or not.  
> i.e. 12 or 24 hr time.
> 
> Might some Locales only support 12 or 24?  Maybe, maybe not.  But if I decide 
> to only rely on the setting from Locale & Region and my interpretations are 
> good this should not matter.  The user will never see 12 or 24 for locales 
> that do not support them.
> The specific section is 
> http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Day_Period_Rules.
> 
> Thanks,
> Sandor
> 
>> 
>> - Z
>> 


Well, I am sure that some default to 12 hour time (US) and others to 24.  I 
know that you're doing this on the Mac, but last time I checked, there were 
about 900 locales supported on iOS.  The point here is that you should be able 
to get the user's current locale and see what they is set for that.

It's possible that (even though this is an issue for the Mac) that you will 
find the approach you want looking for a solution on iOS.  Check their 
currentLocale

This has relevant data and on iOS, it would be [NSLocale currentLocale];
You could look into [NSLocale 
componentsFromLocaleIdentifier:myLocaleIdentifierString] and use [[NSLocale 
currentLocale] localeIdentifier]

Also, check here.

http://stackoverflow.com/questions/35435218/ios-time-in-24-hours-format

Good luck, I think you're almost there.

Cheers.

___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Alex,

> On Jan 3, 2017, at 19:51, Alex Zavatone  wrote:
> 
> 
>> On Jan 3, 2017, at 3:02 PM, Sandor Szatmari wrote:
>> 
>> Gary,
>> 
>>> On Jan 3, 2017, at 14:52, Gary L. Wade  wrote:
>>> 
>>> Is there a problem with using +[NSDateFormatter 
>>> localizedStringFromDate:dateStyle:timeStyle:]? Depending on your needs, you 
>>> might also consider +[NSCalendar autoupdatingCurrentCalendar].
>> 
>> I am looking for detecting whether or not the system defaults to 12 or 24 hr 
>> time.  The obj-c method I'm already 'parsing', -dateFormatFromTemplate:::, 
>> returns a template string with well defined formatting tokens that are easy 
>> to detect.  Plus they directly reflect the user's Locale & Region settings.
> 
> I'd expect that would be a function of the language and the locale, possibly 
> just the locale.  Do you care what it defaults to or what it's currently set 
> to?

That's correct and I only care so far as I can determine it as being either 12 
or 24.  

The relevant methods are, -dateFormatFromTemplate::: returns a format string 
which -localizedStringFromDate:dateStyle:timeStyle: consumes to produces a 
human readable Date string.  I am not doing the second step described here.  
Producing he actual string the view is separate from this state stored in my 
model.

The relevant bits are: -dateFormatFromTemplate::: with a template of 'j' 
returns the default format string for the Locale passed as the Locale argument. 
 I am passing [NSLocale currentLocale].  

It is my understanding that any Locale which supports the 12 hr time format 
must represent the AM/PM as 'a' in the format string provided to 
-localizedStringFromDate:dateStyle:timeStyle:.  So therefore the presence of 
'a' indicates that the Locale is configured for 12 hr time.  Otherwise, it's 24 
hr time.  What I am relying on is the behavior of -dateFormatFromTemplate::: 
when passed the 'j' template.  This behavior is documented here 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns.
  It specifically mentions using 'j' to determine the presence AM/PM or not.  
i.e. 12 or 24 hr time.

Might some Locales only support 12 or 24?  Maybe, maybe not.  But if I decide 
to only rely on the setting from Locale & Region and my interpretations are 
good this should not matter.  The user will never see 12 or 24 for locales that 
do not support them.
The specific section is 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Day_Period_Rules.

Thanks,
Sandor

> 
> - Z
> 
___

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: 12 hr vs 24 hr time display

[Alex Zavatone]

On Jan 3, 2017, at 3:02 PM, Sandor Szatmari wrote:

> Gary,
> 
>> On Jan 3, 2017, at 14:52, Gary L. Wade  wrote:
>> 
>> Is there a problem with using +[NSDateFormatter 
>> localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, you 
>> might also consider +[NSCalendar autoupdatingCurrentCalendar].
> 
> I am looking for detecting whether or not the system defaults to 12 or 24 hr 
> time.  The obj-c method I'm already 'parsing', -dateFormatFromTemplate:::, 
> returns a template string with well defined formatting tokens that are easy 
> to detect.  Plus they directly reflect the user's Locale & Region settings.

I'd expect that would be a function of the language and the locale, possibly 
just the locale.  Do you care what it defaults to or what it's currently set to?

- Z


___

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: 12 hr vs 24 hr time display

[Gary L. Wade]

In that case, see if a call like this would work for you in all supported 
locales:

Objective-C
formattedDate = [NSDateFormatter localizedStringFromDate:date
dateStyle:NSDateFormatterNoStyle
timeStyle:NSDateFormatterShortStyle];

or:

Swift
let formattedDate = DateFormatter.localizedString 
(from:date,dateStyle:.none,timeStyle:.short)

If that doesn’t work, look at the comparable method in 
NSDateComponentsFormatter.
--
Gary L. Wade
http://www.garywade.com/ 
> On Jan 3, 2017, at 4:12 PM, Sandor Szatmari  
> wrote:
> 
> Gary,
> 
> On Jan 3, 2017, at 18:40, Gary L. Wade  > wrote:
> 
>> What I’m getting at is how relevant is it to your app that you know if and 
>> where the time-of-day indicators exist in addition to the 24-hour setting.  
>> Answering those questions should be what determines your next steps.  
>> As mentioned, the alarm clock has a long history on the Mac whereas the 
>> Unicode underpinnings for these locale settings are "relatively recent.”  If 
>> all you care about is putting out a time, try using 
>> localizedStringFromDate:….
> All I ever display is hours and minutes for the purposes of this app.  This 
> is the simple part.  It was deciding whether or not to display 24 or 12 hour 
> time which was at question.
> 
>> If you absolutely have to have full control over the format string, unless 
>> the user wants a change, always use the system settings, and model your 
>> override UI after that provided in the system preferences.
> Yea, I thought about duplicating the system's UI, but I find it hard to 
> decide to emulate something I think could be better.  But, it might be the 
> most consistent experience for the user.
> 
>>  If you’re wanting even greater details, try looking for IBM’s ICU test 
>> pages;
> Great suggestion, thanks!
> 
> Sandor
> 
>> I’m sure they’re still around somewhere, and they allow you to run through 
>> all locales in existence, even some that Apple may not currently support.
>> --
>> Gary L. Wade
>> http://www.garywade.com/ 
>>> On Jan 3, 2017, at 1:02 PM, Sandor Szatmari >> > wrote:
>>> 
>>> Gary,
>>> 
>>> On Jan 3, 2017, at 14:52, Gary L. Wade >> > wrote:
>>> 
 Is there a problem with using +[NSDateFormatter 
 localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, 
 you might also consider +[NSCalendar autoupdatingCurrentCalendar].
>>> 
>>> I am looking for detecting whether or not the system defaults to 12 or 24 
>>> hr time.  The obj-c method I'm already 'parsing', 
>>> -dateFormatFromTemplate:::, returns a template string with well defined 
>>> formatting tokens that are easy to detect.  Plus they directly reflect the 
>>> user's Locale & Region settings.
 
 
 A user typically “sets” their region settings when they set up their Mac, 
 and the choice of 12/24 hour display defaults to what the selected region 
 uses.  Few people change things after that, although I am, preferring a 
 four-digit year vs two-digit for the short date format.
>>> 
>>> Great point!  This is exactly why I wanted to follow a user's Locale & Date 
>>> preference.  The only issue I had was that the preference's place of 
>>> definition appeared vague to me.  It is tenuously tied to the Date & Time 
>>> preference for the menu bar clock.  Your point is good because user's 
>>> decide this once, early on.  Why should they have to specify it for every 
>>> application.  Maybe providing an option to override the default behavior is 
>>> the way to go.  Maybe a three state toggle or matrix.  
>>> 
>>> A. Follow Locale & Region
>>> B. Override with 12 hr
>>> C. Override with 24 hr
>>> 
>>> There is some redundancy in there depending on the Locale & Region setting 
>>> but, at least to me it's self explanatory.  Is that too confusing?
>>> 
>>> Thanks,
>>> Sandor
>>> 
 --
 Gary L. Wade
 http://www.garywade.com/ 
> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari  > wrote:
> 
> Jeremy,
> 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>> > > wrote:
>> 
>> 
>>> On 3 Jan 2017, at 06:16, Sandor Szatmari >> > wrote:
>>> 
>>> I am working on a small application where the primary function is to 
>>> display the time to the user.  My hope was to honor the user's 
>>> preference setting.  I am either missing something or honoring the 
>>> user's preference is harder than expected.
>>> 
>>> So, there are two places to set 24 hr time 

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Gary,

> On Jan 3, 2017, at 18:40, Gary L. Wade  wrote:
> 
> What I’m getting at is how relevant is it to your app that you know if and 
> where the time-of-day indicators exist in addition to the 24-hour setting.  
> Answering those questions should be what determines your next steps.  
> As mentioned, the alarm clock has a long history on the Mac whereas the 
> Unicode underpinnings for these locale settings are "relatively recent.”  If 
> all you care about is putting out a time, try using localizedStringFromDate:….
All I ever display is hours and minutes for the purposes of this app.  This is 
the simple part.  It was deciding whether or not to display 24 or 12 hour time 
which was at question.

> If you absolutely have to have full control over the format string, unless 
> the user wants a change, always use the system settings, and model your 
> override UI after that provided in the system preferences.
Yea, I thought about duplicating the system's UI, but I find it hard to decide 
to emulate something I think could be better.  But, it might be the most 
consistent experience for the user.

>  If you’re wanting even greater details, try looking for IBM’s ICU test pages;
Great suggestion, thanks!

Sandor

> I’m sure they’re still around somewhere, and they allow you to run through 
> all locales in existence, even some that Apple may not currently support.
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Jan 3, 2017, at 1:02 PM, Sandor Szatmari  
>> wrote:
>> 
>> Gary,
>> 
>> On Jan 3, 2017, at 14:52, Gary L. Wade  wrote:
>> 
>>> Is there a problem with using +[NSDateFormatter 
>>> localizedStringFromDate:dateStyle:timeStyle:]? Depending on your needs, you 
>>> might also consider +[NSCalendar autoupdatingCurrentCalendar].
>> 
>> I am looking for detecting whether or not the system defaults to 12 or 24 hr 
>> time.  The obj-c method I'm already 'parsing', -dateFormatFromTemplate:::, 
>> returns a template string with well defined formatting tokens that are easy 
>> to detect.  Plus they directly reflect the user's Locale & Region settings.
>>> 
>>> 
>>> A user typically “sets” their region settings when they set up their Mac, 
>>> and the choice of 12/24 hour display defaults to what the selected region 
>>> uses.  Few people change things after that, although I am, preferring a 
>>> four-digit year vs two-digit for the short date format.
>> 
>> Great point!  This is exactly why I wanted to follow a user's Locale & Date 
>> preference.  The only issue I had was that the preference's place of 
>> definition appeared vague to me.  It is tenuously tied to the Date & Time 
>> preference for the menu bar clock.  Your point is good because user's decide 
>> this once, early on.  Why should they have to specify it for every 
>> application.  Maybe providing an option to override the default behavior is 
>> the way to go.  Maybe a three state toggle or matrix.  
>> 
>> A. Follow Locale & Region
>> B. Override with 12 hr
>> C. Override with 24 hr
>> 
>> There is some redundancy in there depending on the Locale & Region setting 
>> but, at least to me it's self explanatory.  Is that too confusing?
>> 
>> Thanks,
>> Sandor
>> 
>>> --
>>> Gary L. Wade
>>> http://www.garywade.com/
>>> 
 On Jan 3, 2017, at 8:34 AM, Sandor Szatmari  
 wrote:
 
 Jeremy,
 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>>  wrote:
>> 
>> 
>> On 3 Jan 2017, at 06:16, Sandor Szatmari  
>> wrote:
>> 
>> I am working on a small application where the primary function is to 
>> display the time to the user.  My hope was to honor the user's 
>> preference setting.  I am either missing something or honoring the 
>> user's preference is harder than expected.
>> 
>> So, there are two places to set 24 hr time display.
>> 
>> 1. Date & Time preference panel
>> 2. Language & Region preference panel 
>> 
>> The cocoa frameworks react differently depending on where you set this.
>> 
>> If set by method 1, cocoa frameworks seem unaware of this setting and it 
>> appears this is cosmetic in that it only affects the display of the 
>> clock in the NSStatusBar.
>> 
>> If set by method 2, cocoa frameworks reflect this and the Date & Time 
>> setting is disabled noting that the setting has been overridden.
>> 
>> So if a user uses method 1, potentially unaware of method 2, how should 
>> one go about determining the user's intentions.
> 
> It seems obvious to me that method 1 only refers to the clock display in 
> the menu bar and nothing else. It’s a sub setting of 
> “Show date and time in the menu bar”.
> 
> If you honour whatever preference is set by method 2 as your code 
> fragment below does, you’ll be 

Re: 12 hr vs 24 hr time display

[Gary L. Wade]

What I’m getting at is how relevant is it to your app that you know if and 
where the time-of-day indicators exist in addition to the 24-hour setting.  
Answering those questions should be what determines your next steps.  As 
mentioned, the alarm clock has a long history on the Mac whereas the Unicode 
underpinnings for these locale settings are "relatively recent.”  If all you 
care about is putting out a time, try using localizedStringFromDate:…. If you 
absolutely have to have full control over the format string, unless the user 
wants a change, always use the system settings, and model your override UI 
after that provided in the system preferences.  If you’re wanting even greater 
details, try looking for IBM’s ICU test pages; I’m sure they’re still around 
somewhere, and they allow you to run through all locales in existence, even 
some that Apple may not currently support.
--
Gary L. Wade
http://www.garywade.com/ 
> On Jan 3, 2017, at 1:02 PM, Sandor Szatmari  
> wrote:
> 
> Gary,
> 
> On Jan 3, 2017, at 14:52, Gary L. Wade  > wrote:
> 
>> Is there a problem with using +[NSDateFormatter 
>> localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, you 
>> might also consider +[NSCalendar autoupdatingCurrentCalendar].
> 
> I am looking for detecting whether or not the system defaults to 12 or 24 hr 
> time.  The obj-c method I'm already 'parsing', -dateFormatFromTemplate:::, 
> returns a template string with well defined formatting tokens that are easy 
> to detect.  Plus they directly reflect the user's Locale & Region settings.
>> 
>> 
>> A user typically “sets” their region settings when they set up their Mac, 
>> and the choice of 12/24 hour display defaults to what the selected region 
>> uses.  Few people change things after that, although I am, preferring a 
>> four-digit year vs two-digit for the short date format.
> 
> Great point!  This is exactly why I wanted to follow a user's Locale & Date 
> preference.  The only issue I had was that the preference's place of 
> definition appeared vague to me.  It is tenuously tied to the Date & Time 
> preference for the menu bar clock.  Your point is good because user's decide 
> this once, early on.  Why should they have to specify it for every 
> application.  Maybe providing an option to override the default behavior is 
> the way to go.  Maybe a three state toggle or matrix.  
> 
> A. Follow Locale & Region
> B. Override with 12 hr
> C. Override with 24 hr
> 
> There is some redundancy in there depending on the Locale & Region setting 
> but, at least to me it's self explanatory.  Is that too confusing?
> 
> Thanks,
> Sandor
> 
>> --
>> Gary L. Wade
>> http://www.garywade.com/ 
>>> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari >> > wrote:
>>> 
>>> Jeremy,
>>> 
 On Jan 3, 2017, at 10:30, Jeremy Pereira 
 > wrote:
 
 
> On 3 Jan 2017, at 06:16, Sandor Szatmari  > wrote:
> 
> I am working on a small application where the primary function is to 
> display the time to the user.  My hope was to honor the user's preference 
> setting.  I am either missing something or honoring the user's preference 
> is harder than expected.
> 
> So, there are two places to set 24 hr time display.
> 
> 1. Date & Time preference panel
> 2. Language & Region preference panel 
> 
> The cocoa frameworks react differently depending on where you set this.
> 
> If set by method 1, cocoa frameworks seem unaware of this setting and it 
> appears this is cosmetic in that it only affects the display of the clock 
> in the NSStatusBar.
> 
> If set by method 2, cocoa frameworks reflect this and the Date & Time 
> setting is disabled noting that the setting has been overridden.
> 
> So if a user uses method 1, potentially unaware of method 2, how should 
> one go about determining the user's intentions.
 
 It seems obvious to me that method 1 only refers to the clock display in 
 the menu bar and nothing else. It’s a sub setting of 
 “Show date and time in the menu bar”.
 
 If you honour whatever preference is set by method 2 as your code fragment 
 below does, you’ll be fine.
 
>>> I feel like fewer people use/find method 2, simply stopping at method 1.  
>>> This may be a gross assumption on my part.  Under my assumption they would 
>>> simply think my app doesn't display 24 hr time or respect the system 
>>> setting.  Am I being to sensitive here?
>>> 
>>> Sandor
 
> 
> There are deprecated methods using: (didn't try, it's deprecated)
>  

Re: Animating autolayout constraint changes for subviews

[Doug Hill]

Just out of curiosity, is it feasible to override the animation of an 
animatable property to implement this? For example, generating the layer 
contents with the reflowed text for a keyframe animation as the frame size 
changes. Presumably I could do this be overriding the behavior for animating 
the frame property.
Trying to get an idea if this a good technique to try.

Doug Hill


> On Dec 30, 2016, at 11:56 AM, David Duncan  wrote:
> 
>> 
>> On Dec 30, 2016, at 11:50 AM, Doug Hill  wrote:
>> 
>> 
>>> On Dec 30, 2016, at 11:38 AM, David Duncan  wrote:
>>> 
>>> 
 On Dec 28, 2016, at 4:14 PM, Doug Hill  wrote:
 
 Hi Ken,
 
 The exact behavior is that the label will resize to the new size 
 immediately and reflow the text, then the container view will animate it's 
 size change. It would be nice if both the label and the container view 
 animate at the same time.
 Also, as I mentioned, a button will exhibit the same behavior, probably 
 because it has a UILabel inside it to show the button text.
>>> 
>>> Labels (and other content provided via -drawRect:) will almost universally 
>>> behave this way without additional work on your part, as the content is 
>>> redrawn instantly at the final size. At best you might get an animation 
>>> where the content resizes into place, but more often than not, it will pop 
>>> in some undesirable way. Generally the only way to get good animations with 
>>> drawn content is to snapshot in some way and execute an custom animation 
>>> from the old to the new content (snapshotting isn’t necessarily literal 
>>> here – it can just mean creating a new label with the new content as one 
>>> example).
>> 
>> David,
>> 
>> Thanks for the info. I’m curious what system views with content are 
>> animatable. I guess UIImageView works for the snapshots. But anything with a 
>> label is out. I’ll do some tests and see what works.
> 
> They are all “animatable”, but the results are not necessarily well defined. 
> Most system controls use combinations of image views and labels for images 
> and text content, so the resizing animations are often going to be based on 
> how -drawRect: content resizes.
> 
>> 
>> Doug Hill
> 
> --
> David Duncan

___

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: AVFoundation and the main thread

[Mailing Lists]

From my experience in shipping multiple complex AVFoundation apps, you can 
safely (assuming you know what you are actually doing) •  :

Build AVAssets / 
Build AVMutableCompositions 
Build AVVideoCompositors /
Build  AVVideoCompositionLayerInstructions   
Build AVPlayerItems
Build AVPlayerItemOutputs / 
Build AVAssetReader inputs / outputs 
Build AVAssetTrackReaders and whats it--dos-its

On background queues / threads / operations.


You can definitely not
Mess with AVPlayer off of main thread•
Mess with AV Layer off of main thread
Associate AVPlayers with player items off of main thread (breaks rule 1)
Associate AVPlayerLayer with AVPlayers off of main thread (breaks rule 1 and 2)
Handle notifications by any AVPlayer off of main thread / respond (you can of 
course have your own logic do whatever you want but messages to/from AVPlayer, 
Player Item (once created and associated with a player) etc, should be handled 
on main thread).
Handle KVO from any observed objects on any thread.

Honestly, its rarely worth it unless you are super familiar with the API and 
the underlying core-media nuances, memory pooling / re-use strategies, OpenGL / 
CALayer nuances /  etc and have a real need for making your life more 
complicated.

Basically, most non-realtime / playback objects (transcoding, export, sample 
reading / writing) are safe for use on a single background thread, but not for 
concurrent access from multiple threads.

AVPlayer / AVPlayerLayer AVSampleLayer etc really wants the main thread, and 
only that thread.

•  values for "know","what","you", and "doing",  may vary. As your doctor if 
multithreading is right for you

> On Dec 20, 2016, at 12:09 PM, Jens Alfke  wrote:
> 
> I’ll also argue that if you’re needing to do this kind of thing from a 
> background thread, your code isn’t factored properly.
> 
> Managing the UI of the app is far too complex a task to try to coordinate 
> among multiple threads. The current best practices for concurrent programming 
> suggest that you should try to minimize the amount of (mutable) state shared 
> between threads, and instead have the threads interact mostly by messaging.
> 
> So in this specific case, if a background thread does something that requires 
> a player view to be resized, it should send a message (or post a block) to 
> the main thread and let the main thread do it. (And hopefully the background 
> thread isn’t concerning itself with pixels, but instead with something like 
> the length of a track or the number of tracks, which the main thread’s UI 
> logic can then translate into pixel dimensions.)
> 
> —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/lists%40vade.info
> 
> This email sent to li...@vade.info

___

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 13, Issue 518

[Jonathan Prescott]

I think that your expectation that presentViewController would retain a strong 
reference to the view controller is not right.  I would put the release after 
the dismissal code has run.  Now, you really don’t need the view controller.

Jonathan

> On Dec 17, 2016, at 3:00 PM, cocoa-dev-requ...@lists.apple.com wrote:
> 
> Send Cocoa-dev mailing list submissions to
>   cocoa-dev@lists.apple.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
>   cocoa-dev-requ...@lists.apple.com
> 
> You can reach the person managing the list at
>   cocoa-dev-ow...@lists.apple.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Releasing modal view controller properly (Andreas Falkenhahn)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 17 Dec 2016 17:07:10 +0100
> From: Andreas Falkenhahn 
> To: cocoa-dev@lists.apple.com
> Subject: Releasing modal view controller properly
> Message-ID: <1688568431.20161217170...@falkenhahn.com>
> Content-Type: text/plain; charset=us-ascii
> 
> I'm not using ARC so I need to take care of releasing objects manually.
> I'm creating and presenting a modal UIViewController like this:
> 
>MyViewController *vc = [[MyViewController alloc] init];
> 
>vc.modalPresentationStyle = UIModalPresentationFormSheet;
>vc.preferredContentSize = CGRectMake(320, 320);
> 
>[self presentViewController:vc animated:YES completion:nil]
>[vc release];
> 
> When touching the modal view's close button my code does the following:
> 
>[[self presentingViewController] dismissViewControllerAnimated:YES 
> completion:nil];
> 
> Unfortunately, the app crashes right after the modal view has completed
> its transition animation.
> 
> When I disable the line "[vc release]", I don't get any crashes and it
> works fine. Can anybody explain why? I was expecting that 
> presentViewController()
> retained the view controller so that it is safe for me to release it
> right after making the call to presentViewController() because I don't
> need it any longer but apparently, there's something wrong in my code
> but I don't see it...
> 
> -- 
> Best regards,
> Andreas Falkenhahn  mailto:andr...@falkenhahn.com
> 
> 
> 
> --
> 
> ___
> 
> Cocoa-dev mailing list  (Cocoa-dev@lists.apple.com)
> 
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
> 
> https://lists.apple.com/mailman/listinfo/cocoa-dev
> 
> 
> End of Cocoa-dev Digest, Vol 13, Issue 518
> **



smime.p7s
Description: S/MIME cryptographic signature
___

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: UINavigationBar content margins in UIPresentationController subclass

[David Duncan]

The most relevant looking bug I can find seems to involve pushing & popping 
view controllers. That said, setting the preferredContentSize on the navigation 
controller directly should always work.

Alternatively you could use your own container view controller instead.

> On Dec 7, 2016, at 10:42 AM, Daniel Stenmark  wrote:
> 
> Thanks, David.  Unfortunately, UINavigationController isn’t currently an 
> option as it doesn’t reliably bubble up preferredContentSize changes, which 
> we have a strong dependency on and is fairly dynamic in our use case.  As of 
> 10.0, it only seems to adapt and forward the very first preferredContentSize 
> mutation, silencing the rest.  I’ve been told this is currently filed as a 
> Radar (though, if you can confirm that’s NOT the case, I’d be more than happy 
> to file a new one!).
> 
> Is there another way I can work around this limitation in the meantime?
> 
> Dan
> 
>> On Dec 7, 2016, at 10:35 AM, David Duncan > > wrote:
>> 
>> 
>>> On Dec 7, 2016, at 10:28 AM, Daniel Stenmark >> > wrote:
>>> 
>>> The UINavigationBar is in the UIPresentationController’s containerView, 
>>> which is a subview of the current UIWindow and does NOT have a view 
>>> controller in its hierarchy.  Is there a particular reason for 
>>> UINavigationBar to have this dependency for correct layout?  Is there a 
>>> ‘right’ way to work around this aside from manual/artificial padding?
>> 
>> Only view controllers know the proper calculation for the padding to be used 
>> by the bars. Typically a solution to your issue would be to wrap the 
>> presenting view controller in a UINavigationController rather than making 
>> the navigation bar part of the presentation itself.
>> 
>>> 
>>> Dan
>>> 
 On Dec 7, 2016, at 10:01 AM, David Duncan > wrote:
 
 Its unclear to me at least, but where in the view hierarchy is the 
 UINavigationBar? If it isn’t in a view that is ultimately backed by a view 
 controller, then it won’t have the correct information to do its layout.
 
> On Nov 7, 2016, at 12:42 PM, Daniel Stenmark  > wrote:
> 
> I have a UIPresentationController subclass with a UINavigationBar 
> embedded in the container view.  However, when setting the 
> rightBarButtonItem, the spacing I usually expect from the item to the 
> screen isn't there.
> 
> http://imgur.com/LHcqhyd 
> 
> 
> Anyone have an idea where I might be going wrong here?  The relevant code 
> for the presentation controller is as follows:
> 
> @objc public protocol SheetPresentationControllerDelegate : class {
>   func sheetPresentationControllerWillDismiss(_ 
> sheetPresentationController: SheetPresentationController)
> }
> 
> open class SheetPresentationController: UIPresentationController {
> 
> 
> 
>   fileprivate let dimmedView: UIView = {
>   let result = UIView()
>   result.backgroundColor = .black
>   result.alpha = 0
>   result.autoresizingMask = [.flexibleWidth, .flexibleHeight]
>   return result
>   }()
> 
> 
> 
>   fileprivate let topView: UIView = {
>   let result = UIView()
>   result.backgroundColor = .white
>   return result
>   }()
> 
> 
> 
>   fileprivate let navigationBar: UINavigationBar = {
>   let result = UINavigationBar()
>   result.backgroundColor = .white
>   result.items = [UINavigationItem()]
>   return result
>   }()
> 
> 
> 
>   open var title: String? {
>   get {
>   return self.navigationBar.topItem?.title
>   }
>   set {
>   self.navigationBar.topItem?.title = newValue
>   }
>   }
> 
> 
> 
>   open var titleView: UIView? {
>   get {
>   return self.navigationBar.topItem?.titleView
>   }
>   set {
>   self.navigationBar.topItem?.titleView = newValue
>   }
>   }
> 
> 
> 
>   open weak var sheetDelegate: SheetPresentationControllerDelegate?
> 
> 
> 
>   fileprivate dynamic func dismiss(_ sender: NSObject) {
>   self.presentingViewController.dismiss(animated: true, completion: 
> nil)
>   }
> 
> 
> 
>   override open func presentationTransitionWillBegin() {
>   super.presentationTransitionWillBegin()
> 
> 
> 
>   guard let containerView = self.containerView else {
>   return
>   }
> 
> 
> 
>   containerView.addSubview(self.dimmedView)

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Sean,

> On Jan 3, 2017, at 15:32, Sean McBride  wrote:
> 
> On Tue, 3 Jan 2017 11:26:48 -0500, Sandor Szatmari said:
> 
>> What I was asking for clarity on is the fact that there is no way to
>> detect that the user prefers 24 hr time display if they only choose
>> method 1, the Date & Time checkbox.  Should I allow my users to set 12
>> hr time but override it to 24 hr time if the Language & Region checkbox
>> is checked?  This doesn't feel right.  I feel like Apple left room for
>> ambiguity in their design here.
> 
> If I were you I would just forget about the setting for the menu bar clock.  
> I agree it's weird that it even exists (file a bug) but it's clearly meant 
> only for the menu bar clock.  Just use NSDateFormatter and add some UI in 
> your app showing the user the proper place to set her preferred date/time 
> format options.

I'm coming around to something like this.  Thanks!  

Sandor
> 
> Cheers,
> 
> -- 
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com 
> Mac Software Developer  Montréal, Québec, Canada
> 
> 

___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Gary,

> On Jan 3, 2017, at 14:52, Gary L. Wade  wrote:
> 
> Is there a problem with using +[NSDateFormatter 
> localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, you 
> might also consider +[NSCalendar autoupdatingCurrentCalendar].

I am looking for detecting whether or not the system defaults to 12 or 24 hr 
time.  The obj-c method I'm already 'parsing', -dateFormatFromTemplate:::, 
returns a template string with well defined formatting tokens that are easy to 
detect.  Plus they directly reflect the user's Locale & Region settings.
> 
> 
> A user typically “sets” their region settings when they set up their Mac, and 
> the choice of 12/24 hour display defaults to what the selected region uses.  
> Few people change things after that, although I am, preferring a four-digit 
> year vs two-digit for the short date format.

Great point!  This is exactly why I wanted to follow a user's Locale & Date 
preference.  The only issue I had was that the preference's place of definition 
appeared vague to me.  It is tenuously tied to the Date & Time preference for 
the menu bar clock.  Your point is good because user's decide this once, early 
on.  Why should they have to specify it for every application.  Maybe providing 
an option to override the default behavior is the way to go.  Maybe a three 
state toggle or matrix.  

A. Follow Locale & Region
B. Override with 12 hr
C. Override with 24 hr

There is some redundancy in there depending on the Locale & Region setting but, 
at least to me it's self explanatory.  Is that too confusing?

Thanks,
Sandor

> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari  
>> wrote:
>> 
>> Jeremy,
>> 
 On Jan 3, 2017, at 10:30, Jeremy Pereira 
  wrote:
 
 
 On 3 Jan 2017, at 06:16, Sandor Szatmari  
 wrote:
 
 I am working on a small application where the primary function is to 
 display the time to the user.  My hope was to honor the user's preference 
 setting.  I am either missing something or honoring the user's preference 
 is harder than expected.
 
 So, there are two places to set 24 hr time display.
 
 1. Date & Time preference panel
 2. Language & Region preference panel 
 
 The cocoa frameworks react differently depending on where you set this.
 
 If set by method 1, cocoa frameworks seem unaware of this setting and it 
 appears this is cosmetic in that it only affects the display of the clock 
 in the NSStatusBar.
 
 If set by method 2, cocoa frameworks reflect this and the Date & Time 
 setting is disabled noting that the setting has been overridden.
 
 So if a user uses method 1, potentially unaware of method 2, how should 
 one go about determining the user's intentions.
>>> 
>>> It seems obvious to me that method 1 only refers to the clock display in 
>>> the menu bar and nothing else. It’s a sub setting of 
>>> “Show date and time in the menu bar”.
>>> 
>>> If you honour whatever preference is set by method 2 as your code fragment 
>>> below does, you’ll be fine.
>>> 
>> I feel like fewer people use/find method 2, simply stopping at method 1.  
>> This may be a gross assumption on my part.  Under my assumption they would 
>> simply think my app doesn't display 24 hr time or respect the system 
>> setting.  Am I being to sensitive here?
>> 
>> Sandor
>>> 
 
 There are deprecated methods using: (didn't try, it's deprecated)
  NSUserDefaults with the key NSShortTimeDateFormatString
 
 There are supported methods using: (works with method 2)
  NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
 locale:[NSLocale currentLocale]];
  BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
 
 Can anyone provide any clarity here?
 
 Sandor
 ___
 
 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/adc%40jeremyp.net
 
 This email sent to a...@jeremyp.net
>>> 
>>> --
>>> Jeremy Pereira
>>> jeremy.pere...@aptosolutions.co.uk
>>> 07884 265457
> 
___

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: 12 hr vs 24 hr time display

[Sean McBride]

On Tue, 3 Jan 2017 11:26:48 -0500, Sandor Szatmari said:

>What I was asking for clarity on is the fact that there is no way to
>detect that the user prefers 24 hr time display if they only choose
>method 1, the Date & Time checkbox.  Should I allow my users to set 12
>hr time but override it to 24 hr time if the Language & Region checkbox
>is checked?  This doesn't feel right.  I feel like Apple left room for
>ambiguity in their design here.

If I were you I would just forget about the setting for the menu bar clock.  I 
agree it's weird that it even exists (file a bug) but it's clearly meant only 
for the menu bar clock.  Just use NSDateFormatter and add some UI in your app 
showing the user the proper place to set her preferred date/time format options.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada



___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Quincey,

> On Jan 3, 2017, at 14:46, Quincey Morris 
>  wrote:
> 
>> On Jan 3, 2017, at 05:00 , Sandor Szatmari  
>> wrote:
>> 
>> Are you suggesting case sensitivity is an issue here?  If so, I don't think 
>> so.  The template returned from this method uses 'a' as a place holder for 
>> AM/PM.  e.g. It might return the string 'h a' as it does by default for the 
>> English/US locale on my system, and a is always lower case.  This is 
>> described here 
>> http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
>>  See the 'period' field in the Date Field Symbol Table and section 8.2 for 
>> my justification.
> 
> I was, but (sorry) that was because I didn’t read your code carefully enough.
> 
>> Yea, I was considering just making it an app local preference but that 
>> strikes me as crude.  Ideally speaking, at best an appropriate preference 
>> for my app could be 'Override System 24 hr time preference' or something 
>> akin.
> 
> Why can’t be the app preference simply be “Show 24 hr time” and default to 
> the locale setting? Which is to say, the same thing you said but without the 
> semi-pejorative description.
This discussion has proven very helpful.  Putting it that way makes me feel 
like I can satisfy my feeling of ambiguity by adjusting the wording in my 
preference panel.  I feel the wording of something like 'Show 24 hr time 
according to Locale & Region Setting' works.  Too wordy, I know, but making the 
UI self explanatory/teaching is important to me.
> 
> TBH, I think the menu bar clock has an overriding setting only for historical 
> reasons. However, it doesn’t seem completely unlikely that a user might want 
> the always-visible clock to be different from formatted times. It may be that 
> the locale (or bureaucratic policy) might mandate that one format is used for 
> dates/times generally, but a specific user might be more comfortable telling 
> *time of day* using the opposite convention.
Yea, I vacillated here for a while.  It was the unidirectionally connectedness 
of these features that to me implied these features were coupled and yet they 
weren't at the same time.  Apple allows this distinction when the Locale & 
Region 24 hr checkbox is unchecked (Locale says 12hr/clock can be 12 or 24hr), 
but disables the Date & Time checkbox when the Locale & Region checkbox IS 
checked (Locale and clock are both 24 hr).
> 
> Similarly and analogously, a user might have reasons for setting the Mac to 
> GMT generally, but still want to display local time in the menu bar.
> 
I agree with your examples but Apple has carved out a space where they disallow 
a distinction.  I can see why they would be forced to be in sync.  I can see 
why they would be allowed to be independent.  I cannot reason why it is 
implemented as it is.
> 

Thanks,
Sandor
___

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: 12 hr vs 24 hr time display

[Gary L. Wade]

Is there a problem with using +[NSDateFormatter 
localizedStringFromDate:dateStyle:timeStyle:]?  Depending on your needs, you 
might also consider +[NSCalendar autoupdatingCurrentCalendar].

A user typically “sets” their region settings when they set up their Mac, and 
the choice of 12/24 hour display defaults to what the selected region uses.  
Few people change things after that, although I am, preferring a four-digit 
year vs two-digit for the short date format.
--
Gary L. Wade
http://www.garywade.com/ 
> On Jan 3, 2017, at 8:34 AM, Sandor Szatmari  
> wrote:
> 
> Jeremy,
> 
>> On Jan 3, 2017, at 10:30, Jeremy Pereira 
>>  wrote:
>> 
>> 
>>> On 3 Jan 2017, at 06:16, Sandor Szatmari  
>>> wrote:
>>> 
>>> I am working on a small application where the primary function is to 
>>> display the time to the user.  My hope was to honor the user's preference 
>>> setting.  I am either missing something or honoring the user's preference 
>>> is harder than expected.
>>> 
>>> So, there are two places to set 24 hr time display.
>>> 
>>> 1. Date & Time preference panel
>>> 2. Language & Region preference panel 
>>> 
>>> The cocoa frameworks react differently depending on where you set this.
>>> 
>>> If set by method 1, cocoa frameworks seem unaware of this setting and it 
>>> appears this is cosmetic in that it only affects the display of the clock 
>>> in the NSStatusBar.
>>> 
>>> If set by method 2, cocoa frameworks reflect this and the Date & Time 
>>> setting is disabled noting that the setting has been overridden.
>>> 
>>> So if a user uses method 1, potentially unaware of method 2, how should one 
>>> go about determining the user's intentions.
>> 
>> It seems obvious to me that method 1 only refers to the clock display in the 
>> menu bar and nothing else. It’s a sub setting of 
>> “Show date and time in the menu bar”.
>> 
>> If you honour whatever preference is set by method 2 as your code fragment 
>> below does, you’ll be fine.
>> 
> I feel like fewer people use/find method 2, simply stopping at method 1.  
> This may be a gross assumption on my part.  Under my assumption they would 
> simply think my app doesn't display 24 hr time or respect the system setting. 
>  Am I being to sensitive here?
> 
> Sandor
>> 
>>> 
>>> There are deprecated methods using: (didn't try, it's deprecated)
>>>  NSUserDefaults with the key NSShortTimeDateFormatString
>>> 
>>> There are supported methods using: (works with method 2)
>>>  NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
>>> locale:[NSLocale currentLocale]];
>>>  BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
>>> 
>>> Can anyone provide any clarity here?
>>> 
>>> Sandor
>>> ___
>>> 
>>> 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/adc%40jeremyp.net
>>> 
>>> This email sent to a...@jeremyp.net
>> 
>> --
>> Jeremy Pereira
>> jeremy.pere...@aptosolutions.co.uk
>> 07884 265457

___

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: 12 hr vs 24 hr time display

[Quincey Morris]

On Jan 3, 2017, at 05:00 , Sandor Szatmari  wrote:
> 
> Are you suggesting case sensitivity is an issue here?  If so, I don't think 
> so.  The template returned from this method uses 'a' as a place holder for 
> AM/PM.  e.g. It might return the string 'h a' as it does by default for the 
> English/US locale on my system, and a is always lower case.  This is 
> described here 
> http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
>  
> 
>  See the 'period' field in the Date Field Symbol Table and section 8.2 for my 
> justification.

I was, but (sorry) that was because I didn’t read your code carefully enough.

> Yea, I was considering just making it an app local preference but that 
> strikes me as crude.  Ideally speaking, at best an appropriate preference for 
> my app could be 'Override System 24 hr time preference' or something akin.

Why can’t be the app preference simply be “Show 24 hr time” and default to the 
locale setting? Which is to say, the same thing you said but without the 
semi-pejorative description.

TBH, I think the menu bar clock has an overriding setting only for historical 
reasons. However, it doesn’t seem completely unlikely that a user might want 
the always-visible clock to be different from formatted times. It may be that 
the locale (or bureaucratic policy) might mandate that one format is used for 
dates/times generally, but a specific user might be more comfortable telling 
*time of day* using the opposite convention.

Similarly and analogously, a user might have reasons for setting the Mac to GMT 
generally, but still want to display local time in the menu bar.


___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Alex,

> On Jan 3, 2017, at 13:47, Alex Zavatone  wrote:
> 
> iOS or Mac?
> 
> In any case, this will help you out to no end.
> 
> http://NSDateformatter.com/

Thanks, I'll check this out.
> 
> And note that the case of the letters you use in your formatter matter.

I don't think I said case doesn't matter.  It certainly does... e.g. A vs. a, H 
vs. h, Y vs. y, ...  have significance.  As far as I'm aware, and according to 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
 there is only one specifier for AM/PM, and that is lowercase 'a', and it is 
germane only to 12 hr time format strings.  'A' specifies milliseconds in day.  
The only discussion of case was when I explained why I didn't need to, or 
rather shouldn't, consider uppercase 'AM'.  Those tokens have independent 
significance in a format string.  To clarify for future readers of this thread, 
I was not implying case doesn't matter.  Indeed, I was saying case does matter 
and looking for lowercase 'a' was appropriate.  Thanks for pointing that out.

Sandor

> 
> GL.
> - Alex Zavatone
> 
> 
>> On Jan 3, 2017, at 12:16 AM, Sandor Szatmari wrote:
>> 
>> I am working on a small application where the primary function is to display 
>> the time to the user.  My hope was to honor the user's preference setting.  
>> I am either missing something or honoring the user's preference is harder 
>> than expected.
>> 
>> So, there are two places to set 24 hr time display.
>> 
>> 1. Date & Time preference panel
>> 2. Language & Region preference panel 
>> 
>> The cocoa frameworks react differently depending on where you set this.
>> 
>> If set by method 1, cocoa frameworks seem unaware of this setting and it 
>> appears this is cosmetic in that it only affects the display of the clock in 
>> the NSStatusBar.
>> 
>> If set by method 2, cocoa frameworks reflect this and the Date & Time 
>> setting is disabled noting that the setting has been overridden.
>> 
>> So if a user uses method 1, potentially unaware of method 2, how should one 
>> go about determining the user's intentions.
>> 
>> There are deprecated methods using: (didn't try, it's deprecated)
>>   NSUserDefaults with the key NSShortTimeDateFormatString
>> 
>> There are supported methods using: (works with method 2)
>>   NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
>> locale:[NSLocale currentLocale]];
>>   BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
>> 
>> Can anyone provide any clarity here?
>> 
>> Sandor
>> ___
>> 
>> 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/archive%40mail-archive.com

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

Re: 12 hr vs 24 hr time display

[Alex Zavatone]

iOS or Mac?

In any case, this will help you out to no end.

http://NSDateformatter.com/

And note that the case of the letters you use in your formatter matter.

GL.
- Alex Zavatone


On Jan 3, 2017, at 12:16 AM, Sandor Szatmari wrote:

> I am working on a small application where the primary function is to display 
> the time to the user.  My hope was to honor the user's preference setting.  I 
> am either missing something or honoring the user's preference is harder than 
> expected.
> 
> So, there are two places to set 24 hr time display.
> 
> 1. Date & Time preference panel
> 2. Language & Region preference panel 
> 
> The cocoa frameworks react differently depending on where you set this.
> 
> If set by method 1, cocoa frameworks seem unaware of this setting and it 
> appears this is cosmetic in that it only affects the display of the clock in 
> the NSStatusBar.
> 
> If set by method 2, cocoa frameworks reflect this and the Date & Time setting 
> is disabled noting that the setting has been overridden.
> 
> So if a user uses method 1, potentially unaware of method 2, how should one 
> go about determining the user's intentions.
> 
> There are deprecated methods using: (didn't try, it's deprecated)
>NSUserDefaults with the key NSShortTimeDateFormatString
> 
> There are supported methods using: (works with method 2)
>NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
> locale:[NSLocale currentLocale]];
>BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
> 
> Can anyone provide any clarity here?
> 
> Sandor
> ___
> 
> 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/archive%40mail-archive.com

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

Finalizing CVPixelBuffer while lock count is 1

[Torsten Curdt]

While doing some image processing I am also trying to detect QR codes from
an image buffer.
The following code works just fine

func captureOutput(_ captureOutput: AVCaptureOutput,
didOutputSampleBuffer sampleBuffer: CMSampleBuffer, from connection:
AVCaptureConnection) {

if !CMSampleBufferIsValid(sampleBuffer) {
return
}

let pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer)! as
CVPixelBuffer
var image = CIImage(cvPixelBuffer: pixelBuffer)

...

let qrFeatures = qrDetector?.features(in: CIImage(cvImageBuffer:
pixelBuffer))
print("qr", qrFeatures ?? "nil")

if let previewView = self.previewView {
previewView.image = image
}
}


but the QR code detector is producing a warning and spamming the console.

  Finalizing CVPixelBuffer 0x17412f500 while lock count is 1.
  qr []
  Finalizing CVPixelBuffer 0x17012ed80 while lock count is 1.
  qr []
  Finalizing CVPixelBuffer 0x17012ed80 while lock count is 1.
  qr []

>From this stackoverflow post it sounds like that's a iOS10 bug.


http://stackoverflow.com/questions/35956538/how-to-read-qr-code-from-static-image/35957461

Has anyone come across this before?

It sounds like an imbalance
of CVPixelBufferLockBaseAddress/CVPixelBufferUnlockBaseAddress calls. But
calling CVPixelBufferUnlockBaseAddress myself didn't help either.

Any thoughts on fixing this?

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

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

Re: 12 hr vs 24 hr time display

[Sandor Szatmari]

Steve,

> On Jan 3, 2017, at 12:28, Steve Christensen  wrote:
> 
>> On Jan 3, 2017, at 8:26 AM, Sandor Szatmari  
>> wrote:
>> 
>> Steve,
>> 
>>> On Jan 3, 2017, at 10:17, Steve Christensen  wrote:
>>> 
>>> In the Date & Time preference panel, I assume that you're referring to the 
>>> option on the Clock tab. If so, those settings refer only to the menubar 
>>> clock display.
>> I just think it's weird that there are two checkboxes.  It seems odd to me 
>> that one would want a 24 hr clock in the menu bar but not anywhere else.
> 
> The menubar clock settings also have options for displaying the time with or 
> without seconds, showing AM/PM, showing the day of the week, and showing the 
> date. These options all affect the final representation in the menubar, 
> independent of the locale settings, but you're focusing on just one of these.
Yes, I agree.
> 
> I have a little bit of experience with the menubar clock in the pre-OS X 
> world so I happen to know that those particular options were present as early 
> as 1992, so people have been living with the arrangement for a long time.
> 
>>> If you notice in that same preference panel, on the Date & Time tab, there 
>>> is a message at the bottom that says, "To set date and time formats, use 
>>> the Language & Region preferences." Clicking the button takes you to that 
>>> other panel, and there you will find a checkbox that lets you select 
>>> 24-hour time.
>> Yes, this is method 2 I referred to.  If you check the Language & Region 
>> checkbox it overrides the Date & Time checkbox, enabling 24 hr time display 
>> in the menu bar clock and disabling the Date & Time checkbox.  So clearly 
>> someone at Apple sees there is at least a one direction connection between 
>> these two checkboxes.
> 
> That's merely an implementation detail related to a private system feature. 
> It's no different than if you were to put such an option in your app.
I think it was the fact that Apple made a one direction connection allowing the 
clock's preference to be overridden is what made this unclear for me.
> 
>>> The Language & Region settings are what specify the locale that is used for 
>>> formatting date and time values (among other things), which is why you see 
>>> those changes reflected in the NSDateFormatter methods.
>> Yes, this discrepancy (IMHO) is what I was asking about.  I don't see why 
>> the option for the clock display would be separated from this option.
>> 
>> What I was asking for clarity on is the fact that there is no way to detect 
>> that the user prefers 24 hr time display if they only choose method 1, the 
>> Date & Time checkbox.  Should I allow my users to set 12 hr time but 
>> override it to 24 hr time if the Language & Region checkbox is checked?  
>> This doesn't feel right.  I feel like Apple left room for ambiguity in their 
>> design here.
> 
> The locale settings, in the Language & Region preference panel, specifies the 
> user's current preferences in terms of general time formatting. The clock 
> settings specify the user's current preferences for the menubar clock. I 
> don't see the ambiguity.
I guess Apple thought that setting the Language & Region 24 hr time setting was 
strong enough for them to disallow the menu bar clock from being displayed in 
12 hr format when it, the Language & Region, preference is set.

I guess part of me felt like the the clock should either be totally in sync 
with the Language & Region setting, or totally independent.  Understanding this 
better, I will have to just pick one implementation.

Thanks for everyone's opinions.

> 
> 
 On Jan 2, 2017, at 10:16 PM, Sandor Szatmari 
  wrote:
 
 I am working on a small application where the primary function is to 
 display the time to the user.  My hope was to honor the user's preference 
 setting.  I am either missing something or honoring the user's preference 
 is harder than expected.
 
 So, there are two places to set 24 hr time display.
 
 1. Date & Time preference panel
 2. Language & Region preference panel 
 
 The cocoa frameworks react differently depending on where you set this.
 
 If set by method 1, cocoa frameworks seem unaware of this setting and it 
 appears this is cosmetic in that it only affects the display of the clock 
 in the NSStatusBar.
 
 If set by method 2, cocoa frameworks reflect this and the Date & Time 
 setting is disabled noting that the setting has been overridden.
 
 So if a user uses method 1, potentially unaware of method 2, how should 
 one go about determining the user's intentions.
 
 There are deprecated methods using: (didn't try, it's deprecated)
 NSUserDefaults with the key NSShortTimeDateFormatString
 
 There are supported methods using: (works with method 2)
 NSString *format = [NSDateFormatter 

Re: 12 hr vs 24 hr time display

[Steve Christensen]

On Jan 3, 2017, at 8:26 AM, Sandor Szatmari  
wrote:
> 
> Steve,
> 
>> On Jan 3, 2017, at 10:17, Steve Christensen  wrote:
>> 
>> In the Date & Time preference panel, I assume that you're referring to the 
>> option on the Clock tab. If so, those settings refer only to the menubar 
>> clock display.
> I just think it's weird that there are two checkboxes.  It seems odd to me 
> that one would want a 24 hr clock in the menu bar but not anywhere else.

The menubar clock settings also have options for displaying the time with or 
without seconds, showing AM/PM, showing the day of the week, and showing the 
date. These options all affect the final representation in the menubar, 
independent of the locale settings, but you're focusing on just one of these.

I have a little bit of experience with the menubar clock in the pre-OS X world 
so I happen to know that those particular options were present as early as 
1992, so people have been living with the arrangement for a long time.

>> If you notice in that same preference panel, on the Date & Time tab, there 
>> is a message at the bottom that says, "To set date and time formats, use the 
>> Language & Region preferences." Clicking the button takes you to that other 
>> panel, and there you will find a checkbox that lets you select 24-hour time.
> Yes, this is method 2 I referred to.  If you check the Language & Region 
> checkbox it overrides the Date & Time checkbox, enabling 24 hr time display 
> in the menu bar clock and disabling the Date & Time checkbox.  So clearly 
> someone at Apple sees there is at least a one direction connection between 
> these two checkboxes.

That's merely an implementation detail related to a private system feature. 
It's no different than if you were to put such an option in your app.

>> The Language & Region settings are what specify the locale that is used for 
>> formatting date and time values (among other things), which is why you see 
>> those changes reflected in the NSDateFormatter methods.
> Yes, this discrepancy (IMHO) is what I was asking about.  I don't see why the 
> option for the clock display would be separated from this option.
> 
> What I was asking for clarity on is the fact that there is no way to detect 
> that the user prefers 24 hr time display if they only choose method 1, the 
> Date & Time checkbox.  Should I allow my users to set 12 hr time but override 
> it to 24 hr time if the Language & Region checkbox is checked?  This doesn't 
> feel right.  I feel like Apple left room for ambiguity in their design here.

The locale settings, in the Language & Region preference panel, specifies the 
user's current preferences in terms of general time formatting. The clock 
settings specify the user's current preferences for the menubar clock. I don't 
see the ambiguity.


>>> On Jan 2, 2017, at 10:16 PM, Sandor Szatmari  
>>> wrote:
>>> 
>>> I am working on a small application where the primary function is to 
>>> display the time to the user.  My hope was to honor the user's preference 
>>> setting.  I am either missing something or honoring the user's preference 
>>> is harder than expected.
>>> 
>>> So, there are two places to set 24 hr time display.
>>> 
>>> 1. Date & Time preference panel
>>> 2. Language & Region preference panel 
>>> 
>>> The cocoa frameworks react differently depending on where you set this.
>>> 
>>> If set by method 1, cocoa frameworks seem unaware of this setting and it 
>>> appears this is cosmetic in that it only affects the display of the clock 
>>> in the NSStatusBar.
>>> 
>>> If set by method 2, cocoa frameworks reflect this and the Date & Time 
>>> setting is disabled noting that the setting has been overridden.
>>> 
>>> So if a user uses method 1, potentially unaware of method 2, how should one 
>>> go about determining the user's intentions.
>>> 
>>> There are deprecated methods using: (didn't try, it's deprecated)
>>>  NSUserDefaults with the key NSShortTimeDateFormatString
>>> 
>>> There are supported methods using: (works with method 2)
>>>  NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
>>> locale:[NSLocale currentLocale]];
>>>  BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
>>> 
>>> Can anyone provide any clarity here?
>>> 
>>> Sandor


___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Jeremy,

> On Jan 3, 2017, at 10:30, Jeremy Pereira  
> wrote:
> 
> 
>> On 3 Jan 2017, at 06:16, Sandor Szatmari  
>> wrote:
>> 
>> I am working on a small application where the primary function is to display 
>> the time to the user.  My hope was to honor the user's preference setting.  
>> I am either missing something or honoring the user's preference is harder 
>> than expected.
>> 
>> So, there are two places to set 24 hr time display.
>> 
>> 1. Date & Time preference panel
>> 2. Language & Region preference panel 
>> 
>> The cocoa frameworks react differently depending on where you set this.
>> 
>> If set by method 1, cocoa frameworks seem unaware of this setting and it 
>> appears this is cosmetic in that it only affects the display of the clock in 
>> the NSStatusBar.
>> 
>> If set by method 2, cocoa frameworks reflect this and the Date & Time 
>> setting is disabled noting that the setting has been overridden.
>> 
>> So if a user uses method 1, potentially unaware of method 2, how should one 
>> go about determining the user's intentions.
> 
> It seems obvious to me that method 1 only refers to the clock display in the 
> menu bar and nothing else. It’s a sub setting of 
> “Show date and time in the menu bar”.
> 
> If you honour whatever preference is set by method 2 as your code fragment 
> below does, you’ll be fine.
> 
I feel like fewer people use/find method 2, simply stopping at method 1.  This 
may be a gross assumption on my part.  Under my assumption they would simply 
think my app doesn't display 24 hr time or respect the system setting.  Am I 
being to sensitive here?

Sandor
> 
>> 
>> There are deprecated methods using: (didn't try, it's deprecated)
>>   NSUserDefaults with the key NSShortTimeDateFormatString
>> 
>> There are supported methods using: (works with method 2)
>>   NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
>> locale:[NSLocale currentLocale]];
>>   BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
>> 
>> Can anyone provide any clarity here?
>> 
>> Sandor
>> ___
>> 
>> 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/adc%40jeremyp.net
>> 
>> This email sent to a...@jeremyp.net
> 
> --
> Jeremy Pereira
> jeremy.pere...@aptosolutions.co.uk
> 07884 265457
> 
> 
> 
> 

___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Steve,

> On Jan 3, 2017, at 10:17, Steve Christensen  wrote:
> 
> In the Date & Time preference panel, I assume that you're referring to the 
> option on the Clock tab. If so, those settings refer only to the menubar 
> clock display.
I just think it's weird that there are two checkboxes.  It seems odd to me that 
one would want a 24 hr clock in the menu bar but not anywhere else.
> 
> If you notice in that same preference panel, on the Date & Time tab, there is 
> a message at the bottom that says, "To set date and time formats, use the 
> Language & Region preferences." Clicking the button takes you to that other 
> panel, and there you will find a checkbox that lets you select 24-hour time.
Yes, this is method 2 I referred to.  If you check the Language & Region 
checkbox it overrides the Date & Time checkbox, enabling 24 hr time display in 
the menu bar clock and disabling the Date & Time checkbox.  So clearly someone 
at Apple sees there is at least a one direction connection between these two 
checkboxes.
> 
> The Language & Region settings are what specify the locale that is used for 
> formatting date and time values (among other things), which is why you see 
> those changes reflected in the NSDateFormatter methods.
Yes, this discrepancy (IMHO) is what I was asking about.  I don't see why the 
option for the clock display would be separated from this option.

What I was asking for clarity on is the fact that there is no way to detect 
that the user prefers 24 hr time display if they only choose method 1, the Date 
& Time checkbox.  Should I allow my users to set 12 hr time but override it to 
24 hr time if the Language & Region checkbox is checked?  This doesn't feel 
right.  I feel like Apple left room for ambiguity in their design here.
> 
> 
>> On Jan 2, 2017, at 10:16 PM, Sandor Szatmari  
>> wrote:
>> 
>> I am working on a small application where the primary function is to display 
>> the time to the user.  My hope was to honor the user's preference setting.  
>> I am either missing something or honoring the user's preference is harder 
>> than expected.
>> 
>> So, there are two places to set 24 hr time display.
>> 
>> 1. Date & Time preference panel
>> 2. Language & Region preference panel 
>> 
>> The cocoa frameworks react differently depending on where you set this.
>> 
>> If set by method 1, cocoa frameworks seem unaware of this setting and it 
>> appears this is cosmetic in that it only affects the display of the clock in 
>> the NSStatusBar.
>> 
>> If set by method 2, cocoa frameworks reflect this and the Date & Time 
>> setting is disabled noting that the setting has been overridden.
>> 
>> So if a user uses method 1, potentially unaware of method 2, how should one 
>> go about determining the user's intentions.
>> 
>> There are deprecated methods using: (didn't try, it's deprecated)
>>   NSUserDefaults with the key NSShortTimeDateFormatString
>> 
>> There are supported methods using: (works with method 2)
>>   NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
>> locale:[NSLocale currentLocale]];
>>   BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
>> 
>> Can anyone provide any clarity here?
>> 
>> Sandor
> 

___

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: 12 hr vs 24 hr time display

[Steve Christensen]

In the Date & Time preference panel, I assume that you're referring to the 
option on the Clock tab. If so, those settings refer only to the menubar clock 
display.

If you notice in that same preference panel, on the Date & Time tab, there is a 
message at the bottom that says, "To set date and time formats, use the 
Language & Region preferences." Clicking the button takes you to that other 
panel, and there you will find a checkbox that lets you select 24-hour time.

The Language & Region settings are what specify the locale that is used for 
formatting date and time values (among other things), which is why you see 
those changes reflected in the NSDateFormatter methods.


> On Jan 2, 2017, at 10:16 PM, Sandor Szatmari  
> wrote:
> 
> I am working on a small application where the primary function is to display 
> the time to the user.  My hope was to honor the user's preference setting.  I 
> am either missing something or honoring the user's preference is harder than 
> expected.
> 
> So, there are two places to set 24 hr time display.
> 
> 1. Date & Time preference panel
> 2. Language & Region preference panel 
> 
> The cocoa frameworks react differently depending on where you set this.
> 
> If set by method 1, cocoa frameworks seem unaware of this setting and it 
> appears this is cosmetic in that it only affects the display of the clock in 
> the NSStatusBar.
> 
> If set by method 2, cocoa frameworks reflect this and the Date & Time setting 
> is disabled noting that the setting has been overridden.
> 
> So if a user uses method 1, potentially unaware of method 2, how should one 
> go about determining the user's intentions.
> 
> There are deprecated methods using: (didn't try, it's deprecated)
>NSUserDefaults with the key NSShortTimeDateFormatString
> 
> There are supported methods using: (works with method 2)
>NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
> locale:[NSLocale currentLocale]];
>BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
> 
> Can anyone provide any clarity here?
> 
> Sandor


___

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: 12 hr vs 24 hr time display

[Sandor Szatmari]

Quincy,



Sandor
> On Jan 3, 2017, at 04:35, Quincey Morris 
>  wrote:
> 
>> On Jan 2, 2017, at 22:16 , Sandor Szatmari  
>> wrote:
>> 
>> There are supported methods using: (works with method 2)
>>NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
>> locale:[NSLocale currentLocale]];
>>BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);
> 
> Well of course this won’t work in every locale, not even all the 
> English-speaking ones, since (IIRC) it’s “AM” in some of them, but I assume 
> you’ve breezed right past that small point. :)

Are you suggesting case sensitivity is an issue here?  If so, I don't think so. 
 The template returned from this method uses 'a' as a place holder for AM/PM.  
e.g. It might return the string 'h a' as it does by default for the English/US 
locale on my system, and a is always lower case.  This is described here 
http://www.unicode.org/reports/tr35/tr35-31/tr35-dates.html#Date_Format_Patterns
 See the 'period' field in the Date Field Symbol Table and section 8.2 for my 
justification.

> 
> It seems to me you have two choices. One is to honor the setting for time 
> *text* and to use the date formatter result unmodified (which means you might 
> get more characters than just the 3 or 4 or 5 that represent the time with a 
> possible separator). Or, if your app really is more like a clock, then I’d 
> make the 12/24 hr format a setting within the app. As you’ve seen from the 
> menu bar clock, there does seem to be a possible distinction between clock 
> time format and annotation time. Since you can’t access the menu bar format 
> (no public API at least), a one-time app setting seems reasonable.

Yea, I was considering just making it an app local preference but that strikes 
me as crude.  Ideally speaking, at best an appropriate preference for my app 
could be 'Override System 24 hr time preference' or something akin.

But, I might have to settle for that...
> 
___

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: UIModalPresentationFormSheet on iPad and iPhone

[Andreas Falkenhahn]

Solved this now. Of course I can just add all the GUI controls to another 
subview
and then center this subview in the root view's frame. This makes the GUI look
good on both iPad and iPhone. 

On 02.01.2017 at 17:59 Andreas Falkenhahn wrote:

> As described in the docs, view controllers that have their 
> modalPresentationStyle
> set to UIModalPresentationFormSheet open in a popover over the presenting view
> controller on iPad whereas on iPhone they often (but not always) appear full
> screen.

> Since I don't use Interface Builder/Storyboards to create my GUI but instead
> initialize it manually viewDidLoad(), I need to find a way to deal with this
> situation. On the iPad everything is nice: I set preferredContentSize to the
> desired size and then do the layout in viewDidLayoutSubviews() and everything
> appears nicely centered on screen.

> On the iPhone, however, it looks quite ugly because the GUI now appears in the
> top-left corner with lots of space to the bottom and to the right of the GUI.
> In order to make this look nicer, I guess I'd have to center all my subviews
> in viewDidLayoutSubviews() manually. But this is of course quite some work
> so I am wondering whether there isn't an easier solution to this? 

> Also, how do I detect in viewDidLayoutSubviews() or viewDidLayout() whether
> the view controller is being shown as a popover (as on iPad) or in fullscreen
> mode (as on iPhone)? 



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

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

Re: 12 hr vs 24 hr time display

[Quincey Morris]

On Jan 2, 2017, at 22:16 , Sandor Szatmari  wrote:
> 
> There are supported methods using: (works with method 2)
>NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
> locale:[NSLocale currentLocale]];
>BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);

Well of course this won’t work in every locale, not even all the 
English-speaking ones, since (IIRC) it’s “AM” in some of them, but I assume 
you’ve breezed right past that small point. :)

It seems to me you have two choices. One is to honor the setting for time 
*text* and to use the date formatter result unmodified (which means you might 
get more characters than just the 3 or 4 or 5 that represent the time with a 
possible separator). Or, if your app really is more like a clock, then I’d make 
the 12/24 hr format a setting within the app. As you’ve seen from the menu bar 
clock, there does seem to be a possible distinction between clock time format 
and annotation time. Since you can’t access the menu bar format (no public API 
at least), a one-time app setting seems reasonable.

___

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

12 hr vs 24 hr time display

[Sandor Szatmari]

I am working on a small application where the primary function is to display 
the time to the user.  My hope was to honor the user's preference setting.  I 
am either missing something or honoring the user's preference is harder than 
expected.

So, there are two places to set 24 hr time display.

1. Date & Time preference panel
2. Language & Region preference panel 

The cocoa frameworks react differently depending on where you set this.

If set by method 1, cocoa frameworks seem unaware of this setting and it 
appears this is cosmetic in that it only affects the display of the clock in 
the NSStatusBar.

If set by method 2, cocoa frameworks reflect this and the Date & Time setting 
is disabled noting that the setting has been overridden.

So if a user uses method 1, potentially unaware of method 2, how should one go 
about determining the user's intentions.

There are deprecated methods using: (didn't try, it's deprecated)
NSUserDefaults with the key NSShortTimeDateFormatString

There are supported methods using: (works with method 2)
NSString *format = [NSDateFormatter dateFormatFromTemplate:@"j" options:0 
locale:[NSLocale currentLocale]];
BOOL is24Hour = ([format rangeOfString:@"a"].location == NSNotFound);

Can anyone provide any clarity here?

Sandor
___

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