Re: Decompressing JPEG data into specific format, getting raw pixels

[Doug Hill]

> On Aug 15, 2017, at 9:54 AM, Sean McBride <s...@rogue-research.com> wrote:
> 
> On Tue, 15 Aug 2017 09:41:25 -0700, Doug Hill said:
> 
>> Check out CoreImage ColorControls filter, which has a Saturation parameter:
> 
> Thanks Doug and Jonathan for the CIImage suggestion, I'll take a closer look. 
>  But one thing I don't see at all in CIImage.h is how to get an NSData of the 
> pixels of a CIImage.  There are init methods that take NSData, but nothing I 
> see gives NSData.
> 
> I should note that I have no need to draw this data whatsoever.  I only need 
> access to the raw pixels to do some custom processing on.

NSBitmapImageRep can be created from a CIImage, and has methods for creating an 
NSData version of the bitmap, or just getting the bitmapData and/or data planes.

Doug
___

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: Decompressing JPEG data into specific format, getting raw pixels

[Doug Hill]

Check out CoreImage ColorControls filter, which has a Saturation parameter:

https://developer.apple.com/library/content/documentation/GraphicsImaging/Reference/CoreImageFilterReference/#//apple_ref/doc/filter/ci/CIColorControls
 
<https://developer.apple.com/library/content/documentation/GraphicsImaging/Reference/CoreImageFilterReference/#//apple_ref/doc/filter/ci/CIColorControls>

"To calculate saturation, this filter linearly interpolates between a grayscale 
image (saturation = 0.0) and the original image (saturation = 1.0).”

Doug Hill


> On Aug 15, 2017, at 9:23 AM, Sean McBride <s...@rogue-research.com> wrote:
> 
> I get some JPEG data from the network.  I want to efficiently decompress this 
> data into a specific format (8 bit greyscale) and have an NSData of the raw 
> pixels.  What's the best way to do this?
> 
> I'm currently using NSBitmapImageRep initWithData:, then testing if the 
> result is greyscale or RGB.  If the latter, I write my own loop to convert to 
> greyscale.
> 
> But I'm hoping there is some lower level API available that I can tell 
> explicitly that I want greyscale...
___

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

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

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

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

Re: Is "-init" really needed?

[Doug Hill]

> On Aug 8, 2017, at 2:15 PM, Uli Kusterer <witness.of.teacht...@gmx.net> wrote:
> 
> On 8. Aug 2017, at 18:38, Doug Hill <cocoa...@breaqz.com> wrote:
>> As others have mentioned, I too have never seen any evidence or statements 
>> from Apple that discourages +new or -init. Or designated initializers.
> 
> I never said anything about init or designated initializers. In fact, ObjC 
> gained support for marking designated initializers fairly recently.

I was responding to a lot of different issues in my email, not necessarily just 
yours. My apologies if it came off that way.

But, that said, designated initializers have been in the Objective-C 
Programming Guide from Apple since at least 2003 (the earliest version of the 
document I can find). And this pattern probably originated in the NeXT days. 
What are the recent developments in designated initializers?

Doug Hill
___

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

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

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

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

Re: Is "-init" really needed?

[Doug Hill]

> On Aug 9, 2017, at 3:01 AM, Alastair Houghton <alast...@alastairs-place.net> 
> wrote:
> 
> On 8 Aug 2017, at 17:38, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> As others have mentioned, I too have never seen any evidence or statements 
>> from Apple that discourages +new or -init.
> 
> I suspect it was ObjC programmers themselves rather than Apple/NeXT that 
> discouraged it.  As for why, well I can imagine a few reasons:
> 
> - Performance - it incurs an extra message send (which would have been an 
> issue back in the day)

+new requires no extra message. It's just a shorthand for [[SomeClassname 
alloc] init]

> - Clarity - [[… alloc] init] shows clearly that it’s a two step operation 
> (some classes support being *re*-initialized, so you can call initialisers 
> more than once; other classes don’t actually need initialising)

Some say that it's far more confusing and hard to read the alloc/init syntax.

> - If +new was the way to go, you’d need variants of +new for each variant of 
> -init (or you have to use [[… alloc] init] anyway)

There has never been an issue with this. +new saves you some typing for one 
syntax but has no impact on anything else.

> - The fact that convenience constructors were often written naming the 
> object, e.g. [NSString stringWithFormat:…], [NSArray array].  +new would 
> duplicate that, but isn’t as nice to read or look at.  OK, +new doesn’t 
> autorelease, but still.

With ARC, autorelease behavior is essentially hidden from the developer and 
doesn't really matter any more. Again, +new is unrelated to all the other class 
methods.

Doug Hill 
___

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

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

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

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

Re: Is "-init" really needed?

[Doug Hill]

As others have mentioned, I too have never seen any evidence or statements from 
Apple that discourages +new or -init. Or designated initializers. The 
Objective-C Programming Guide from Apple describes very well all of the above 
and the reasoning behind using them. Please point to evidence, such as 
documentation or statements by Apple. My fear is that further speculation 
without backup is confusing people.

Getting back to the original question…you still need -init. And on a related 
note, it’s a great shorthand to use +new.

Doug Hill


> On Aug 8, 2017, at 6:46 AM, gerti-cocoa...@bitart.com wrote:
> 
> Unlike with Swift, in Objective-C it is to no small part the developers who 
> drive how the language evolves.
> 
> +new used to be the canonical initializer in the very olden days. But then 
> folks wanted a better distinction between object allocation and object 
> initialization to make memory management a bit more mechanical and less 
> hidden. They also came up with the concept of the "designated initializer". 
> That was in the very early 80s IIRC.
> 
> This worked, but two things happened:
> 
> - having to remember designated initializers, and chaining them correctly 
> when subclassing, is a tad cumbersome. It's like having to know a secret 
> handshake to use an object. Further Objective-C never formally introduced 
> syntactic support for a designated initializer, so eventually some people 
> resorted to some weird hinting with macros. Yuk.
> 
> - ARC
> 
> So "designated initializers" became de-emphasized over time, most modern 
> objects rarely use them. And ARC now makes it less important to distinguish 
> between object allocation and object initialization. Hence the renaissance of 
> +new. And with the advent of dot notation some (like me) even started to 
> further de-emphasize that by using "MyClass.new". This is debatable I guess, 
> but I like it, because it visually distracts less from the purpose of the 
> surrounding code.
> 
> Just my 2 cents, and I may be completely wrong.
> 
> Gerd
> 
> 
>> On Aug 8, 2017, at 05:13, Uli Kusterer <witness.of.teacht...@gmx.net 
>> <mailto:witness.of.teacht...@gmx.net>> wrote:
>> 
>> On 8. Aug 2017, at 02:23, Carl Hoefs <newsli...@autonomy.caltech.edu> wrote:
>>> Is the use of +new discouraged also?
>> 
>> Apple have gone back and forth on this AFAIR. +new was actually the 
>> pre-retain/release way to create an object. So it has been discouraged since 
>> ... OpenStep, I think? But it was never formally deprecated, and I'm seeing 
>> it used more and more in ARC code these days.
>> 
>> Cheers,
>> -- Uli Kusterer
>> "The Witnesses of TeachText are everywhere..."
>> http://www.zathras.de
> 

___

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: Who owns a child view controller?

[Doug Hill]

> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes <moon.rab...@virginmedia.com> 
> wrote:
> 
>> On 12 Jul 2017, at 22:07, Quincey Morris 
>> <quinceymor...@rivergatesoftware.com> wrote:
>> 
>>> Or there's something else going on under the covers.
>> 
>> Yes, you are correct, betting *against* this assumption is a really, really 
>> terrible idea. Reasoning about the point at which objects actually 
>> deallocate is a code smell.
> 
> I’m trying to understand memory management so I can avoid retain cycles and 
> other issues.
> 
> …
> 
> If I release the child view controllers of this top-level view controller (by 
> assigning an empty array to childViewControllers), my expectation is that I 
> don’t have to release every view controller and view in the hierarchy because 
> they are effectively owned by the top-level view controller.

While this discussion has been good at understanding underlying ARC and manual 
ref-count issues, my guess as to what's causing these issues is that you 
shouldn't just assign nil to the childViewControllers array. You should try 
calling:

childVC.removeFromParentViewController()

for each child view controller.

Hopefully this is the source of your object-ownership issues.

Doug Hill

___

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: Embedded Collection View Controller scrolling issue

[Doug Hill]

Following up…

I had some people mention the inherent difficulties of 
scroller-within-a-scroller implementations. After some more testing I notice 
that all taps are being ignored by subviews in the scroller as I scroll content 
up. That is, the newly displayed content will now not respond to any taps.

A long shot I know, but any ideas on how to debug this before going through the 
TSI route? I'm sure that has to be some techniques for figuring this out.

Doug Hill
https://github.com/djfitz/SFFontFeatures 
<https://github.com/djfitz/SFFontFeatures>


> On Jun 19, 2017, at 11:45 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> Hello Quincey,
> 
> First, I should have originally made clear this is iOS, apologies. Also, to 
> clarify, I am talking about the drag-scroll gesture, which would be the Pan 
> gesture. 
> 
> The scroller-within-a-scroller is definitely more complex but I've usually 
> made them work in previous view controllers I've developed. Like you, I don't 
> really have a great idea of what is happening under the hood in these various 
> UIScrollviews. Or even a good idea how to debug what seems like lower-level 
> stuff.
> Thinking about it more, I might look into priorities of the gesture 
> recognizers, since this sounds like it could be related. Otherwise, I'm still 
> looking for other ways to track this down.
> 
> Thanks again.
> 
> Doug Hill
> 
> 
>> On Jun 19, 2017, at 11:29 PM, Quincey Morris 
>> <quinceymor...@rivergatesoftware.com> wrote:
>> 
>> On Jun 19, 2017, at 16:22 , Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>>> 
>>> The embedded collection view will only scroll if I drag on the area of the 
>>> collection view that is originally visible.
>> 
>> Can you clarify this a bit? Are you talking about the autoscrolling that 
>> happens when you drag-select, or scrolling that happens when you use a 
>> scroll gesture on a trackpad? If you click on one of the 
>> previously-hidden-but-now-exposed rows, then try to drag it as a separate 
>> step, does the scroll happen?
>> 
>> I’d assume the problem arises because you have a scroll view within a scroll 
>> view, and each scroll has installed a pan gesture recognizer. The recognizer 
>> may be capturing the visibleRect of the scrolled view, and when you scroll 
>> the outer view, there may not be anything to tell the inner view that its 
>> visibleRect has changed.
>> 
>> This is all pretty moot, though. Even if that’s the explanation, I can’t 
>> think of anything you can do about it.

___

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: Embedded Collection View Controller scrolling issue

[Doug Hill]

> On Jun 19, 2017, at 11:50 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jun 19, 2017, at 23:45 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> I'm still looking for other ways to track this down.
> 
> I think you’re going to have to submit a bug report or use a TSI to get Apple 
> to tell you what to do.

Sigh, I seem to get a lot of these.

Thanks for the input.

Doug Hill
___

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: Embedded Collection View Controller scrolling issue

[Doug Hill]

Hello Quincey,

First, I should have originally made clear this is iOS, apologies. Also, to 
clarify, I am talking about the drag-scroll gesture, which would be the Pan 
gesture. 

The scroller-within-a-scroller is definitely more complex but I've usually made 
them work in previous view controllers I've developed. Like you, I don't really 
have a great idea of what is happening under the hood in these various 
UIScrollviews. Or even a good idea how to debug what seems like lower-level 
stuff.
Thinking about it more, I might look into priorities of the gesture 
recognizers, since this sounds like it could be related. Otherwise, I'm still 
looking for other ways to track this down.

Thanks again.

Doug Hill


> On Jun 19, 2017, at 11:29 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Jun 19, 2017, at 16:22 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> The embedded collection view will only scroll if I drag on the area of the 
>> collection view that is originally visible.
> 
> Can you clarify this a bit? Are you talking about the autoscrolling that 
> happens when you drag-select, or scrolling that happens when you use a scroll 
> gesture on a trackpad? If you click on one of the 
> previously-hidden-but-now-exposed rows, then try to drag it as a separate 
> step, does the scroll happen?
> 
> I’d assume the problem arises because you have a scroll view within a scroll 
> view, and each scroll has installed a pan gesture recognizer. The recognizer 
> may be capturing the visibleRect of the scrolled view, and when you scroll 
> the outer view, there may not be anything to tell the inner view that its 
> visibleRect has changed.
> 
> This is all pretty moot, though. Even if that’s the explanation, I can’t 
> think of anything you can do about it.
> 

___

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

Embedded Collection View Controller scrolling issue

[Doug Hill]

I have a View Controller that has some embedded view controllers in it. One of 
the embedded view controllers is a Collection View Controller. This view 
controller is a grid of values that can be an arbitrary content size (e.g. 
number of cells) but the collection view bounds has fixed size. The collection 
view content can scroll within it's bounds, in addition to the parent scroll 
view scrolling the entire collection view..

Everything seems to work fine except for the scroller-in-a-scroller issue. 
Since the parent view controller can have many embedded child view controllers, 
the parent height can be very big. Then the embedded collection view can also 
scroll it's own content separately. That is, the child collection view width is 
small compared to it's content so that the view will scroll as needed inside 
the parent view as a separate scroll view.

OK, all is good so far except for the following. The embedded collection view 
will only scroll if I drag on the area of the collection view that is 
originally visible. That is, the area of the embedded collection view that is 
visible when first displayed. Let's say rows 1 to 10 are initially visible.
However, if I scroll the parent scroll view vertically to show row 11 of the 
collection view, and then attempt to scroll the embedded scroll view 
horizontally while dragging in row 11, it will only scroll the parent scroll 
view. But if I scroll in the area of the embedded view that was originally 
visible (rows 1 through 10) I can scroll the content of the collection view.

I checked the scroll view content size for both the parent and child scroll 
views and they seem to be correct. I'm looking for ways to debug this. Any 
ideas is appreciated.

Doug Hill
___

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: Button doesn't respond to touches in landscape mode

[Doug Hill]

FWIW, I finally figured this out. There was a fully transparent view covering 
the button that had incorrect autolayout constraints. The problem would only 
manifest in landscape mode due to a bit of luck. Really staring at the view 
debugging tree helped me spot the overlapping view.

Doug

> On May 19, 2017, at 12:14 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> I have a button in my view controller view in a storyboard. As far as I can 
> tell, there's nothing particularly interesting about this button. Just a 
> standard system button with a title.
> 
> When the device is in portrait mode, the button can be tapped anywhere in 
> it's bounds to send control messages. When I rotate the device to landscape 
> mode, I can only tap on a very small area on the top of the button. 
> Otherwise, taps are ignored.
> 
> The button seems to layout with autolayout correctly, there are no autolayout 
> warnings in the storyboard or at runtime. View debugging doesn't show 
> anything weird about this button.
> 
> Any ideas on how to troubleshoot this?
> 
> Doug Hill
> https://github.com/djfitz/SFFontFeatures

___

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

Button doesn't respond to touches in landscape mode

[Doug Hill]

I have a button in my view controller view in a storyboard. As far as I can 
tell, there's nothing particularly interesting about this button. Just a 
standard system button with a title.

When the device is in portrait mode, the button can be tapped anywhere in it's 
bounds to send control messages. When I rotate the device to landscape mode, I 
can only tap on a very small area on the top of the button. Otherwise, taps are 
ignored.

The button seems to layout with autolayout correctly, there are no autolayout 
warnings in the storyboard or at runtime. View debugging doesn't show anything 
weird about this button.

Any ideas on how to troubleshoot this?

Doug Hill
https://github.com/djfitz/SFFontFeatures
___

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: Exporting a public key from the secure enclave

[Doug Hill]

> On May 15, 2017, at 3:46 PM, Jens Alfke <j...@mooseyard.com> wrote:
> 
> Is there a specific reason you’re trying to work with the secure enclave 
> directly, and not just the keychain?
> 
> In my experience the Keychain APIs are mind-curdlingly horrible to work with, 
> and the newer the feature you’re trying to use, the worse they get. Have you 
> tried doing this stuff without getting the secure enclave involved?
> 
> —Jens



The reason I'm using the secure enclave is because, as of iOS 9, you can create 
an EC key inside the enclave where the private key can't be copied. You are 
only able to perform cryptographic operations inside the secure enclave using 
these keys. Only the public key is exportable, no one can get access to the 
private key, even the user. 

And yes, the Security framework APIs are pretty wonky, and require an intense 
amount of cryptographic knowledge to use correctly. But at this point the 
roadblocks I'm running into aren't dealing with the enclave, but trying to pass 
data from iOS to a Linux version of openssl. And that has complexity which is 
off the scale and has little to no documentation, especially when using EC 
keys. Not counting all the forked versions of openssl out there. Apple still 
uses 0.9.8 on macOS and the Linux server I'm working with has 1.0.1. And I see 
many Google search results for versions talking about features neither of these 
versions support. So maddening.

Apparently a number of people have made this all work, given the sample code 
and dev forum posts I'm reading, so I'll see if I can do the same. But I hear 
you, this is all pretty difficult to use.

Doug Hill
___

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: Exporting a public key from the secure enclave

[Doug Hill]

> On May 15, 2017, at 2:20 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On May 15, 2017, at 14:08 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Also, the Security developer forum has held up my forum post for moderation 
>> for almost 4 days.
> 
> You really should ask Quinn (the Eskimo). The moderation was probably due to 
> the external GitHub link. Try removing the “https” and “://“. People will 
> still know what you mean.
> 
> Or just email Quinn directly. He might even be able to assist getting your 
> existing post out of moderation.

Thanks for the feedback. I will contact him directly.

HOWEVER…if anyone else has worked with exporting EC keys from the Secure 
Enclave, please let me know.

Doug Hill
___

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

Exporting a public key from the secure enclave

[Doug Hill]

I'm attempting to implement what is described in this developer forum post:

https://forums.developer.apple.com/message/84684#84684 
<https://forums.developer.apple.com/message/84684#84684>

That is, export an elliptic curve public key from the secure enclave.

Unfortunately, this doesn't work for me. Also, the Security developer forum has 
held up my forum post for moderation for almost 4 days. So I thought I'd ask 
here.

--

I'm trying to send secure messages between our server and iOS app. I see the 
following forum post about how to do send a public key to a server:
 
https://forums.developer.apple.com/message/84684#84684 
<https://forums.developer.apple.com/message/84684#84684>
 
except it doesn't work. I even use the sample code in the referenced git repo
 
https://github.com/hfossli/EskimoKeys/tree/master 
<https://github.com/hfossli/EskimoKeys/tree/master>
 
but this sample code fails key verification.  FWIW, here is my output of 
running the sample code:
 
>>>>>>>>>>>>>>>>>>

#! /bin/sh
echo This string was signed after 2017-05-15 20:57:20 +. | xxd -r -p > 
dataToSign.dat
echo 
3044022036fb9f4f0bb18cffae4da20be7130a9e2d2a22529ce97cf63302c099ac150f64022038c7f7cfb94510a1eb1397650eb2f8952c5a996dc5f5680ae91c0bfe40162b24
 | xxd -r -p > signature.dat
cat > key.pem <>>>>>>>>>>>>>>>>>
 
Runing the script I get the following error message:
 
"Verification Failure"
 
Unfortunately, I don't know enough about openssl to figure what the problem is. 
FWIW I can analyze the public key with the following script:
 
$ openssl asn1parse -in pubkey.b64 -inform PEM
 
Output:
0:d=0  hl=2 l=  89 cons: SEQUENCE
2:d=1  hl=2 l=  19 cons: SEQUENCE
4:d=2  hl=2 l=   7 prim: OBJECT:id-ecPublicKey
   13:d=2  hl=2 l=   8 prim: OBJECT:prime256v1
   23:d=1  hl=2 l=  66 prim: BIT STRING  
 
So the public key looks valid, but I can't do the signature verification as the 
above-mentioned forum post describes.
 
Any ideas? Thanks.
 
Doug Hill
___

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: Does file-mapping a memory allocation work around RAM limits?

[Doug Hill]

> On May 3, 2017, at 6:21 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
> Our iOS app works with very large data buffers (hundreds of MB). As you can 
> imagine, we run into issues at times.
> 
> I saw some sample code that used this technique, and it got me wondering if 
> this actually works around the 600 MB limitation of some iOS devices (which 
> begs another question: doss the large iPad Pro with 3GB of RAM also limit 
> apps to 600 MB?).
> 
> -- 
> Rick Mann
> rm...@latencyzero.com

The limits of mmap should be the limits of the file system. Well, technically 
it’s limited by the size_t parameter which I guess is OS specific. But these 
days it should be what the VFS can handle.

I just tried out this code snippet:

http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/ 
<http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/>

and set the size of the mapped file to 32GB Works fine on a Mac with 16GB of 
RAM.

It is SLOOWW however. You have to move all that data across a bus after 
all. If you need to load 3GB of data from your file, I recommend making it 
happen on a background thread. And make some lights blink and play a happy tune 
while the user waits.

Not sure what the limitation on some iOS devices you’re referring to. Is it 
dependent on the installed RAM? Are there other artificial limits?

Doug Hill
___

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: Reference to embedded view controller in IB?

[Doug Hill]

OK, this looks like the official solution. I see that on iOS my prepareForSegue 
method is being called for the embed segues, and this is called before 
viewDidLoad.

Excellent!

Doug Hill
https://github.com/djfitz/SFFontFeatures 
<https://github.com/djfitz/SFFontFeatures>


> On Apr 6, 2017, at 4:43 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Apr 6, 2017, at 14:55 , Kyle Sluder <k...@ksluder.com> wrote:
>> 
>> It is not called for all segues, but it should be called for embed
>> segues created by dragging out a Container View from the Object Library.
> 
> I was wondering about this, like Jean-Daniel was, so I just tried it in an 
> existing Mac project, and the prepareForSegue: override (NSViewController 
> subclass) for an embed segue *was* called.

___

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: Reference to embedded view controller in IB?

[Doug Hill]

Alright, thanks for the follow-up. It looks there's nothing built into UIKit 
for doing this lookup or a way to store a reference in IB, so I'll try one of 
these solutions.

Doug Hill
https://github.com/djfitz/SFFontFeatures 
<https://github.com/djfitz/SFFontFeatures>


> On Apr 5, 2017, at 2:30 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Apr 5, 2017, at 14:06 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Let's say, views are in position 1, 2, and 3 and I want to configure 1, 2,  
>> and 3 differently based on their position.
> 
> The simplest way would be to set a different tag on each view, and 
> distinguish between them using “viewController.view.tag”. The slightly less 
> simple but slightly more elegant way would be to define a property on the 
> view controller itself, and use the “User Defined Run Time Attributes” editor 
> on the Identity inspector to set a different value for each view controller.
> 
> Or you could sort the childViewControllers array on 
> viewController.view.origin.y, and identify the view controllers from their 
> sorted index.
> 
>> I'm thinking of making a outlet to the embedding view and then compare this 
>> view with view controllers in childViewControllers. But seems like a lot of 
>> busy work It would be great to be able to more easily lookup the view 
>> controller for a particular embed view. Any chance?
> 
> I think one of the above techniques would be easier.
> 

___

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: Reference to embedded view controller in IB?

[Doug Hill]

Thanks for the follow up.
I saw this but I happen to have multiple embedded view controllers. While it's 
possible to do a search, it's more difficult because there are multiple embed 
view with the same view controller class. Let's say, views are in position 1, 
2, and 3 and I want to configure 1, 2,  and 3 differently based on their 
position.
I'm thinking of making a outlet to the embedding view and then compare this 
view with view controllers in childViewControllers. But seems like a lot of 
busy work It would be great to be able to more easily lookup the view 
controller for a particular embed view. Any chance?

Doug Hill
https://github.com/djfitz/SFFontFeatures 
<https://github.com/djfitz/SFFontFeatures>


> On Apr 5, 2017, at 1:55 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Apr 5, 2017, at 13:42 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Can this be done? Are there other ways to get a reference to the embedded 
>> view controller at runtime?
> 
> I believe you’ll find the embedded view controller in the root view 
> controller’s “childViewControllers” array property.
> 

___

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

Reference to embedded view controller in IB?

[Doug Hill]

I have a view controller that I instantiate in my Storyboard. This view 
controller has an embedding view inside it's view, and this embedding view has 
another view controller in it.

I need to configure this embedded view controller but I don't know a way to 
make it available to my container VC in Interface Builder. For example, it 
would be great to create an outlet in my container view controller to the 
embedded view controller. But I don't see any way to do this.

Can this be done? Are there other ways to get a reference to the embedded view 
controller at runtime?

Thanks.

Doug Hill
https://github.com/djfitz/SFFontFeatures 
___

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: -forceCancel an NSOperation

[Doug Hill]

> On Mar 1, 2017, at 2:44 PM, Wim Lewis <w...@omnigroup.com> wrote:
> 
> On Mar 1, 2017, at 2:23 PM, Carl Hoefs <newsli...@autonomy.caltech.edu> wrote:
>> Normally, that is sufficient. But under some circumstances, it's possible 
>> for an executing NSOperation to get hung up doing I/O or for some other 
>> reason. No means is given to forcibly stop the execution of an NSOperation, 
>> and there's no -thread method to obtain its thread and terminate it. 
> 
> As Ken Thomases says, this probably can't be done safely in the *general* 
> case.
> 
> If you have a specific operation which might need to be asynchronously 
> interrupted, you can probably install a per-thread signal handler (remember 
> to clean it up on completion) and stash a thread identifier somewhere on the 
> NSOperation where your other code can find it. The handler could cancel any 
> blocked syscall and/or set a flag somewhere it can be cheaply checked by 
> cpu-intensive code.
> 
> Truly asynchronously terminating a thread is unsafe unless you're very 
> careful about what might be happening in there: lots of library calls can 
> take out global locks temporarily (e.g., anything that uses malloc/free or 
> sends objc messages), and dropping one of those locks will promptly cause 
> your application to hang.

FWIW, pthread_cancel has historically not been implemented in any meaningful 
way on Darwin and this functionality is generally not useful. For example, 
there are no cancel points for typical file/network I/O system calls. (e.g. 
fread/fwrite) AFAIK, there's no way to cancel a synchronous system call via a 
thread (e.g. without killing the process). I would be interested to hear 
otherwise.

I think the best you can do, as has been suggested, is to set a flag that the 
blocked thread can check after it wakes up again so it knows not to continue 
processing.

Doug Hill
___

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

[off-topic] Re: Overriding the release mehod

[Doug Hill]

> On Jan 25, 2017, at 11:56 AM, Dave <d...@looktowindward.com> wrote:
> 
> 
>> On 25 Jan 2017, at 19:37, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> 
>>> On Jan 25, 2017, at 11:23 AM, Dave <d...@looktowindward.com 
>>> <mailto:d...@looktowindward.com>> wrote:
>>> 
>>> I also tried searching “release method documentation” but nada!
>> 
>> I hear you about the search functionality of Apple's developer 
>> documentation. They definitely need a better search engine for documentation 
>> in both Xcode and the developer website as finding things can be iffy at 
>> best. They seem to suffer from what I call the 'Dictionary Problem.' You 
>> can't find the spelling of a word in a dictionary unless you already roughly 
>> know the spelling. Similarly,  you can't find anything in Apple's 
>> documentation unless you roughly know where it is.
>> 
>> A couple of recommendations:
>> 
>> 1. Use Google search to search developer.apple.com 
>> <http://developer.apple.com/>
>> 
>> For example, searching for 'nsobject release' returns the protocol it's 
>> defined as the first result, the method documentation as the second.
>> 
>> 2. Feel free to encourage Apple to improve their search functionality
> 
> it used to work much better, then Apple “improved it” and now it is as it is. 
> One can only assume they changed it for good reason so why moan about it to 
> them. I’ve largely found it a complete waste of time, once Apple decide to 
> “improve” something then it is automatically better in their eyes and no 
> amount of logic or use (or lack of use) cases can change their minds. Just 
> look at XCode code in general…… They probably don’t have the resources to do 
> it properly any more as they are spending their money on teams of accountants 
> to research tax dodging….. 
> 
> All the Best
> Dave

This is starting to go off topic, and we want to avoid getting into personal 
attacks on this list but… I suspect if every developer complained to Apple 
about problems, things would probably change pretty quickly. Apple indeed has 
limited resources and has to devote them to maximum benefit. If developers are 
consistently having problems, telling Apple gets those problems higher priority.

Anyways, feel free to respond off-list.

Doug Hill



___

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: Overriding the release mehod

[Doug Hill]

> On Jan 25, 2017, at 11:23 AM, Dave <d...@looktowindward.com> wrote:
> 
> I also tried searching “release method documentation” but nada!

I hear you about the search functionality of Apple's developer documentation. 
They definitely need a better search engine for documentation in both Xcode and 
the developer website as finding things can be iffy at best. They seem to 
suffer from what I call the 'Dictionary Problem.' You can't find the spelling 
of a word in a dictionary unless you already roughly know the spelling. 
Similarly,  you can't find anything in Apple's documentation unless you roughly 
know where it is.

A couple of recommendations:

1. Use Google search to search developer.apple.com <http://developer.apple.com/>

For example, searching for 'nsobject release' returns the protocol it's defined 
as the first result, the method documentation as the second.

2. Feel free to encourage Apple to improve their search functionality

Cheers!

Doug Hill
___

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: Overriding the release mehod

[Doug Hill]

> On Jan 25, 2017, at 10:59 AM, Dave  wrote:
> 
> Hi,
> 
>> Look at Apple's Foundation NSObject protocol reference document for the 
>> -release method. It includes this statement:
> 
> Could you point me to the URL I still can’t find it. Apple’s documentation is 
> absolutely shocking! I’m looking at 
> https://developer.apple.com/reference/objectivec/protocol?language=objc but 
> no mention of release to be found?
> 
> All the Best
> Dave

https://developer.apple.com/reference/objectivec/1418956-nsobject?language=objc 


release - Decrements the receiver’s reference count.

Language - Objective-C

Declaration

- (oneway void)release;

Discussion

The receiver is sent a dealloc message when its reference count reaches 0.

You would only implement this method to define your own reference-counting 
scheme. Such implementations should not invoke the inherited method; that is, 
they should not include a release message to super.
___

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: Swift: Draw a circle with tic marks at it's edge?

[Doug Hill]

Hello Eric,

There's a number of ways to approach this problem.

If you want to render this at runtime yourself, you'll need to learn Core 
Graphics and figure out how to create paths (e.g. arcs and lines). I'll have to 
leave it to a Google search or Apple docs for you to figure this out. It's 
actually pretty easy to do, so check your graphics context, coordinates, and 
the path, fill, and background colors.

Another approach is to render the individual frames of each state ahead of time 
and use those at runtime. For example, it there were only 10 positions on your 
knob you could render these positions separately in e.g. Photoshop and when the 
gesture recognizer sends an event that the user did a rotate gesture, you 
update an image view with a different pre rendered image.
There might also be a way to render one frame of the dial (e.g. the 'Ø' 
position) and apply a rotate transform. This is dependent on the design you 
have whether it could be rotated and still look good.

Good luck!

Doug Hill

> On Jan 18, 2017, at 12:34 PM, Eric E. Dolecki <edole...@gmail.com> wrote:
> 
> [image: Screen Shot 2017-01-18 at 3.28.22 PM.png]
> 
> I have been tasked to create a control. A giant knob that is ticked along
> its edge (the number dependent on the minimum & maximum values). Not 360
> degrees, just enough ticks to show the range. It will do other things as
> well, but I'm wondering how to approach this. The values will always be
> Int.
> 
> I have included a screenshot. The longer dark tick will always show the
> current value. I didn't want to paste a lot of code in here, but I tried
> UIBezierPaths and my code only produced a black background. Would this be a
> ShapeLayer with another sublayer for the ticks? I'll be using
> UIGestureRecognizer to control the rotation of the "dial"...
> 
> 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/archive%40mail-archive.com

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

Re: How does chromium simulate keyboard events using CGEventPost in pre login agent?

[Doug Hill]

It’s possible “untrusted” means not code-signed.


> On Jan 4, 2017, at 11:36 PM, Sai Prasanna  wrote:
> 
> I have created a pre-login agent which uses CGEventPost for simulating
> keyboard. FYI I am developing a remote control app similar to teamviewer.
> 
> Keyboard (I tried other event sources too)
> 
> CGEventRef keyEvent = CGEventCreateKeyboardEvent( NULL, keyCode, down ) ;
> CGEventPost( kCGHIDEventTap, keyEvent ) ;
> CFRelease( keyEvent ) ;
> 
> Mouse
> 
> CGEventRef event = CGEventCreateMouseEvent(eventSource, eventType,
> mouseLocation, mouseButton );
> CGEventPost(kCGHIDEventTap, event);
> CFRelease(event);
> 
> Pre-login launch agent
> 
> 
>  "http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
> 
> 
>Label
>my app label
>LimitLoadToSessionType
>LoginWindow
>RunAtLoad
>
>WorkingDirectory
>My app directory
>ProgramArguments
>
>app absolute path
>service
>myservice
>
>KeepAlive
>
> 
> 
> 
> CGEventPost is not working, I get the following in the Console logs after
> login
> 
> Untrusted apps are not allowed to connect to
> Window Server before login.
> 
> I have searched o chromium's remote control (which has keyboard and mouse
> simulation working) source code. They use CGEventPost for keyboard, but it
> works in login window.
> 
> https://cs.chromium.org/chromium/src/remoting/host/
> input_injector_mac.cc?rcl=0=42
> 
> They seem to use a sh file in privileged helper tools directory and use to
> to load the service, I tried putting our service in privileged helpers
> tool, but still the event handling fails.
> 
> The Deprecated API CGPostMouseEvent, CGPostKeyBoardEvent work without
> problem , but would really like to know how non deprecated keyboard API
> works in chromium.


___

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: 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 <david.dun...@apple.com> wrote:
> 
>> 
>> On Dec 30, 2016, at 11:50 AM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> 
>>> On Dec 30, 2016, at 11:38 AM, David Duncan <david.dun...@apple.com> wrote:
>>> 
>>> 
>>>> On Dec 28, 2016, at 4:14 PM, Doug Hill <cocoa...@breaqz.com> 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: Animating autolayout constraint changes for subviews

[Doug Hill]

> On Dec 30, 2016, at 11:56 AM, David Duncan <david.dun...@apple.com> wrote:
> 
> 
>> On Dec 30, 2016, at 11:50 AM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> 
>>> On Dec 30, 2016, at 11:38 AM, David Duncan <david.dun...@apple.com> wrote:
>>> 
>>> 
>>>> On Dec 28, 2016, at 4:14 PM, Doug Hill <cocoa...@breaqz.com> 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.

Right, “animatable” in the sense that I won’t need to do a snapshot trick.

Working on the snapshotting now, appreciate the tips.

Doug Hill


___

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: Animating autolayout constraint changes for subviews

[Doug Hill]

> On Dec 30, 2016, at 11:38 AM, David Duncan <david.dun...@apple.com> wrote:
> 
> 
>> On Dec 28, 2016, at 4:14 PM, Doug Hill <cocoa...@breaqz.com> 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.

Doug Hill
___

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: Animating autolayout constraint changes for subviews

[Doug Hill]

Hello Steve,

FWIW, I’ve tried both ways and it doesn’t seem to affect the problem I’m 
having. However, Apple says to update constraints than do the animation block 
with layoutIfNeeded, according to this WWDC session:

https://developer.apple.com/videos/play/wwdc2012/228/?id=228 
<https://developer.apple.com/devcenter/download.action?path=/videos/wwdc_2012__sd/session_228__best_practices_for_mastering_auto_layout.mov>

But in general, the SDK documentation on animating autolayout constraint 
changes is borderline non-existent. 

Doug Hill


> On Dec 28, 2016, at 5:54 PM, Steve Christensen <puns...@mac.com> wrote:
> 
> I have always put the thing that I'm animating into the animation block:
> 
> - (IBAction)animateIt:(id)sender
> {
>   static BOOL small = NO;
> 
>   small = !small;
> 
>   CGFloat newWidth = small ? self.view.frame.size.width / 2 : 
> self.view.frame.size.width;
> 
>   [UIView animateWithDuration:1 animations:
>   ^{
>   self.containerWidthConstraint.constant = newWidth;
>   [self.view layoutIfNeeded];
>   }];
> }
> 
>> On Dec 28, 2016, at 4:14 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> Hi Ken,
>> 
>> I uploaded a sample project here:
>> 
>> https://github.com/djfitz/TestAutolayoutAnimations
>> 
>> I tried to strip this down to what is needed to show the behavior I see.
>> 
>> My code to actually do the animation is this:
>> 
>> - (IBAction)animateIt:(id)sender
>> {
>>  static BOOL small = NO;
>> 
>>  if( small )
>>  {
>>  [self.view layoutIfNeeded];
>> 
>>  self.containerWidthConstraint.constant = 
>> self.view.frame.size.width;
>> 
>>  [UIView animateWithDuration:1 animations:
>>  ^{
>>  [self.view layoutIfNeeded];
>>  }];
>>  }
>>  else
>>  {
>>  [self.view layoutIfNeeded];
>> 
>>  self.containerWidthConstraint.constant = 
>> self.view.frame.size.width / 2;
>> 
>>  [UIView animateWithDuration:1 animations:
>>  ^{
>>  [self.view layoutIfNeeded];
>>  }];
>>  }
>> 
>>  small = !small;
>> }
>> 
>> 'container view' has one subview which is a UILabel. The label is pinned to 
>> the superview edges via autolayout constraints. (e.g. trailing, leading, 
>> top, bottom edges all pinned to superview edges.)
>> 
>> I tried a few different variations, including leaving out the first 
>> layoutIfNeeded (which some people say should be done, others not).
>> 
>> 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.
>> 
>> Thanks again for any ideas.
>> 
>> Doug Hill
>> 
>> 
>>> On Dec 28, 2016, at 12:50 PM, Ken Thomases <k...@codeweavers.com> wrote:
>>> 
>>> On Dec 28, 2016, at 1:55 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>>>> 
>>>> I can now animate my constraint changes but I notice that subviews aren't 
>>>> animated. For example, I have a single view with a width constraint, and 
>>>> this view has a label as a subview that expands to the size of it's parent 
>>>> view via edge constraints.
>>>> I can change the width constraint constant of the parent view at runtime 
>>>> and it animates very well. However, the subviews jump into place 
>>>> immediately then the parent view animates into place. I see the same 
>>>> behavior with a button as a subview.
>>> 
>>> Show exactly how you're animating the constraint changes.  Are you really 
>>> animating the change of the constraint or are you doing a layoutIfNeeded 
>>> within an animation context?  Even if the former, are you calling any 
>>> methods that force layout (layoutIfNeeded or similar)?  If so, where/when?
>>> 
>>> Regards,
>>> Ken
> 

___

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: Animating autolayout constraint changes for subviews

[Doug Hill]

Hi Ken,

I uploaded a sample project here:

https://github.com/djfitz/TestAutolayoutAnimations

I tried to strip this down to what is needed to show the behavior I see.

My code to actually do the animation is this:

- (IBAction)animateIt:(id)sender
{
static BOOL small = NO;

if( small )
{
[self.view layoutIfNeeded];

self.containerWidthConstraint.constant = 
self.view.frame.size.width;

[UIView animateWithDuration:1 animations:
^{
[self.view layoutIfNeeded];
}];
}
else
{
[self.view layoutIfNeeded];

self.containerWidthConstraint.constant = 
self.view.frame.size.width / 2;

[UIView animateWithDuration:1 animations:
^{
[self.view layoutIfNeeded];
}];
}

small = !small;
}

'container view' has one subview which is a UILabel. The label is pinned to the 
superview edges via autolayout constraints. (e.g. trailing, leading, top, 
bottom edges all pinned to superview edges.)

I tried a few different variations, including leaving out the first 
layoutIfNeeded (which some people say should be done, others not).

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.

Thanks again for any ideas.

Doug Hill


> On Dec 28, 2016, at 12:50 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 
> On Dec 28, 2016, at 1:55 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> I can now animate my constraint changes but I notice that subviews aren't 
>> animated. For example, I have a single view with a width constraint, and 
>> this view has a label as a subview that expands to the size of it's parent 
>> view via edge constraints.
>> I can change the width constraint constant of the parent view at runtime and 
>> it animates very well. However, the subviews jump into place immediately 
>> then the parent view animates into place. I see the same behavior with a 
>> button as a subview.
> 
> Show exactly how you're animating the constraint changes.  Are you really 
> animating the change of the constraint or are you doing a layoutIfNeeded 
> within an animation context?  Even if the former, are you calling any methods 
> that force layout (layoutIfNeeded or similar)?  If so, where/when?
> 
> Regards,
> Ken
> 


___

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

Animating autolayout constraint changes for subviews

[Doug Hill]

I had a previous question to the list about animating autolayout constraint 
changes at runtime. The documentation on this is a little thin and was grateful 
for the list's suggestions on the correct way to do this.

I can now animate my constraint changes but I notice that subviews aren't 
animated. For example, I have a single view with a width constraint, and this 
view has a label as a subview that expands to the size of it's parent view via 
edge constraints.
I can change the width constraint constant of the parent view at runtime and it 
animates very well. However, the subviews jump into place immediately then the 
parent view animates into place. I see the same behavior with a button as a 
subview.

Doing a Google search I see examples of other people running into this same 
problem but don't find a good solution. For example, I see people animating the 
subview themselves via a timer.

http://stackoverflow.com/questions/20097580/autolayout-animate-constraint-does-not-animate-subviews#32891810

This doesn't look like a very good solution to me since it would be almost 
impossible to match that same animation of the parent view.

Before I go too much further, I'm looking to see if there are better solutions 
out there, other other pointers to documentation about this.

Thanks.

Doug Hill
___

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

[Doug Hill]

Great, more good stuff to know!

However, trying this out I see that some views animate and others don't (just 
jump into place). I guess I'll look into a more animatable design.

Doug Hill

> On Dec 14, 2016, at 3:24 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 
> On Dec 14, 2016, at 5:15 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> Ok, this is more good information to keep in mind when designing autolayout 
>> constraints. Given that my design isn't animatable, it's back to the 
>> autolayout drawing board. Again.
> 
> I think it works to animate a change of constraints if you do the 
> -layoutIfNeeded on the window within the animation context.  It's technically 
> animating the frame changes rather than the constraints, which can transition 
> through some different states and even temporarily violate constraints, but 
> for this case it should work.
> 
> Regards,
> Ken
> 


___

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

[Doug Hill]

Ok, this is more good information to keep in mind when designing autolayout 
constraints. Given that my design isn't animatable, it's back to the autolayout 
drawing board. Again.

Doug Hill


> On Dec 14, 2016, at 3:07 PM, Gary L. Wade <garyw...@desisoftsystems.com> 
> wrote:
> 
> Right, activate and deactivate are not animatable, but the constant values in 
> constraints are.
> 
> True, it depends on what you’re showing as to whether to shrink or move your 
> view.  When I wanted to use a search bar in UISearchController with a 
> collection view in iOS to appear similarly as UITableView, I moved the search 
> bar:
> 
> https://whatweretheythinkingblog.wordpress.com/2016/11/19/effectively-using-uisearchcontroller-with-uicollectionview/
>  
> <https://whatweretheythinkingblog.wordpress.com/2016/11/19/effectively-using-uisearchcontroller-with-uicollectionview/>
> 
> When I wanted to show an icon to the left of a title, where the item may not 
> have an icon but was only available through a REST call, I found it more 
> attractive to grow the icon and compress the title in that animation, 
> choosing a scale-to-fill option, when I determined there was an icon.
> --
> Gary L. Wade
> http://www.garywade.com/ <http://www.garywade.com/>
>> On Dec 14, 2016, at 2:52 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Gary,
>> 
>> Thanks for the reply.
>> I tried moving the container rather than resizing to 0 because there's a 
>> table inside this view and it will relayout when resizing. For an animation, 
>> I guess it depends on what effect you want: either seeing the view move or 
>> resize to 0.
>> 
>> Oddly, when I put my code to activate/deactivate constraints inside a 
>> [UIView animateWithDuration…] I get no animation. :(
>> 
>> Doug Hill
>> 
>>> On Dec 14, 2016, at 2:49 PM, Gary L. Wade <garyw...@desisoftsystems.com 
>>> <mailto:garyw...@desisoftsystems.com>> wrote:
>>> 
>>> If I understand you correctly, you might prefer the approach I chose to do. 
>>>  Rather than activating and deactivating constraints (BTW, you should 
>>> always deactivate before having multiple actives), set your constraints up 
>>> to always be active but change the width for the one you’re hiding to 0 and 
>>> the other to be the extra size needed to fill the gap.  I also chose to 
>>> animate the constant values, so the size-change is smooth to the user.
>>> --
>>> Gary L. Wade
>>> http://www.garywade.com/ <http://www.garywade.com/>
>>>> On Dec 14, 2016, at 2:19 PM, Doug Hill <cocoa...@breaqz.com 
>>>> <mailto:cocoa...@breaqz.com>> wrote:
>>>> 
>>>> I'm seeing warnings in the console when I dynamically make autolayout 
>>>> constraints active/inactive at runtime.
>>>> 
>>>> I have two constraints that align a container view leading or trailing 
>>>> edge with another view's edge. This is to move the container onscreen or 
>>>> offscreen. I have another view whose trailing edge aligns with the leading 
>>>> edge of the first container view so it moves with it as autolayout 
>>>> constraints change.
>>>> 
>>>> At runtime, I make one of these constraints active and the other inactive, 
>>>> like so:
>>>> 
>>>> - (IBAction)toggleCommentsVisibility:(id)sender
>>>> {
>>>>self.commentsAreHidden ? [self showComments:self] : [self 
>>>> hideComments:self]; 
>>>> }
>>>> 
>>>> - (IBAction)showComments:(id)sender
>>>> {
>>>>self.showCommentsConstraint.active = YES;
>>>>self.hideCommentsContainerConstraint.active = NO;
>>>> 
>>>>self.commentsAreHidden = NO;
>>>> }
>>>> 
>>>> - (IBAction)hideComments:(id)sender
>>>> {
>>>>self.showCommentsConstraint.active = NO;
>>>>self.hideCommentsContainerConstraint.active = YES;
>>>> 
>>>>self.commentsAreHidden = YES;
>>>> }
>>>> 
>>>> When I call showComments, I get the following warning in the console:
>>>> 
>>>> =
>>>> 
>>>> Unable to simultaneously satisfy constraints.
>>>> Probably at least one of the constraints in the following list is one you 
>>>> don't want. 
>>>> Try this: 
>>>>(1) look at each constraint and try to figure out which you don't 
>>>&

Re: Autolayout warnings

[Doug Hill]

Gary,

Thanks for the reply.
I tried moving the container rather than resizing to 0 because there's a table 
inside this view and it will relayout when resizing. For an animation, I guess 
it depends on what effect you want: either seeing the view move or resize to 0.

Oddly, when I put my code to activate/deactivate constraints inside a [UIView 
animateWithDuration…] I get no animation. :(

Doug Hill

> On Dec 14, 2016, at 2:49 PM, Gary L. Wade <garyw...@desisoftsystems.com> 
> wrote:
> 
> If I understand you correctly, you might prefer the approach I chose to do.  
> Rather than activating and deactivating constraints (BTW, you should always 
> deactivate before having multiple actives), set your constraints up to always 
> be active but change the width for the one you’re hiding to 0 and the other 
> to be the extra size needed to fill the gap.  I also chose to animate the 
> constant values, so the size-change is smooth to the user.
> --
> Gary L. Wade
> http://www.garywade.com/ <http://www.garywade.com/>
>> On Dec 14, 2016, at 2:19 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> I'm seeing warnings in the console when I dynamically make autolayout 
>> constraints active/inactive at runtime.
>> 
>> I have two constraints that align a container view leading or trailing edge 
>> with another view's edge. This is to move the container onscreen or 
>> offscreen. I have another view whose trailing edge aligns with the leading 
>> edge of the first container view so it moves with it as autolayout 
>> constraints change.
>> 
>> At runtime, I make one of these constraints active and the other inactive, 
>> like so:
>> 
>> - (IBAction)toggleCommentsVisibility:(id)sender
>> {
>>  self.commentsAreHidden ? [self showComments:self] : [self 
>> hideComments:self]; 
>> }
>> 
>> - (IBAction)showComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = YES;
>>  self.hideCommentsContainerConstraint.active = NO;
>> 
>>  self.commentsAreHidden = NO;
>> }
>> 
>> - (IBAction)hideComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = NO;
>>  self.hideCommentsContainerConstraint.active = YES;
>> 
>>  self.commentsAreHidden = YES;
>> }
>> 
>> When I call showComments, I get the following warning in the console:
>> 
>> =
>> 
>> Unable to simultaneously satisfy constraints.
>> Probably at least one of the constraints in the following list is one you 
>> don't want. 
>> Try this: 
>>  (1) look at each constraint and try to figure out which you don't 
>> expect; 
>>  (2) find the code that added the unwanted constraint or constraints and 
>> fix it. 
>> (
>>"> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>"> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>"> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>"> H:[UIView:0x7f91426def30(768)]>"
>> )
>> 
>> Will attempt to recover by breaking constraint 
>> > H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
>> 
>> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
>> catch this in the debugger.
>> 
>> =
>> 
>> This is puzzling because IB doesn't give me any autolayout errors/warning 
>> when I manually activate/deactivate these constraints. Also, I don't get 
>> this runtime warning when calling hideComments, only the 'show' case. 
>> Finally, things actually work at runtime because it's nice enough to "break" 
>> the constraint that I deactivated in code. But I would like to not have 
>> these warnings.
>> 
>> Any ideas on what's going on how I might go about debugging this?
>> 
>> Doug Hill
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com 
>> <mailto:Cocoa-dev@lists.apple.com>)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com 
>> <http://lists.apple.com/>
>> 
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/garywade%40desisoftsystems.com
>>  
>> <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: Autolayout warnings

[Doug Hill]

> On Dec 14, 2016, at 2:46 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 
> On Dec 14, 2016, at 4:19 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> I'm seeing warnings in the console when I dynamically make autolayout 
>> constraints active/inactive at runtime.
>> 
>> I have two constraints that align a container view leading or trailing edge 
>> with another view's edge. This is to move the container onscreen or 
>> offscreen. I have another view whose trailing edge aligns with the leading 
>> edge of the first container view so it moves with it as autolayout 
>> constraints change.
>> 
>> At runtime, I make one of these constraints active and the other inactive, 
>> like so:
> 
>> - (IBAction)showComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = YES;
>>  self.hideCommentsContainerConstraint.active = NO;
> 
> Swap the order of these.  Always disable no-longer-applicable constraints 
> before enabling newly-applicable constraints.  The way you have it here, 
> after the first line, you temporarily have constraints which conflict 
> enabled.  You fix that with the next line, but you've already gotten the 
> warning by then.

Ding-Ding-Ding-Ding-Ding-Ding! We have a winner!

I went ahead and made this change and warnings are gone. Will keep the order of 
activation in mind for future coding.

Doug Hill
___

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

[Doug Hill]

Quincey,

Thanks for the reply.

> On Dec 14, 2016, at 2:40 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Dec 14, 2016, at 14:19 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>>"> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>"> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>"> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>"> H:[UIView:0x7f91426def30(768)]>"
> 
> It kinda looks like the conflict is between the first and last of these. When 
> you move the comments view off to the trailing edge of what it’s aligned to, 
> you seem to be making the enclosing view wider according to some combination 
> of constraints, which violates the constraint (the last one) saying that the 
> enclosing view is 768 pts wide.

The funky  UIView-Encapsulated-Layout-Width constraint is not mine and I don't 
set it to 768. Not sure what it is.

> Can you set the comment view to 0 width when you hide it? That would probably 
> eliminate the problem, although a different approach might be preferable. 
> (For example, use conditional constraints on the view that expands to fill 
> the space occupied by the comment view, relative to the enclosing view, and 
> hide the comment view instead of moving it.)

I actually put a lot of time into trying to figure out how to architect the 
autolayout constraints to make everything move together using. This scheme 
seems good because, by not shrinking the container (which has a table view 
inside), it doesn't cause the table to relayout. But I'll try some of your 
techniques too.

Doug Hill
___

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

Autolayout warnings

[Doug Hill]

I'm seeing warnings in the console when I dynamically make autolayout 
constraints active/inactive at runtime.

I have two constraints that align a container view leading or trailing edge 
with another view's edge. This is to move the container onscreen or offscreen. 
I have another view whose trailing edge aligns with the leading edge of the 
first container view so it moves with it as autolayout constraints change.

At runtime, I make one of these constraints active and the other inactive, like 
so:

- (IBAction)toggleCommentsVisibility:(id)sender
{
self.commentsAreHidden ? [self showComments:self] : [self 
hideComments:self]; 
}

- (IBAction)showComments:(id)sender
{
self.showCommentsConstraint.active = YES;
self.hideCommentsContainerConstraint.active = NO;

self.commentsAreHidden = NO;
}

- (IBAction)hideComments:(id)sender
{
self.showCommentsConstraint.active = NO;
self.hideCommentsContainerConstraint.active = YES;

self.commentsAreHidden = YES;
}

When I call showComments, I get the following warning in the console:

=

Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't 
want. 
Try this: 
(1) look at each constraint and try to figure out which you don't 
expect; 
(2) find the code that added the unwanted constraint or constraints and 
fix it. 
(
"",
"",
"",
""
)

Will attempt to recover by breaking constraint 


Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch 
this in the debugger.

=

This is puzzling because IB doesn't give me any autolayout errors/warning when 
I manually activate/deactivate these constraints. Also, I don't get this 
runtime warning when calling hideComments, only the 'show' case. Finally, 
things actually work at runtime because it's nice enough to "break" the 
constraint that I deactivated in code. But I would like to not have these 
warnings.

Any ideas on what's going on how I might go about debugging this?

Doug Hill
___

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: iOS 9: Adding CALayer to self.view.layer causes EXC_BAD_ACCESS

[Doug Hill]

I've wondered about this before, but maybe some Objective-C runtime experts 
know.

Does writing directly to the ivar backing a property bypass the ARC features of 
the property. For example, will a strong property be retained if you write 
directly to the ivar?

If not, that's your problem.

Doug

> On Dec 6, 2016, at 11:44 AM, Carl Hoefs  
> wrote:
> 
> I get the following crash in my iOS 9 app simply by adding a CALayer to the 
> current view controller's self.view.layer and then dismissing the current 
> view controller. Simplified code:
> 
>@property (strong,nonatomic) CALayer *layer;
>.  .  .
>_layer = [[CALayer alloc] init];
>[_layer setDelegate: self];
>[self.view.layer addSublayer:_layer];
> 
> Upon dismissing the VC:
> 
>[self dismissViewControllerAnimated:YES completion:nil];
> 
> The following exception occurs:
> 
> (lldb) bt
> * thread #1: tid = 0x121bd, 0x22c2c68a libobjc.A.dylib`objc_retain + 10, 
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
> address=0xb010)
>frame #0: 0x22c2c68a libobjc.A.dylib`objc_retain + 10
>frame #1: 0x27a2a22a UIKit`-[UIView(Hierarchy) subviews] + 330
>frame #2: 0x27b3e1ea UIKit`discardEngineRecursive + 118
>frame #3: 0x27a2fd06 UIKit`-[UIView dealloc] + 630
>frame #4: 0x2336cd98 CoreFoundation`-[__NSDictionaryM dealloc] + 132
>frame #5: 0x22c2cf8a libobjc.A.dylib`objc_object::sidetable_release(bool) 
> + 150
>frame #6: 0x22c2d3cc libobjc.A.dylib`(anonymous 
> namespace)::AutoreleasePoolPage::pop(void*) + 388
>frame #7: 0x23363f30 CoreFoundation`_CFAutoreleasePoolPop + 16
>frame #8: 0x23415c56 CoreFoundation`__CFRunLoopRun + 1598
>frame #9: 0x233641c8 CoreFoundation`CFRunLoopRunSpecific + 516
>frame #10: 0x23363fbc CoreFoundation`CFRunLoopRunInMode + 108
>frame #11: 0x24980af8 GraphicsServices`GSEventRunModal + 160
>frame #12: 0x27a9c434 UIKit`UIApplicationMain + 144
>  * frame #13: 0x001b655e ProteinFold`main(argc=1, argv=0x0043bbc8) + 122 at 
> main.m:14
> 
> If I remove the CALayer first before the 
> -dismissViewControllerAnimated:completion:, it doesn't crash:
> 
>[layer removeFromSuperlayer];
> 
> Why do I need to explicitly remove my added CALayer before dismissing the VC? 
> Note: If I declare layer as weak, the crash does not occur, but neither does 
> the layer display onscreen.
> -Carl
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/cocoadev%40breaqz.com
> 
> This email sent to cocoa...@breaqz.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: Vertically Centered Colon

[Doug Hill]

> On Dec 1, 2016, at 11:20 AM, Alastair Houghton <alast...@alastairs-place.net> 
> wrote:
> 
> On 1 Dec 2016, at 19:05, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> Just made another breakthrough. I finally figured out why we have the 
>> vertically centerd colon (I’ll now call it VCC) by default but has 
>> requirements of numbers on either side of the colon.
>> The SF font setting is “Contextual Alternatives” (I’ll now call it CA). When 
>> CA is on, it will use the logic of numbers on either side of a colon to get 
>> VCC. Turning off CA turns off this logic and no VCC. But even if CA is on, 
>> and you have a character stream that isn’t :, you can turn 
>> on VCC explicitly with it’s own selector to get that behavior.
>> 
>> Other than VCC I’m not sure what other contextual alternatives there are. 
>> Fractions didn’t seem to do anything differently.
> 
> I think we’ve headed off topic somewhat, so this is likely my final word on 
> the subject.  Contextual alternates’ usual abbreviation is “calt” (which is 
> its OpenType tag).  It might also, at this point, be worth pointing you at 
> the OpenType specification
> 
>  https://www.microsoft.com/en-us/Typography/OpenTypeSpecification.aspx
> 
> and in particular the registered features page:
> 
>  https://www.microsoft.com/typography/otspec/featurelist.htm
> 
> The pages on advanced layout may also be informative.

Thanks for the info!

At this point, I think we figured out the original VCC bug, and I was able to 
document a number of SF font features and how to easily use them. I hope this 
has some value to the developer community; at the very least Google searches 
will now bring up info about these features.
Going forward, I personally hope I don’t have to do a deep dive into the 
OpenType spec everytime I want to use cool features of San Francisco. ;)

Thanks again everyone.

Doug Hil
___

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: Vertically Centered Colon

[Doug Hill]

> On Dec 1, 2016, at 8:17 AM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
>> On Dec 1, 2016, at 12:58 AM, Alastair Houghton 
>> <alast...@alastairs-place.net> wrote:
>> 
>> Agreed.  At the very least it needs to explicitly document the set of 
>> stylistic alternates for the SF font family so that we know what they all do 
>> (it looks like there might be more than in your document too; I can’t think 
>> of a reason for using one, two, three and then seven without also using 
>> four, five and six).
> 
> Alastair,
> 
> At the time I wrote that document, I only had time to figure out a few of the 
> selectors. I have since found out #6 (“High Legibility”). According to the 
> Mac Font Panel, #4 is “Stylistic Set 4”, whatever that is. #5 appears to do 
> nothing, AFAICT.

Just made another breakthrough. I finally figured out why we have the 
vertically centerd colon (I’ll now call it VCC) by default but has requirements 
of numbers on either side of the colon.
The SF font setting is “Contextual Alternatives” (I’ll now call it CA). When CA 
is on, it will use the logic of numbers on either side of a colon to get VCC. 
Turning off CA turns off this logic and no VCC. But even if CA is on, and you 
have a character stream that isn’t :, you can turn on VCC 
explicitly with it’s own selector to get that behavior.

Other than VCC I’m not sure what other contextual alternatives there are. 
Fractions didn’t seem to do anything differently.

Also, when Apple says VCC is on by default in the SDKs, I think they mean CA is 
on by default.

Anyways, this selector is in my SF Font code here:

https://github.com/djfitz/SFFontFeatures 
<https://github.com/djfitz/SFFontFeatures>

Doug Hill
___

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: Vertically Centered Colon

[Doug Hill]

> On Dec 1, 2016, at 8:07 AM, Alastair Houghton <alast...@alastairs-place.net> 
> wrote:
> 
> On 1 Dec 2016, at 15:57, Alex Zavatone <z...@mac.com> wrote:
>> 
>> If we are able to do it right, then we don't have to worry about waiting for 
>> it or aren't put behind an 8 ball if Apple decides to pull the rug out from 
>> under us if it decides to change the feature (which happens).
>> 
>> With these features in text styling, we have all the metrics that we need 
>> and as long as the font we want to use supports what we want, these features 
>> can be implemented without waiting for someone else to do it for us.
> 
> Up to a point.  Sometimes there is special support in a font for some 
> particular feature, which will provide better results than naïvely moving or 
> scaling a glyph.  A case in point is small caps; you can simulate small caps 
> by using capitals from a smaller point size, but doing so will affect the 
> weight of the strokes.  Dedicated small caps support tends to look a lot 
> better — the stroke weight will match, but also sometimes changes are made to 
> the glyphs to better fit into the available space and/or to better align with 
> other characters in the font.
> 
> Vertically centring a colon is towards the simpler end of things and should 
> be doable “by hand”, though there might still be gotchas with some fonts 
> (e.g. where digits are not the same height as capital letters or where “old 
> style” digits are in use).

Indeed, while knowing how to achieve typographic effects on any font can be 
very desirable, the system font is a very special case. Apple has tried to 
bring these typographic affects to a wider developer audience by including them 
in the font itself, and has actively encouraged developers to use these 
features. While the usage is a bit clunky right now due to primitive 
interfaces, I believe it will get easier with time. Additionally, as mentioned, 
the quality of the typographic effects should be quite good, as mentioned 
above. For example, the setting for “High Legibility” encompasses a lot of 
features (change many glyph forms, change tracking, etc.) that probably would 
be a pain to achive manually. Also, Apple did a lot of research into what makes 
things more legible and will probably improve this in the future.

With so many easy to use features available, Apple has done the developer 
community a big favor. My guess is that these features will be supported for 
some time, as they are used by many Apple apps, and Apple has publicly 
encouraged developers to use them as well.

Doug Hill




___

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: Vertically Centered Colon

[Doug Hill]

> On Dec 1, 2016, at 12:58 AM, Alastair Houghton <alast...@alastairs-place.net> 
> wrote:
> 
> On 30 Nov 2016, at 18:33, Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Still hoping Apple will make SF font specific features part of the SDK.
> 
> Agreed.  At the very least it needs to explicitly document the set of 
> stylistic alternates for the SF font family so that we know what they all do 
> (it looks like there might be more than in your document too; I can’t think 
> of a reason for using one, two, three and then seven without also using four, 
> five and six).

Alastair,

At the time I wrote that document, I only had time to figure out a few of the 
selectors. I have since found out #6 (“High Legibility”). According to the Mac 
Font Panel, #4 is “Stylistic Set 4”, whatever that is. #5 appears to do 
nothing, AFAICT.

Also, I finally got time to collect the work I’ve done and make a convenience 
class to use these San Francisco font features. See here:

https://github.com/djfitz/SFFontFeatures 
<https://github.com/djfitz/SFFontFeatures>

I can’t guarantee that anything will work, or if there are other features I’m 
missing. For now, I have support for 11 features:

• Straight-sided six and nine
• Open Four
• Vertically centered colon
• High Legibility
• One Storey a
• Upper Case Small Capitals
• Lower Case Small Capitals
• Contextual Fractional Forms
• Monospaced/Proportional Numbers
• Superiors/Superscripts
• Inferiors/Subscripts

Feel free to try this out, and let me know if things work for you.

Doug Hill
___

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: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 11:06 PM, Alex Zavatone <z...@mac.com> wrote:
> 
> 
> On Nov 30, 2016, at 12:10 AM, Doug Hill wrote:
> 
>> After some trial and error, I figured out how to accomplish the San 
>> Francisco font features described below. I updated my document to include 
>> the code to turn on each feature.
>> 
>> http://breaqz.com/font/AlternateStylisticForms.pdf 
>> <http://breaqz.com/font/AlternateStylisticForms.pdf>
>> 
>> I should make a sample app or blog post but time doesn’t permit at the 
>> moment. Hope this all helps!
>> 
>> Doug Hill
> 
> This doc might help
> https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html
>  
> <https://developer.apple.com/fonts/TrueType-Reference-Manual/RM09/AppendixF.html>

A lot of good stuff there. It appears to be some documentation for what's in 
SFNTLayoutTypes.h which is helpful.
However, all the alternate stylistic forms are still numbered selectors so not 
a lot of new information.

Still hoping Apple will make SF font specific features part of the SDK.

Doug
___

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: Vertically Centered Colon

[Doug Hill]

After some trial and error, I figured out how to accomplish the San Francisco 
font features described below. I updated my document to include the code to 
turn on each feature.

http://breaqz.com/font/AlternateStylisticForms.pdf

 I should make a sample app or blog post but time doesn’t permit at the moment. 
Hope this all helps!

Doug Hill


> On Nov 29, 2016, at 9:38 AM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> I suppose if I have some time I’ll try them out and see if I can do my own 
> documentation. For reference, here are a few different forms that I was able 
> to create with TextEdit:
> 
> http://breaqz.com/font/AlternateStylisticForms.pdf
> 
> This includes examples of the following:
> 
> • Vertically centered colon
> • Straight-sided six and nine
> • Open Four
> • One storev a (e.g. alternate lowercase ‘a’ form)
> • Small Capitals
> • Contextual Fractional Forms (fractional form for any fraction)


___

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: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 3:58 PM, Rick Mann <rm...@latencyzero.com> wrote:
> 
> 
>> On Nov 29, 2016, at 09:38 , Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> Wow, it's awesome that this works! And now that I know how to set these 
>> attributes for a UILabel, I might try using some other features of SF font, 
>> such as contextual fractional forms for any fraction.
> 
> Oh, wow, contextual fractional forms! This is *perfect* for the app I'm 
> working on currently.
> 
> I'm late to this thread. Does this stuff only work for attributed strings?

I believe you can use [UIFont fontWithDescriptor:size] with a non-attributed 
string but if you want to mix font styles in a single string, then you need 
attributed.

> Do I apply the alternate form attribute to the string "99/100" in order to 
> get the fractional form?

It would appear that you need to apply this style to a character sequence of: a 
multi-digit number followed by a ‘/‘ then another multi-digit number.

Good luck!

Doug
___

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: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 10:04 AM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Nov 29, 2016, at 09:38 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> But seriously, why didn’t Apple document what those stylistic alernative 
>> type attribute constants are? Are they supposed to change? Did they not know 
>> what they correspond to when creating the header? Did they not expect that 
>> developers would use this feature?
> 
> My guess is because there aren’t any definitions, but these are instead 
> optional font-specific features with generic identifications. And, lo and 
> behold, when I went to check on this:
> 
>   
> en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features
>  
> <http://en.wikipedia.org/wiki/List_of_typographic_features#OpenType_typographic_features>
> 
> there they are [well, I presume this is them] under the heading “Ligation and 
> alternate forms features intended for all scripts” as “Stylistic Set 1 – 20”. 
> Indeed, if you look at the example of Stylistic Set 04 here:
> 
>   ilovetypography.com/OpenType/opentype-features.html 
> <http://ilovetypography.com/OpenType/opentype-features.html>
> 
> it even looks like the meaning of the set is somehow defined within the font.
> 
> (Note that there appear to be “stylistic alternates”, and “stylistic sets” 
> which are a specific kind of stylistic alternate, so the whole system seems 
> more complicated than I was able to grasp in 5 minutes of searching.)
> 
> I’m ready to stand corrected, but — unless there’s a separate registry or 
> convention on what the sets mean — this appears to me to indicate that the 
> centered colon may only work for SF and perhaps a set of other Apple-tweaked 
> fonts that are intended to have the same behavior.

Indeed many of these features are likely SF font specific. However, these 
features are known to Apple’s developers. For example, check out the Typography 
settings of a font in the Macintosh Font Panel. It knows which features are 
available for any font and shows their name when switching fonts. So the 
mapping between OpenType setting and SF font feature is known somewhere, but 
not to SDK users.

But thanks for the links, very good info which I don’t understand all of it 
either. You can go down this font rat-hole as far as you want; I don’t think it 
ever ends. :)

Doug
___

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: Vertically Centered Colon

[Doug Hill]

> On Nov 29, 2016, at 1:33 AM, Gerriet M. Denkmann <gerri...@icloud.com> wrote:
> 
>> On 29 Nov 2016, at 03:33, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> A little experimentation might find the right one.

> 
> A “little” is kind of misleading. There are about 40 features, with up to 20 
> alternatives each.
> 
> …
> After you kindly mentioned kStylisticAlternativesType I started to try this. 
> The documentation is quite helpful in mentioning that some flag “Turns the 
> nth set of alternates on or off” for n = 1 … 20.
> 
> And luckily kStylisticAltThreeOnSelector does indeed turn centred colons on.

Wow, it's awesome that this works! And now that I know how to set these 
attributes for a UILabel, I might try using some other features of SF font, 
such as contextual fractional forms for any fraction.

But seriously, why didn’t Apple document what those stylistic alernative type 
attribute constants are? Are they supposed to change? Did they not know what 
they correspond to when creating the header? Did they not expect that 
developers would use this feature?
I suppose if I have some time I’ll try them out and see if I can do my own 
documentation. For reference, here are a few different forms that I was able to 
create with TextEdit:

http://breaqz.com/font/AlternateStylisticForms.pdf

This includes examples of the following:

• Vertically centered colon
• Straight-sided six and nine
• Open Four
• One storev a (e.g. alternate lowercase ‘a’ form)
• Small Capitals
• Contextual Fractional Forms (fractional form for any fraction)
• Monospaced Numbers

Doug Hill


___

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: Vertically Centered Colon

[Doug Hill]

OK, after doing some tests, UILabel indeed behaves like you mentioned with the 
SF font. If there aren't numbers on either side of the colon, no vertical 
centering. My guess would see if you can attempt to set the 
kStylisticAlternativesType attribute, as noted below, but as previously 
mentioned, will probably not work automatically due to the different fonts for 
the numerals around the colon.

At this point, I'd say your working solution is probably as good as you're 
going to get.

Doug Hill


> On Nov 28, 2016, at 12:33 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> A couple of things to note:
> 
> 1. In the SF font, colons are vertically centered by default.
> You can test this by creating a plain UILabel with System Font in IB and type 
> a time e.g. 10:20, and notice the colon is vertically centered. So if you use 
> SF font, you don't have to do anything to get the centered colon feature.
> 
> 2. The font for UILabel with an attributed string 'text' property appears NOT 
> to be SF font (e.g. System Font) by default.
> Again, to test this create a UILabel in IB and change Text to an attributed 
> string, notice that the font changes to Helvetica Neue. I also notice that SF 
> font doesn't show up in the list of fonts in IB for this label. FWIW, I'm 
> still using Xcode 7.x so someone should try Xcode 8 to verify if this is 
> still the case.
> For the heck of it I installed SF font on my Mac so I can select it in the 
> attributed text font list, but notice a bunch of bugs. For example, the font 
> size I set in IB for the attributed text is ignored. At runtime it's probably 
> 12 or 14 pt. Also, in IB, if you edit the text by double-clicking in the 
> label, you'll see an input field for large text but nothing shown. Oh well, 
> another trip to RADAR.
> In any case it's a bad idea to select the exact font since you have to choose 
> SF Display or Text which you don't want to do. It should be dynamically 
> selected at runtime based on the font size. This behavior is supported by 
> using System Font.
> 
> Anyways, I would check the font at runtime to make sure it's SF. Otherwise, 
> you need a font that supports the Vertically Centered Colon font feature. You 
> can check this feature by doing the following:
> • Select your desired font on your Mac for the attributed string in the font 
> panel
> • Click the Gear icon in the upper-left corner.
> • Select Typography…
> • Select 'Alternative Stylistic Sets'
> • Select 'Vertically Centered Colon'
> 
> Which Helvetica Neue DOES NOT support.
> 
> Furthermore, I don't see a way to set these  'Alternative Stylistic' 
> attributes from UIAttributedText. I do see some settings in 
> CoreText/SFNTLayoutTypes.h under kStylisticAlternativesType. But the settings 
> are just numbered so I don't know which it might be. A little experimentation 
> might find the right one.
> 
> But in summary, if you are using SF font, you don't need to set the 
> Vertically Centered Colon attribute as it should be on by default.
> 
> Doug Hill
> 
> 
> 
>> On Nov 28, 2016, at 11:12 AM, Gerriet M. Denkmann <gerri...@icloud.com> 
>> wrote:
>> 
>> 
>>> On 28 Nov 2016, at 23:42, Alastair Houghton <alast...@alastairs-place.net> 
>>> wrote:
>>> 
>>> On 28 Nov 2016, at 16:18, Gerriet M. Denkmann <gerri...@icloud.com> wrote:
>>>> 
>>>> 
>>>>> On 28 Nov 2016, at 22:13, Eric E. Dolecki <edole...@gmail.com> wrote:
>>>>> 
>>>>> You could probably use an attributed string and add an attribute for the 
>>>>> last colon: NSBaselineOffsetAttributeName
>>>> 
>>>> Yes; but this would be some rather desperate work-around.
>>>> 
>>>> I was rather thinking of UIFontDescriptorFeatureSettingsAttribute with 
>>>> some Feature type from SFNTLayoutTypes.h (in CoreText).
>>>> I tried a few types, but no success so far.
>>> 
>>> The problem you’ve got is that unless the font has a feature that 
>>> specifically allows you to change *any* colon (as opposed to a colon 
>>> between two numerals), you aren’t going to be able to do it by turning on 
>>> an OpenType feature.  Even if you can, there doesn’t appear to be a 
>>> standard feature code for this, so you’d be reliant on Apple not changing 
>>> it in the future.
>> 
>> The WWDC 2015 talk seemed to suggest that there is a standard feature for 
>> this.
>> But there are about 40 feature types in SFNTLayoutTypes.h - no idea what to 
>> use.
>> 
>> 
>>> What you *could* do instead is get Core Text (or Cocoa Text) to lay out a 
>>> str

Re: Vertically Centered Colon

[Doug Hill]

A couple of things to note:

1. In the SF font, colons are vertically centered by default.
You can test this by creating a plain UILabel with System Font in IB and type a 
time e.g. 10:20, and notice the colon is vertically centered. So if you use SF 
font, you don't have to do anything to get the centered colon feature.

2. The font for UILabel with an attributed string 'text' property appears NOT 
to be SF font (e.g. System Font) by default.
Again, to test this create a UILabel in IB and change Text to an attributed 
string, notice that the font changes to Helvetica Neue. I also notice that SF 
font doesn't show up in the list of fonts in IB for this label. FWIW, I'm still 
using Xcode 7.x so someone should try Xcode 8 to verify if this is still the 
case.
For the heck of it I installed SF font on my Mac so I can select it in the 
attributed text font list, but notice a bunch of bugs. For example, the font 
size I set in IB for the attributed text is ignored. At runtime it's probably 
12 or 14 pt. Also, in IB, if you edit the text by double-clicking in the label, 
you'll see an input field for large text but nothing shown. Oh well, another 
trip to RADAR.
In any case it's a bad idea to select the exact font since you have to choose 
SF Display or Text which you don't want to do. It should be dynamically 
selected at runtime based on the font size. This behavior is supported by using 
System Font.

Anyways, I would check the font at runtime to make sure it's SF. Otherwise, you 
need a font that supports the Vertically Centered Colon font feature. You can 
check this feature by doing the following:
• Select your desired font on your Mac for the attributed string in the font 
panel
• Click the Gear icon in the upper-left corner.
• Select Typography…
• Select 'Alternative Stylistic Sets'
• Select 'Vertically Centered Colon'

Which Helvetica Neue DOES NOT support.

Furthermore, I don't see a way to set these  'Alternative Stylistic' attributes 
from UIAttributedText. I do see some settings in CoreText/SFNTLayoutTypes.h 
under kStylisticAlternativesType. But the settings are just numbered so I don't 
know which it might be. A little experimentation might find the right one.

But in summary, if you are using SF font, you don't need to set the Vertically 
Centered Colon attribute as it should be on by default.

Doug Hill



> On Nov 28, 2016, at 11:12 AM, Gerriet M. Denkmann <gerri...@icloud.com> wrote:
> 
> 
>> On 28 Nov 2016, at 23:42, Alastair Houghton <alast...@alastairs-place.net> 
>> wrote:
>> 
>> On 28 Nov 2016, at 16:18, Gerriet M. Denkmann <gerri...@icloud.com> wrote:
>>> 
>>> 
>>>> On 28 Nov 2016, at 22:13, Eric E. Dolecki <edole...@gmail.com> wrote:
>>>> 
>>>> You could probably use an attributed string and add an attribute for the 
>>>> last colon: NSBaselineOffsetAttributeName
>>> 
>>> Yes; but this would be some rather desperate work-around.
>>> 
>>> I was rather thinking of UIFontDescriptorFeatureSettingsAttribute with some 
>>> Feature type from SFNTLayoutTypes.h (in CoreText).
>>> I tried a few types, but no success so far.
>> 
>> The problem you’ve got is that unless the font has a feature that 
>> specifically allows you to change *any* colon (as opposed to a colon between 
>> two numerals), you aren’t going to be able to do it by turning on an 
>> OpenType feature.  Even if you can, there doesn’t appear to be a standard 
>> feature code for this, so you’d be reliant on Apple not changing it in the 
>> future.
> 
> The WWDC 2015 talk seemed to suggest that there is a standard feature for 
> this.
> But there are about 40 feature types in SFNTLayoutTypes.h - no idea what to 
> use.
> 
> 
>> What you *could* do instead is get Core Text (or Cocoa Text) to lay out a 
>> string e.g. “12:00”, then grab the glyph for the centred colon directly from 
>> that string and use it explicitly, e.g. by attaching a 
>> kCTGlyphInfoAttributeName attribute to your string with the value set to an 
>> appropriately constructed CTGlyphInfoRef.
> 
> done once:
> 
> CGRect frame = { {0,0},{99,99}};  
> UITextView *dummyTextView = [ [UITextView alloc] initWithFrame: frame 
> textContainer: nil ];
> dummyTextView.text = @“23:21”;
> dummyTextView.font = thinFont;
> NSLayoutManager *layoutManager = dummyTextView.layoutManager;
> [ layoutManager ensureGlyphsForCharacterRange: range ];
> [ layoutManager ensureLayoutForCharacterRange: range ];
> NSUInteger glyphIndex = [ layoutManager glyphIndexForCharacterAtIndex: 2 ];
> centeredColonGlyph = [ layoutManager CGGlyphAtIndex: glyphIndex ];;
> 
> 
> and then:
> 
> CFMutableAttributedStringRef aStr = (__bridge 
> CFMutableAttributedStringRef)at

Re: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Doug Hill]

> On Oct 19, 2016, at 2:14 PM, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
>> On Oct 19, 2016, at 2:04 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Presumably if the app is terminated due to inactivity everything would be 
>> dealloc'd including singletons. No idea if that is happening or not in this 
>> case though.
> 
> No, nothing would be dealloced. The whole process would just be killed, and 
> _nothing_ would happen in it after that point, including seeing a null 
> singleton pointer. So that’s not what the problem is.
> 
> —Jens



FWIW, in the past I saw my iOS shut down gracefully when being terminated due 
to inactivity or low-memory, rather than just a kill -9. I haven't checked this 
lately though.

Doug Hill
___

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: iOS: Preventing a singleton from being deallocated when the app is in the background.

[Doug Hill]

> On Oct 19, 2016, at 2:00 PM, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
>> On Oct 19, 2016, at 1:23 PM, Steve Mills <sjmi...@mac.com> wrote:
>> 
>> Pardon my obvious question, but this isn't a matter of your app napping 
>> while in the background, is it? Or something like that?
> 
> Why would that cause a singleton to be dealloced? The app just stops getting 
> CPU time for a while.
> 
> —Jens

Presumably if the app is terminated due to inactivity everything would be 
dealloc'd including singletons. No idea if that is happening or not in this 
case though.

Doug Hill


___

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: Swift 3 macOS read keyboard

[Doug Hill]

> On Oct 10, 2016, at 4:08 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 10, 2016, at 16:00 , Eric Dolecki <edole...@gmail.com> wrote:
>> 
>> Can I […] set accepts first responder true.
> 
> Unfortunately, no. It’s a read-only property.

Implement this in your NSResponder subclass:


- (BOOL)acceptsFirstResponder
{
return YES;
}


Doug Hill
___

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: Swift 3 macOS read keyboard

[Doug Hill]

> On Oct 10, 2016, at 3:36 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Oct 10, 2016, at 15:07 , Graham Cox <graham@bigpond.com> wrote:
>> 
>> NSWindow, NSWindowController and NSView, NSViewController all inherit from 
>> NSResponder, which provide standard methods for dealing with keyUp and 
>> keyDown events.
> 
> I agree with everything you said, but a bit of caution is needed with 
> NSViewController subclasses, if the deployment target is earlier than 10.10.
> 
> Previously, view controllers were not in the responder chain (unless you 
> wrote code to put them there), and the “responder chain for events” section 
> of the Event Handling Guide doesn’t mention view controllers as any kind of 
> special case, as it does for window controllers.
> 
> I believe there are 4 possibilities:
> 
> 1. Subclass NSView to return true from ‘acceptsFirstResponder’. Otherwise the 
> events will go to the window.
> 
> 2. Subclass NSViewController to handle keyUp/Down. But it’s also necessary to 
> do #1, and if you want pre-10.10 compatibility, you should override 
> keyUp/Down in the view subclass instead.
> 
> 3. Subclass NSWindow to handle keyUp/Down.
> 
> 4. Subclass NSWindowController to handle keyUp/Down.
> 
> Of these, #4 is the easiest and least treacherous, but I get the impression 
> Eric wants to centralize his business logic in the view controller and pretty 
> much ignore the window controller (which is a fairly reasonable attitude in 
> these storyboard days). In that case, he can have the window controller call 
> view controller methods, preferably *not* keyUp/Down overrides, but it would 
> make more sense to encapsulate everything in the view/view controller 
> combination, which means #1 and probably #2, depending on deployment.
> 
> What I find interesting about this problem is that there’s a really easy 
> solution, except that it’s easy only in the it’s-a-very-*small*-can-of-worms 
> sense. That’s why we love old-school Cocoa.

From this list #1 seems to me to be the most standard paradigm for handling 
events. If you have a view controller you have a view already, so making the 
root view of the controller handle events via 'acceptsFirstResponder' and using 
'becomeFirstResponder' seems like the easiest and most standard way to go. #2 
could also work, as NSViewController also derives from NSResponder, so, you 
could have the controller handle all key events as well.
All the other options have various levels of hackiness that are probably more 
trouble than they're worth, IMHO.

Doug Hill
___

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: Stupid objective-c question

[Doug Hill]

> On Sep 22, 2016, at 4:19 PM, Sandor Szatmari <admin.szatmari@gmail.com> 
> wrote:
> 
> So there was lots of discussion and plenty of 'don't do anything that equates 
> to this' --> @"myString" == @"myString", and I agree.  
> 
> I wanted to get some opinions on the following which I have done in the past 
> and perceive as different because the string constant is introduced and 
> defined once and only once.
> 
> // my .m file
> static NSString * const kMyContext = @"my fantastic context";
> 
> // later on
> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>   change: (NSDictionary *) change context: (void *) 
> context
> {
>  if ( context == kMyContext )
>  { // do my stuff }
>  else
>  // call super
> }
> 
> My interpretation of how to use context has been as an arbitrary pointer...  
> Does this run afoul of anyone's sensibility?
> 
> Sandor Szatmari

This appears to follow Apple recommended practice. I think after all the 
discussion on this thread, pretty much the only thing you should do is compare 
the context to a static pointer. And a static string maybe makes it easier to 
identify a particular context. I’m actually changing some old code right now to 
use these recommendations.

Good luck!

Doug Hill


___

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: Stupid objective-c question

[Doug Hill]

> On Sep 21, 2016, at 10:07 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 21, 2016, at 21:10 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> I believe the original question was why you can compare a string literal to 
>> another object pointer using the == operator and it somehow works.
> 
> Actually, we’re more or less on the same page here, but for posterity…
> 
> There’s no “somehow” with the == operator. It’s a C thing, not an Obj-C 
> thing, so putting it between two pointers is well-defined, even if either of 
> them happens to be an object reference. Indeed, constructs like "(void*)3" 
> are also a C thing 

Just as an example of how this “somehow worked”, but just as easily couldn't:

@“xyz123” == @“xyz123”

isn’t guaranteed to resolve to YES.

Crazy stuff. :)

But I appreciate everyone jumping in on this topic, another thread for the ages.

Doug Hill
___

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: Stupid objective-c question

[Doug Hill]

I think it’s because an NSArray is immutable such that an empty array is 
guaranteed to never change. This gives the compiler opportunities for 
optimization based on this knowledge.

It starts to get interesting when you do things like:

NSArray *emptyArray   = [[NSArray alloc] init];
NSArray *anotherArray = [emptyArray arrayByAddingObject:anObject];

But this creates a new array. Consequently, any meaningful array won’t be the 
one created with [[NSArray alloc] init].

Doug Hill


> On Sep 21, 2016, at 9:19 PM, Jeff Evans <jev...@ars-nova.com> wrote:
> 
> Whoa - maybe I've had too much wine with dinner, but:
> 
>   Is it really true what Jens says,  that [[NSArray alloc]init] always 
> returns the same pointer?
>   If that is the case, how can one declare two separate arrays?
> 
> Jeff
> 
> On Sep 21, 2016, at 8:50 PM, Jens Alfke wrote:
> 
> 
>> On Sep 21, 2016, at 6:36 PM, Graham Cox <graham@bigpond.com> wrote:
>> 
>> Which is yet another reason why void* is such a shitty concept. Apple could 
>> easily have insisted that parameter was id without any real 
>> problems, so void*… sheesh.
> 
> It’s not an object! It’s just an opaque ‘cookie’ that you can use to 
> recognize which observer is being invoked, and specify which one to remove.
> 
> The point of using a void* is that it’s easy to generate guaranteed-unique 
> values by taking the address of a static variable. If the context were an 
> object, people would be likely to assume they should use -isEqual: to compare 
> them (as half the people on this thread seem to be doing), but that’s not a 
> good idea because it can result in false positives comparing 
> equal-but-different objects.
> 
> Moreover, it can be hard to be sure whether you’re getting distinct objects 
> in Obj-C, since initializers will often return unique singletons for common 
> cases. For instance, [[NSArray alloc] init] will always return the same 
> pointer every time it’s called, making it a terrible choice for a context.
> 
> —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: Stupid objective-c question

[Doug Hill]

> On Sep 21, 2016, at 8:33 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 21, 2016, at 19:00 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Just to be clear, the original question was specifically about comparing an 
>> Objective-C string literal. For this case, you definitely want to use 
>> -[NSString isEqualToString:]
> 
> Actually, no. A couple of similar comments in this thread have slightly 
> missed the point about the original question.
> 
> The “cleverness” of that original approach was that the contents of the 
> string really had nothing to do with anything. As long as the string being 
> used for the current observer scenario was different from strings being used 
> by other scenarios, the pointers to the string would be different, and every 
> context would be different.
> 
> You could as easily have used (void*)1, (void*)2, (void*)3, etc in the 
> various places in your app, but using meaningful strings instead is a fairly 
> easy way of not mixing the pointers up.
> 
> Thus, there was never any intent to compare string values, just pointers, and 
> that’s what made the ‘==‘ comparison crash-proof.
> 
> It wouldn’t be *illogical* to use string value comparisons instead, except 
> that then, yes, you’d have to code around the cases where the context is not 
> a pointer to a NSString object.

I believe the original question was why you can compare a string literal to 
another object pointer using the == operator and it somehow works. The contents 
of the string in this case would be very important because the compiler does 
some magic to make duplicates of strings all have the same address. As was 
mentioned, this is a quirk of string pooling/merging by the compiler and that 
it might happen in some cases but maybe not in others. For example, I think you 
can control this behavior in GCC and LLVM with a compiler setting. Just to make 
it clear, CLang calls this undefined behavior:

NSString *foo = @"xyz123";
if( foo == @"xyz123" )
NSLog(@"YES");

warning: direct comparison of a string literal has undefined behavior 
[-Wobjc-string-compare]

Again, in general (i.e. not just for observing scenarios) you probably 
shouldn’t rely on identical strings, especially literals.

But as we’ve now verified from Apple documentation, comparing to a static 
variable address is the way to handle the context parameter in key path 
observation, so we shouldn’t be involving literals.

>> As to the context type, I would be interested to know of cases where the 
>> observer doesn't have control over the context. My understanding is that the 
>> context is something that the observer sets itself when calling addObserver, 
>> and it is passed back to itself in the above method call. So the observer 
>> should know what kind of entity the context is, and can determine the best 
>> way to compare this value.
> 
> 
> If you were the sole author of all observations in your app, you wouldn’t 
> absolutely need a context parameter at all, since you can identify the 
> observation** from the object and keypath. But you’re not.
> 
> The observer doesn’t have control over the context when the superclass or a 
> subclass also does observations, and those other classes aren’t written as 
> part of the project. For example, a view controller is a class that’s often 
> going to want to observe things, but NSViewController may itself be observing 
> things too, possible some of the same things. That’s one reason why the 
> observer method must always call super for notifications that it cannot 
> recognize *specifically* as resulting from observations it *specifically* 
> added.
> 
> ** Except in the case where observations from various sources are funneled 
> through a common observer method, which doesn’t happen a lot, but does happen.

This makes sense. I’m glad I’m getting this figured out after all these years. 
:)

Doug Hill

___

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: Stupid objective-c question

[Doug Hill]

> On Sep 21, 2016, at 6:36 PM, Graham Cox <graham@bigpond.com> wrote:
> 
> 
>> On 22 Sep 2016, at 10:40 AM, Quincey Morris 
>> <quinceymor...@rivergatesoftware.com> wrote:
>> 
>> On Sep 21, 2016, at 17:01 , Graham Cox <graham@bigpond.com> wrote:
>>> 
>>> This should be: if([(NSString*)context 
>>> isEqualToString:@“mediaLibraryLoaded”])…
>> 
>> Actually, this is not a good idea either, because *other* observations — 
>> ones you don’t control — might use a value that’s not an object, or not even 
>> a valid pointer.
> 
> 
> Fair point.
> 
> Which is yet another reason why void* is such a shitty concept. Apple could 
> easily have insisted that parameter was id without any real 
> problems, so void*… sheesh.
> 
> So Gabriel’s alternative is basically to use a global address, as you 
> otherwise suggested.
> 
> void* tsk… *goes away muttering*
> 
> —Graham

Just to be clear, the original question was specifically about comparing an 
Objective-C string literal. For this case, you definitely want to use 
-[NSString isEqualToString:]

As to the context type, I would be interested to know of cases where the 
observer doesn't have control over the context. My understanding is that the 
context is something that the observer sets itself when calling addObserver, 
and it is passed back to itself in the above method call. So the observer 
should know what kind of entity the context is, and can determine the best way 
to compare this value.

But hey, always check the documentation first. Here's a nice little tidbit from

https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOBasics.html
 
<https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/KeyValueObserving/Articles/KVOBasics.html>

"The address of a uniquely named static variable within your class makes a good 
context. Contexts chosen in a similar manner in the super- or subclass will be 
unlikely to overlap. You may choose a single context for the entire class and 
rely on the key path string in the notification message to determine what 
changed. Alternatively, you may create a distinct context for each observed key 
path, which bypasses the need for string comparisons entirely, resulting in 
more efficient notification parsing."

So, instead of using a string literal, create a static object and do pointer 
comparisons is what Apple recommends.

Hope this helps.

Doug Hill
___

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: Stupid objective-c question

[Doug Hill]

> On Sep 21, 2016, at 4:52 PM, Steve Mills <sjmi...@mac.com> wrote:
> 
>> On Sep 21, 2016, at 18:44, Gabriel Zachmann <z...@tu-clausthal.de> wrote:
>> 
>> I've got a stupid, curious question regarding a code snippet that I have 
>> found on the net (I tried it, it works).
>> 
>> Here is the code snippet:
>> 
>> - (void) observeValueForKeyPath: (NSString *) keyPath   ofObject: (id) object
>>   change: (NSDictionary *) change context: (void *) 
>> context
>> {
>>  if ( context == (__bridge void *) @"mediaLibraryLoaded" )
>>  {
>>// ...
>> 
>> 
>> My question is: how can the compiler know that '==' in this case is a 
>> NSString comparison?
>> Or is some other magic going on here? if so, which?
>> Does the compiler know it should perform some kind of dynamic method 
>> dispatch?
> 
> My guess, without seeing the code that set up the observer, is that it was 
> also set up with @"mediaLibraryLoaded", and the compiler collects and reuses 
> string constants, so the address is the same. I'd guess that if you ensure 
> that the string is a unique variable, it won't work.
> 
> NSString* s = [NSString stringWithFormat:@"%@%@%@", @"media", @"Library", 
> @"Loaded"];
> if(context == (__bridge void*)s)
> 
> Steve via iPad

For the above test, you could also try turning off the LLVM code-gen setting 
"gcc_reuse_strings".
(Which parenthetically, you probably wouldn't want to do in shipping code, 
particularly if you have a lot of strings.)

But yeah, as everyone says, it's generally not a good thing to rely upon this 
behavior, and just use -[NSString isEqual:]

Doug Hill
___

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

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

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

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

Re: How to update UI from a background thread

[Doug Hill]

> On Sep 21, 2016, at 10:00 AM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Sep 21, 2016, at 09:20 , Dave <d...@looktowindward.com> wrote:
>> 
>> The time consuming method I am calling is in a third party library and it 
>> must be called in the main thread. 
> 
> You cannot update UI on a background thread, so if the library method is 
> blocking the main thread you’re out of luck. The only solution is to get the 
> library author to write proper code.
> 
> If the library method is running on the main thread and calling back to a 
> block of your code (which sounds like the case), then it’s safe execute code 
> that issues UI updates, but you likely won’t see the results until later, 
> after your app returns to the main event loop.
> 
> If a time-consuming operation *is* running on a background thread, it can 
> dispatch_async a block to the main thread to update the UI, but then you must 
> consider thread safety, if the update is referencing data that’s still being 
> modified as the background thread continues to run.


As Quincy accurately describes, it is well documented you can’t do any UI 
updates on anything other than the main queue/thread. 

https://developer.apple.com/reference/uikit

Which is why your 3rd-party library has this requirement and why CALayer is 
complaining. So, your UI update needs to be called on the main queue as well.

Sandor’s suggestion to put your UI update code on a block that’s executed 
sometime later on the main queue SHOULD work as it just delays your code until 
the queue finishes it’s currently executing tasks. The symptoms you mention 
sound like a classic deadlock problem. That is, a code block running on the 
main queue schedules another code block on the main queue, but the original 
block never completes thus causing the app to hang or the new task never runs. 
It could well be that there is a bug in the library you’re using that causes it 
to block the main queue. But it’s probably good to make sure your code is doing 
the right thing. Perhaps there’s another issue that’s causing the problems you 
see. Maybe you could provide some code for the case where you use the 
dispatch_async technique below to accomplish your task and when you don’t and, 
what happens in each case.

Doug Hill
___

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: Passing param by reference then using within block throws exception

[Doug Hill]

I think this is the exact solution. As I'm sure you've tried, you can't use the 
__block modifier on method parameters, as you will get the following compiler 
error:

__block attribute not allowed, only allowed on local variables

So, you're doing the right thing creating the local as a temporary to 
eventually assign to the method parameter.

Doug Hill



> On Sep 20, 2016, at 2:06 PM, Steve Mills <sjmi...@mac.com> wrote:
> 
> I'm turning on ARC for a project (yay) and have run into a problem I can't 
> wrap my head around. It always worked fine before ARC. When I turn zombies 
> on, doing "memory history 0x610004279ac0" can't find it in the history. 
> Here's the method and the call to it:
> 
> -(void) doStuff:(NSString**)fillMeIn
> {
>[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL* stop) {
>   if(obj.flag) {
>  *stop = YES;
>  *fillMeIn = @"wow";
>   }
>}];
> }
> 
> NSString* getFilledIn;
> 
> [thing doStuff:];
> 
> The call to doStuff: results in EXC_BAD_ACCESS, or "*** -[CFString retain]: 
> message sent to deallocated instance 0x610004279ac0" if I turn zombies on.
> 
> I tried changing the param type to (NSString** _Nonnull), thinking it was 
> confused about my knowing that the reference will never be nil, but it didn't 
> help. Then I got to thinking about the reference being assigned inside the 
> block and changed it to:
> 
> -(void) doStuff:(NSString** _Nonnull)fillMeIn
> {
>__block NSString* noFillMeIn;
>
>[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL* stop) {
>   if(obj.flag) {
>  *stop = YES;
>  *noFillMeIn = @"wow";
>   }
>}];
>
>*fillMeIn = noFillMeIn;
> }
> 
> That seems to fix it. Is there a better way to deref and assign to the param 
> from within the block?


___

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: Toolbar hiding on rotation?

[Doug Hill]

> On Aug 29, 2016, at 9:57 AM, Alex Kac <a...@webis.net> wrote:
> 
> I have a UINavigationController and UIViewController root that I set the 
> toolbarItems on. I obviously also tell it not to hide the toolbar. Great! 
> Works perfectly. But when I rotate, the toolbar is hidden - even if I rotate 
> back to portrait. I've set all the "hides*" properties such as 
> hidesBarsWhenVerticallyCompact to false (they were already false - but I 
> tried anyway), and it still hides the toolbar. I’ve put breakpoints 
> everywhere including symbolic ones for the toolbar hidden properties/methods 
> in UIKit. Since we are using a navigationcontroller subclass, I even tried 
> overriding the toolbar methods so that they can't get set to true (hiding 
> that is) and it still hides the toolbar. 
> 
> In some ways, I'm okay with it hiding going in landscape, but I'm not OK with 
> it not coming back when you go to portrait. The view debugger also shows the 
> toolbar is completely gone. So something in UIKit is removing the toolbar 
> view and never bringing it back - nothing I do can bring it back. This is 
> obviously disconcerting. My next step will be to just creating my own toolbar 
> instead of using Apple’s navcontroller toolbar, but if I can get it to work, 
> that’s my preference.
> 
> Any ideas?

It's interesting you mention this since I just spent a bunch of time trying to 
get this toolbar thing working according to Apple HIG.

For example, it used to say that on iPad you should put the bar button items in 
the Navigation Bar but on iPhone they should be at the bottom in a Toolbar. Now 
they say to use the Size classes to determine this. For example, regular width 
they put buttons in nav bar but in compact width use toolbar. This is because 
compact width generally corresponds to iPhone. But just to make things 
complicated multitasking windows on iPad are compact width. Further, landscape 
iPhone 6 plus (e.g. 5.5" display) is regular width. Gah! This is kind of weird 
because the toolbar hides and shows based on device rotation and multitasking 
modes, which seems a little jarring to me. But hey, go with the flow.

That said, I'm looking at my code and I see that I implement this logic in 
traitCollectionDidChange. And I'm just using 
self.navigationController.toolbarHidden for toolbar hiding and it seems to work 
fine. See if this property works for you, and let us know. Otherwise, there 
might be some other code hiding the toolbar.

Doug Hill
___

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: Mysterious crash with NSTableView

[Doug Hill]

> On Aug 26, 2016, at 9:20 PM, Jeff Szuhay  wrote:
> 
> 
>>> On Aug 26, 2016, at 8:44 PM, Sandor Szatmari  
>>> wrote:
>>> 
>>> 
>>> However, in your case I wonder what the static analyzer in Xcode tells you 
>>> about the bug you see?
>> 
>> I believe Andreas mentioned he does not use Xcode as his product is cross 
>> platform, but this is a good suggestion.
> 
> Any why not? 
> 
> Sure, build it without Xcode, but couldn’t you create a shell project where 
> the product doesn’t really matter, then build and use the tools in Xcode?

I believe you can also invoke the analyzer via the command-line tools.
___

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: Mysterious crash with NSTableView

[Doug Hill]

On Aug 26, 2016, at 1:52 PM, Jens Alfke  wrote:
> 
> On Aug 26, 2016, at 8:42 AM, Andreas Falkenhahn  
> wrote:
>> 
>> But once again, I think it's a crime that there is no mentioning of this in 
>> the class
>> documentation of "setDelegate" and "setDatasource" :( 
> 
> In the Xcode 8 docs for NSTableView.dataSource, it does:
>   "Note that in versions of OS X prior to v10.12, the table view did not 
> retain the data source in a managed memory environment."
> 
> I’m sure I won’t be the first person to suggest that you switch to ARC. If 
> you find ref-counting confusing, ARC will help you a lot.
> 
> —Jens

As usual, Jens speaks truthfully about using ARC.

However, in your case I wonder what the static analyzer in Xcode tells you 
about the bug you see? Can it catch the bug? In manual ref-counting, the 
analyzer has saved my skin more than once. :)

Doug
___

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: Does setFormatter() retain?

[Doug Hill]

Also, if you're unsure whether you're following ref-counting rules correctly, 
the static analyzer in Xcode will give very detailed warnings about incorrect 
uses. Just another way to determine if you're using ref-counting correctly.

Doug Hill


> On Aug 24, 2016, at 2:49 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> Wim,
> 
> If I may paraphrase:
> 
> The reference counting semantics are only interesting to the caller when the 
> callee returns an object. What the callee does with a setter is entirely the 
> responsibility of the callee to make sure it follows ref-counting rules. For 
> example, a setter may not involve a property or iVar at all, it could be pure 
> side-effects. In terms of ref-counting semantics, the caller doesn't have a 
> clue or need to care what happens
> 
> In this particular case, it would appear that the NSTextField holds a 
> reference the 'formatter' object via the similarly-named property in 
> NSControl. While it might be good to know it's a property so we can make use 
> of property syntax correctly, how it goes about keeping a reference to this 
> object is unimportant to the caller.
> 
> Doug Hill
> 
> PS
> IMHO using manual ref-counting because there is a perceived time-savings from 
> learning ARC is generally a bad argument. The amount of time trying to figure 
> out all the manual ref-counting rules, and making sure your code follows them 
> perfectly, is probably much better spent learning ARC and applying it 
> correctly. And likely results in more maintainable and understandable code. 
> The argument in favor of ARC is especially better if you own the code in 
> question and there isn't much code to write.
> 
> PS #2
> ARC is available in OS X 10.6 as "ARCLite" e.g. "Automatic Reference Counting 
> without zeroing weak reference."
> If you don't require the weak attribute semantics in your own code, then you 
> should be able to use ARC.
> 
> https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/
> 
> 
>> On Aug 24, 2016, at 1:41 PM, Wim Lewis <w...@omnigroup.com> wrote:
>> 
>> 
>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn <andr...@falkenhahn.com> 
>> wrote:
>>> I have read Apple's memory management guide on retain/release and
>>> I think I've basically got it, but there's just one thing that
>>> I'm not confident about and that is "setXXX" methods which accept an
>>> NSObject parameter and I don't know how I can know whether the
>>> "setXXX" retains or not.
>> 
>> In general, if a method you call wants to keep a reference to an object you 
>> pass in, it is that method's responsibility to retain it (or copy it, or 
>> whatever). If it doesn't hold on to the formatter, then it won't retain it. 
>> The goal of reference-counting, whether ARC or not, is that all that 
>> information can be safely considered an implementation detail of the method 
>> you call, and not something you need to worry about.
>> 
>> Delegate and data source setters are an unusual, exceptional case: an object 
>> with a delegate typically doesn't retain its delegate, just keeps a 
>> reference to it. This is dangerous, since the delegate can get deallocated, 
>> leaving a dangling pointer (--> soon you'll crash). If the API conventions 
>> were being formed today, delegates would probably be 'weak' pointers, but 
>> since they predate the existence of weak pointers they get the "slightly 
>> dodgy poor-man's weak pointer" behavior of simply not retaining. Why is 
>> this? It's to avoid retain-cycles, since very often, an object's delegate is 
>> its (direct or indirect) owner in a conceptual sense and therefore already 
>> retains the object.
>> 
>> 
>>> Post-scriptum: Yes, I know, there's now ARC and everything and
>>> all those retain stuff shouldn't be used anymore
>> 
>> ARC just automatically inserts the same retain/release calls that you would 
>> have written manually. (Plus some optimizations on top of that, but that's 
>> the basic idea.) It can be useful to understand MRR even if you don't write 
>> it.
>> 
>> On Aug 24, 2016, at 1:24 PM, Andreas Falkenhahn <andr...@falkenhahn.com> 
>> wrote:
>>> If it retains, I could just do the following:
>>> 
>>>  [textField setFormatter:formatter];
>>>  [formatter release];
>>> 
>>> And I wouldn't have to worry about "formatter" any longer.
>> 
>> Yes, you can do exactly that. If the textField needs the formatter to 
>> continue to exist after -setFormatter: returns, it wi

Re: Does setFormatter() retain?

[Doug Hill]

Wim,

If I may paraphrase:

The reference counting semantics are only interesting to the caller when the 
callee returns an object. What the callee does with a setter is entirely the 
responsibility of the callee to make sure it follows ref-counting rules. For 
example, a setter may not involve a property or iVar at all, it could be pure 
side-effects. In terms of ref-counting semantics, the caller doesn't have a 
clue or need to care what happens

In this particular case, it would appear that the NSTextField holds a reference 
the 'formatter' object via the similarly-named property in NSControl. While it 
might be good to know it's a property so we can make use of property syntax 
correctly, how it goes about keeping a reference to this object is unimportant 
to the caller.

Doug Hill

PS
IMHO using manual ref-counting because there is a perceived time-savings from 
learning ARC is generally a bad argument. The amount of time trying to figure 
out all the manual ref-counting rules, and making sure your code follows them 
perfectly, is probably much better spent learning ARC and applying it 
correctly. And likely results in more maintainable and understandable code. The 
argument in favor of ARC is especially better if you own the code in question 
and there isn't much code to write.

PS #2
ARC is available in OS X 10.6 as "ARCLite" e.g. "Automatic Reference Counting 
without zeroing weak reference."
If you don't require the weak attribute semantics in your own code, then you 
should be able to use ARC.

https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/


> On Aug 24, 2016, at 1:41 PM, Wim Lewis <w...@omnigroup.com> wrote:
> 
> 
> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn <andr...@falkenhahn.com> 
> wrote:
>> I have read Apple's memory management guide on retain/release and
>> I think I've basically got it, but there's just one thing that
>> I'm not confident about and that is "setXXX" methods which accept an
>> NSObject parameter and I don't know how I can know whether the
>> "setXXX" retains or not.
> 
> In general, if a method you call wants to keep a reference to an object you 
> pass in, it is that method's responsibility to retain it (or copy it, or 
> whatever). If it doesn't hold on to the formatter, then it won't retain it. 
> The goal of reference-counting, whether ARC or not, is that all that 
> information can be safely considered an implementation detail of the method 
> you call, and not something you need to worry about.
> 
> Delegate and data source setters are an unusual, exceptional case: an object 
> with a delegate typically doesn't retain its delegate, just keeps a reference 
> to it. This is dangerous, since the delegate can get deallocated, leaving a 
> dangling pointer (--> soon you'll crash). If the API conventions were being 
> formed today, delegates would probably be 'weak' pointers, but since they 
> predate the existence of weak pointers they get the "slightly dodgy 
> poor-man's weak pointer" behavior of simply not retaining. Why is this? It's 
> to avoid retain-cycles, since very often, an object's delegate is its (direct 
> or indirect) owner in a conceptual sense and therefore already retains the 
> object.
> 
> 
>> Post-scriptum: Yes, I know, there's now ARC and everything and
>> all those retain stuff shouldn't be used anymore
> 
> ARC just automatically inserts the same retain/release calls that you would 
> have written manually. (Plus some optimizations on top of that, but that's 
> the basic idea.) It can be useful to understand MRR even if you don't write 
> it.
> 
> On Aug 24, 2016, at 1:24 PM, Andreas Falkenhahn <andr...@falkenhahn.com> 
> wrote:
>> If it retains, I could just do the following:
>> 
>>   [textField setFormatter:formatter];
>>   [formatter release];
>> 
>> And I wouldn't have to worry about "formatter" any longer.
> 
> Yes, you can do exactly that. If the textField needs the formatter to 
> continue to exist after -setFormatter: returns, it will retain it. It's the 
> textField's job to worry about that retain/release, not yours. You only need 
> to retain objects that *you* have a reason to reference in the future.


___

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: array = [NSArray new] or array = [NSArray array]?

[Doug Hill]

FWIW, I use the [Classname new] syntax when allocating just about any object 
instead of [[Classname alloc] init]. Including with arrays, especially 
NSMutableArray. I've never seen any issues.

Doug Hill


> On Aug 16, 2016, at 2:20 AM, Alex Zavatone <z...@mac.com> wrote:
> 
> Yes, I know about literals, but I have a different question here.
> 
> I have seen this in some code in our codebase:
> array = [NSArray new]; 
> 
> I'm familiar with using the public method from the NSArray header and what 
> the docs say to use:
> or array = [NSArray array];
> 
> Is there any risk to using [NSArray new] to init an array instead of [NSArray 
> array]??
> 
> I'm surprised to see this being used in our codebase and would like to make 
> sure we are not destroying the universe by using it.
> 
> Thank you in advance.
> - Alex Zavatone


___

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: Justification of collection cells in sections

[Doug Hill]

I'm now trying some techniques to fix the behavior to center items when there 
is one item in a collection view section.

I'm trying two different approaches:

1. Like Peter's suggestion, create a subclass of UICollectionViewFlowLayout, 
and override layout attributes methods

I create overrides of both layoutAttributesForItemAtIndexPath and 
layoutAttributesForElementsInRect. I then modify the 'frame' property of any 
layout attribute objects whose index path is Section == 0. I set the origin to 
0.

I see no effect at runtime.

I notice that the origin X value starts as 0 for these items before I attempt 
to modify it, so it doesn't look like making any changes in this method would 
have any effect. Somewhere else the item is being centered in the collection 
view behind my back.

2. Override preferredLayoutAttributesFittingAttributes in my custom collection 
cell object

Same as above, I notice that the origin X value of the frame property of layout 
attribs is already 0 before I do any modifications. And sure enough, 
modifications don't make any effect at runtime.

This behavior is baffling as I've seen other collection views that are 
implemented with the items left justified in multiple sections. Any ideas? Am I 
missing something?

Doug Hill


> On Aug 8, 2016, at 12:35 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> Hello Peter,
> 
> Thanks for the info. I'm still trying to see if I can do what I want with the 
> stock flow layout.
> 
> FWIW, it appears that the behavior of the flow layout class is to center 
> items when there is one section.
> 
> This appears to be a summary of the behavior:
> 
> Collection has one section:
> • Items on each line are centered on the line, including multiple items per 
> line.
> 
> Collection has multiple sections:
> • If one item in the section, center on the line.
> • Multiple items per section, flow from left-to-right, including across lines.
> 
> I wish the multiple section case was consistent flowing left-to-right.
> 
> Doug
> 
> 
>> On Aug 3, 2016, at 1:12 PM, Peter Tomaselli <vast.gra...@gmail.com> wrote:
>> 
>> I remain a non-expert on this topic, but my assumption has always been that 
>> the current “look” is by design. Ugly, but by design. “Equally distribute 
>> cells across the row” could be taken to mean that in the case of one cell, 
>> it belongs in the middle… [shrug]
>> 
>> This is some of the first Cocoa code I wrote so please forgive… almost 
>> everything about it, but here’s the FlowLayout subclass I mentioned: 
>> https://github.com/Peterbing/CV-AutoLayout/blob/master/TemplateProject/TheFlowLayout.m#L31
>>  
>> <https://github.com/Peterbing/CV-AutoLayout/blob/master/TemplateProject/TheFlowLayout.m#L31>
>> 
>> This is a completely “left-justified” layout and it works by overriding the 
>> `layoutAttributesFor*` methods to call super, and then squishes everything 
>> over to the left before returning the attributes to the caller. 
>> 
>> This is certainly not production-quality code but perhaps it’s a start! IIRC 
>> there is Apple documentation (or perhaps it was a WWDC session) about 
>> creating a simple “tweaked” UICollectionViewFlowLayout subclass — so my 
>> impression is that this approach in general is kosher.
>> 
>> On Wed, Aug 3, 2016 at 3:38 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> So, does anyone know if the current behavior I mentioned is a bug? Is the 
>> behavior of Flow Layout documented? Should I file a bug with Apple?
>> 
>> Also, what would be some quick ways to modify the flow layout behavior to 
>> handle this case with one item per section?
>> 
>> Doug Hill
> 
> ___
> 
> 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/cocoadev%40breaqz.com
> 
> This email sent to cocoa...@breaqz.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: Justification of collection cells in sections

[Doug Hill]

I'm now trying some techniques to fix the behavior to center items when there 
is one item in a collection view section.

I'm trying two different approaches:

1. Like Peter's suggestion, create a subclass of UICollectionViewFlowLayout, 
and override layout attributes methods

I create overrides of both layoutAttributesForItemAtIndexPath and 
layoutAttributesForElementsInRect. I then modify the 'frame' property of any 
layout attribute objects whose index path is Section == 0. I set the origin to 
0.

I see no effect at runtime.

I notice that the origin X value starts as 0 for these items before I modify 
it, so it doesn't look like making any changes in this method would have any 
effect. Somewhere else the item is being centered in the collection view.

2. Override preferredLayoutAttributesFittingAttributes in my custom collection 
cell object

Same as above, I notice that the origin X value of the frame property of layout 
attribs is already 0 before I do any modifications. And sure enough, 
modifications don't make any effect at runtime.

My guess is that this case is somewhat unique compared to other implementations 
that override the layout attributes in that I use multiple sections in the 
collection view. So, is there somewhere else where the cell is being centered.

Any ideas? Am I missing something?

Doug Hill


> On Aug 8, 2016, at 12:35 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> Hello Peter,
> 
> Thanks for the info. I'm still trying to see if I can do what I want with the 
> stock flow layout.
> 
> FWIW, it appears that the behavior of the flow layout class is to center 
> items when there is one section.
> 
> This appears to be a summary of the behavior:
> 
> Collection has one section:
> • Items on each line are centered on the line, including multiple items per 
> line.
> 
> Collection has multiple sections:
> • If one item in the section, center on the line.
> • Multiple items per section, flow from left-to-right, including across lines.
> 
> I wish the multiple section case was consistent flowing left-to-right.
> 
> Doug
> 
> 
>> On Aug 3, 2016, at 1:12 PM, Peter Tomaselli <vast.gra...@gmail.com> wrote:
>> 
>> I remain a non-expert on this topic, but my assumption has always been that 
>> the current “look” is by design. Ugly, but by design. “Equally distribute 
>> cells across the row” could be taken to mean that in the case of one cell, 
>> it belongs in the middle… [shrug]
>> 
>> This is some of the first Cocoa code I wrote so please forgive… almost 
>> everything about it, but here’s the FlowLayout subclass I mentioned: 
>> https://github.com/Peterbing/CV-AutoLayout/blob/master/TemplateProject/TheFlowLayout.m#L31
>>  
>> <https://github.com/Peterbing/CV-AutoLayout/blob/master/TemplateProject/TheFlowLayout.m#L31>
>> 
>> This is a completely “left-justified” layout and it works by overriding the 
>> `layoutAttributesFor*` methods to call super, and then squishes everything 
>> over to the left before returning the attributes to the caller. 
>> 
>> This is certainly not production-quality code but perhaps it’s a start! IIRC 
>> there is Apple documentation (or perhaps it was a WWDC session) about 
>> creating a simple “tweaked” UICollectionViewFlowLayout subclass — so my 
>> impression is that this approach in general is kosher.
>> 
>> On Wed, Aug 3, 2016 at 3:38 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> So, does anyone know if the current behavior I mentioned is a bug? Is the 
>> behavior of Flow Layout documented? Should I file a bug with Apple?
>> 
>> Also, what would be some quick ways to modify the flow layout behavior to 
>> handle this case with one item per section?
>> 
>> Doug Hill


___

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: NSImage drawInRect deadlock

[Doug Hill]

> On Aug 10, 2016, at 4:49 PM, Graham Cox  wrote:
> 
> 
>> On 9 Aug 2016, at 4:05 AM, Andrew Keller  wrote:
>> 
>> In my app, I’m creating thumbnails of images.  To do this in parallel, I’m 
>> using the global background dispatch queue:
> 
> 
> Just to throw another consideration into the discusion, you don’t say what 
> the thumbnails are being used for.
> 
> Typically you might want to display these to the user to browse a collection 
> of images. If that’s the case here, then it might be much more performant to 
> create them only as needed for display, rather than generate a huge batch of 
> them ahead of time. In other words, when an image thumbnail is required *for 
> display*, kick off a thread to fetch it (or display the one you have cached 
> already). This means that first time the user scrolls through the collection, 
> thumbnails will ‘pop in’ to view as each thread completes, but this effect is 
> usually easily tolerated. With scroll pre-fetching you might not even see it 
> at all.
> 
> This way your threads are naturally limited by the number of images that are 
> shown at a time, or scrolled newly into view.
> 
> —Graham

+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: Dynamic-width Collection View

[Doug Hill]

Peter,

I really appreciate your feedback and did look at your solution last week. I 
kind of gave up on the justification issue since it looks like what I saw is 
"expected" behavior and didn't want to get into workarounds until I figured out 
the self-sizing cells issue.

I looked at your code and saw a lot of non-standard stuff in there. I will 
probably end up using a few of your techniques at some point, but at this point 
I want to get an official solution from Apple. I created a TSI with DTS and 
will see if they can offer any additional ideas on how to solve this problem. 
I'll report anything I find out.

Doug Hill

 On Aug 10, 2016, at 3:30 PM, Peter Tomaselli <vast.gra...@gmail.com> wrote:
> 
> Sorry if this is kind of a cheesy reply, but a while ago I believe we were 
> speaking about “left-justifying” a collection view as well? I think I replied 
> to that thread with a link to a very unattractive toy repo of mine on GitHub 
> to illustrate the approach I’d taken with that. 
> 
> Anyway that repo does in fact implement dynamically sizing collection view 
> cells and does so with relatively few entanglements. Can’t say that I’ve used 
> it “in production” anywhere but it might be worth cloning that thing down and 
> seeing how its approach grabs you.
> 
> It’s this thing: https://github.com/Peterbing/CV-AutoLayout 
> <https://github.com/Peterbing/CV-AutoLayout>
> 
> I mention this again because I remember the frustration/bewilderment you are 
> experiencing right now quite well and also did a bunch of legwork researching 
> this. We should probably pool our resources here!
> 
> Cheers,
> 
> Peter

___

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: Dynamic-width Collection View

[Doug Hill]

On Aug 10, 2016, at 3:18 PM, Jonathan Hull <jh...@gbis.com> wrote:
> 
> The main issue is that the cell doesn’t (and shouldn’t) have any idea about 
> what size the collectionView is.  You could actually use the delegate though 
> (which has a wider view) and provide the size that way.

Agreed that the cell shouldn't know about the collection view width. But given 
that Apple says that the size needs to be calculated in the cell's override of 
preferredLayoutAttributesFittingAttributes for self-sizing cells, I'm stuck 
with it.

> That said, I did additional research and found other people with your issue.  
> Relevant posts:
>   https://github.com/imyoungyang/DynamicHeight 
> <https://github.com/imyoungyang/DynamicHeight>
>   
> http://stackoverflow.com/questions/25895311/uicollectionview-self-sizing-cells-with-auto-layout
>  
> <http://stackoverflow.com/questions/25895311/uicollectionview-self-sizing-cells-with-auto-layout>
As with everything else I've read about this topic, these links have numerous 
comments of the form "Self-sizing cells is horribly broken. Maybe my hack will 
work but I'm not sure."
The entire iOS developer community would like this to be fixed by Apple. 
Both documentation and bugs.

> My recommendation would be to remove the preferredAttributes stuff, and give 
> your cell’s content view an explicit width constraint. Then in the 
> collectionView:layout:sizeForItemAtIndexPath: method of your 
> FlowLayoutDelegate, set the constant of the width constraint to the desired 
> width (you are passed the collectionView). Then return the result of 
> contentView.systemLayoutSizeFittingSize(UILayoutFittingCompressedSize).  
> Note: I haven’t actually tried this… all code written in mail.

I actually started working on this, and will report if it gets me any further.

Appreciate the feedback.

Doug Hill

> Thanks,
> Jon
> 
>> On Aug 10, 2016, at 2:27 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Jonathon,
>> 
>> Thanks for the feedback.
>> 
>> A question that comes to mind is, what about making cells the same size as 
>> the collection view requires going through subclassing the collection view 
>> layout? Apple documentation IMPLIES this should work. It even documents that 
>> developers should use preferredLayoutAttributesFittingAttributes for this 
>> very purpose.
>> 
>> The reason I don't want to subclass flow layout is that I pretty much want 
>> the exact functionality the default flow layout provides:
>> 
>> 1. Automatically calculating layout rects that flow across lines.
>> 2. Calculating the height of cells dynamically at runtime via 
>> 'estimatedItemSize'
>> 
>> Given that, I'm open to ideas on what I should override in a layout 
>> subclass. Particularly ones that don't require me to reimplement #1 and #2 
>> above.
>> 
>> Doug Hill
>> 
>>> On Aug 10, 2016, at 2:16 PM, Jonathan Hull <jh...@gbis.com 
>>> <mailto:jh...@gbis.com>> wrote:
>>> 
>>> Because you are trying to make the width of the cell the same size as the 
>>> collection view, I would strongly consider writing a small subclass of flow 
>>> layout.  It honestly sounds like less work than what you are dealing with 
>>> now.
>>> 
>>> Thanks,
>>> Jon
>>>  
>>>> On Aug 10, 2016, at 1:29 PM, Doug Hill <cocoa...@breaqz.com 
>>>> <mailto:cocoa...@breaqz.com>> wrote:
>>>> 
>>>>> 
>>>>> On Aug 10, 2016, at 11:10 AM, Doug Hill <cocoa...@breaqz.com 
>>>>> <mailto:cocoa...@breaqz.com>> wrote:
>>>>> 
>>>>> I'm currently trying to implement something that seems basic but has been 
>>>>> driving me nuts: making a Collection View with cells that are 
>>>>> dynamic-width and height at runtime.
>>>>> 
>>>> 
>>>> Again, looking for any ideas, pointers, etc. about any of this, including 
>>>> whether I'm going about this the wrong way.
>>>> 
>>>> Doug Hill
>> 
> 

___

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: Dynamic-width Collection View

[Doug Hill]

Jonathon,

Thanks for the feedback.

A question that comes to mind is, what about making cells the same size as the 
collection view requires going through subclassing the collection view layout? 
Apple documentation IMPLIES this should work. It even documents that developers 
should use preferredLayoutAttributesFittingAttributes for this very purpose.

The reason I don't want to subclass flow layout is that I pretty much want the 
exact functionality the default flow layout provides:

1. Automatically calculating layout rects that flow across lines.
2. Calculating the height of cells dynamically at runtime via 
'estimatedItemSize'

Given that, I'm open to ideas on what I should override in a layout subclass. 
Particularly ones that don't require me to reimplement #1 and #2 above.

Doug Hill

> On Aug 10, 2016, at 2:16 PM, Jonathan Hull <jh...@gbis.com> wrote:
> 
> Because you are trying to make the width of the cell the same size as the 
> collection view, I would strongly consider writing a small subclass of flow 
> layout.  It honestly sounds like less work than what you are dealing with now.
> 
> Thanks,
> Jon
>  
>> On Aug 10, 2016, at 1:29 PM, Doug Hill <cocoa...@breaqz.com 
>> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>>> 
>>> On Aug 10, 2016, at 11:10 AM, Doug Hill <cocoa...@breaqz.com 
>>> <mailto:cocoa...@breaqz.com>> wrote:
>>> 
>>> I'm currently trying to implement something that seems basic but has been 
>>> driving me nuts: making a Collection View with cells that are dynamic-width 
>>> and height at runtime.
>>> 
>> 
>> Again, looking for any ideas, pointers, etc. about any of this, including 
>> whether I'm going about this the wrong way.
>> 
>> Doug Hill

___

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: Dynamic-width Collection View

[Doug Hill]

> On Aug 10, 2016, at 2:03 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Aug 10, 2016, at 13:42 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> this basically means that Apple's documentation is a fail and the APIs don't 
>> work in a predictable way. Again, this should also be noted so other 
>> developers don't go through all the trouble I've done to implement very 
>> basic functionality. Or maybe *hint hint* Apple could update this 
>> documentation and/or fix these bugs.
> 
> I’d actually be very surprised if this is a gross bug in UICollectionView, 
> because it gets a lot of tender love and care (it’s used in numerous standard 
> Apple apps, I would assume). My guess is that the problem is a result of what 
> you’re doing with autolayout (and possibly when, too), more than what you’re 
> doing with UICollectionView, but that’s just a hunch, nothing rational. Under 
> those circumstances of uncertainty, Apple isn’t going to go looking for a bug.
> 
> You could reasonably file a bug with a sample project that demonstrates the 
> crash, and you’d likely get back some guidance — sometime. Probably within 
> the next 12 months.
> 
> TBH, I’ve never encountered any testiness from any Apple engineer responding 
> to a TSI, and I’ve been impressed that they refund the TSI if they can’t 
> help, even when they had to do some work to figure out that they can’t help.

Quincy, I am sure I'm doing something wrong, so no argument there!

However, given how there's nothing I can find in Apple documentation and the 
fact that it crashes inside of Apple code only sometimes suggests there is a 
bug going on. It might be worth noting that no one on this mailing list has 
come up with any clues about what the problem is suggests to me there is more 
going on than 'you're doing it wrong.' For example, is there sample code from 
Apple with an example? None that I've seen. Also, does anyone else have 
examples of doing what I'm attempting? The code on the interwebs I've seen go 
through rather elaborate subclasses of a collection view layout which I really 
don't want to do, given that Apple is saying this should work.

Also, FWIW, I've had DTS use rather abusive and insulting language after I 
submitted a TSI in very technical, non-emotional terms. Maybe I got unlucky 
with whomever was assigned my TSI but I feel like I have to have my technical 
story extremely solid or I won't get the help I want.

Doug
___

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: Dynamic-width Collection View

[Doug Hill]

> On Aug 10, 2016, at 1:35 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Aug 10, 2016, at 13:29 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> Again, looking for any ideas, pointers, etc. about any of this, including 
>> whether I'm going about this the wrong way.
> 
> This is something that you should use a TSI for. Because collection views 
> have evolved over OS generations, it’s now hard to separate documentation 
> errors from compatibility modes from recommended design and coding practices 
> of various eras. Even if you don’t have a free TSI available, paying for one 
> is likely the best strategy, and the best use of your time.

Quincy,

Thanks for the feedback. I was definitely considering this but I thought I'd 
throw this out to the developer community first so I can at least know I'm not 
missing something obvious. Also, Apple support folk seem to get testy when you 
ask what is considered a "dumb" question. Finally TSI cost money and I don't 
want to waste this valuable resource on something I can find out from the 
community.

Although, this basically means that Apple's documentation is a fail and the 
APIs don't work in a predictable way. Again, this should also be noted so other 
developers don't go through all the trouble I've done to implement very basic 
functionality. Or maybe *hint hint* Apple could update this documentation 
and/or fix these bugs.

Doug Hill
___

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: Dynamic-width Collection View

[Doug Hill]

> On Aug 10, 2016, at 11:10 AM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> I'm currently trying to implement something that seems basic but has been 
> driving me nuts: making a Collection View with cells that are dynamic-width 
> and height at runtime.
> 
> I was able to accomplish this with Table Views by using the dynamic height 
> constant. Following Apple documentation, I set the width of the table view 
> cell in IB to be an arbitrary size, for example using the default 600 pixels. 
> I then use autolayout to make the size/position of the table view subviews 
> adjust to the size of the cell. At runtime, the table view sets the width of 
> the cell, and autolayout can change the height based on the content (e.g. 
> multi-line labels.)
> 
> Now I want to do this using a Collection View. Reading Apple's documentation 
> and watching the relevant WWDC video, it looks like this will be just as 
> easy, right? As is my experience working with Collections, nothing ever comes 
> easy.
> 
> OK, so I do basically the same thing as I was doing with tables.
> 
> • Create a Collection View Controller in a Storyboard.
> • Create a collection view cell in the collection view inside the Storyboard.
> • Make the cell the width of the collection view.
> • Add some labels that fit the width of the cell using autolayout and allow 
> for multiple lines (e.g. dynamic height)
> • Use the default flow layout in IB and set the item size in the flow layout 
> to be something less than the size of the collection view.
> • Make sure section insets are 0.
> • At runtime during viewDidLoad for the collection view controller, set the 
> item size and estimated item size in the flow layout to be something related 
> to the size of collection
> 
> I run this and behold…it crashes. And there are lots of warnings:
> 
> "The behavior of the UICollectionViewFlowLayout is not defined because: the 
> item width must be less than the width of the UICollectionView minus the 
> section insets left and right values, minus the content insets left and right 
> values."
> 
> This is kind of odd since I go through a lot of trouble to make sure the cell 
> item size is not too big. Here is what I see for the item size: Yet the app 
> still crashes due to a cell that is too wide for the collection.
> 
> So, somewhere else the item size is getting set behind my back to something 
> other than what I set in itemSize, estimatedItemSize, cell bounds, etc.
> 
> Before I go any further, I wanted to see if there's an official way to 
> accomplish my goals without doing way more work, that is having to subclass 
> the flow layout class. Should the default flow layout class even be able to 
> do this? I see a lot of different ideas on the interwebs that involve doing 
> things with the flow layout but I'm hesitant to go down that path. Shouldn't 
> this very basic use case be doable without having to get into the complexity 
> of the layout class? Honestly, the documentation for this is terrible. 
> There's a lot of hand-waving and assumptions that don't quite spell out most 
> of the details of this use case.
> 
> Thanks.
> 
> Doug Hill

Digging into this a little deeper, I find this tidbit in Apple documentation

=

UICollectionViewFlowLayout: estimatedItemSize

The default value of this property is CGSizeZero. Setting it to any other value 
causes the collection view to query each cell for its actual size using the 
cell’s preferredLayoutAttributesFittingAttributes: method

=

OK, this makes sense why my cells all ended up with the wrong size. The cell 
class needs to override this method to set the cell's size instead of all the 
other ways I used above.

Remember, my objective is to make the cell width be the same width as the 
collection view itself. Huh, collection cells don't have a reference to the 
collection view it's contained in. Given that I don't know how wide the 
collection view is, I'll pick an arbitrarily small width so at least the app 
won't crash. Let's say 300 pixels. I call the cell's super implementation of 
preferredLayoutAttributesFittingAttributes and then change the frame property 
of the layout attributes it returns.

Progress! The app no longer crashes right away and the collection cells now 
have my adjusted width. I do see a couple of problems though:

1) The height of the cell is wrong
It seems to use the default height of the cell as it is layed out in the 
Storyboard, not the new height of the cell based on my autolayout constraints. 
This is pretty much the entire reason I'm using the estimatedItemSize property 
in the first place; it's supposed to figure this out for itself. Ugh.

As a workaround, I can calculate what the height should be based on the origin 
and height of the multi-line label, 

Dynamic-width Collection View

[Doug Hill]

I'm currently trying to implement something that seems basic but has been 
driving me nuts: making a Collection View with cells that are dynamic-width and 
height at runtime.

I was able to accomplish this with Table Views by using the dynamic height 
constant. Following Apple documentation, I set the width of the table view cell 
in IB to be an arbitrary size, for example using the default 600 pixels. I then 
use autolayout to make the size/position of the table view subviews adjust to 
the size of the cell. At runtime, the table view sets the width of the cell, 
and autolayout can change the height based on the content (e.g. multi-line 
labels.)

Now I want to do this using a Collection View. Reading Apple's documentation 
and watching the relevant WWDC video, it looks like this will be just as easy, 
right? As is my experience working with Collections, nothing ever comes easy.

OK, so I do basically the same thing as I was doing with tables.

• Create a Collection View Controller in a Storyboard.
• Create a collection view cell in the collection view inside the Storyboard.
• Make the cell the width of the collection view.
• Add some labels that fit the width of the cell using autolayout and allow for 
multiple lines (e.g. dynamic height)
• Use the default flow layout in IB and set the item size in the flow layout to 
be something less than the size of the collection view.
• Make sure section insets are 0.
• At runtime during viewDidLoad for the collection view controller, set the 
item size and estimated item size in the flow layout to be something related to 
the size of collection

I run this and behold…it crashes. And there are lots of warnings:

"The behavior of the UICollectionViewFlowLayout is not defined because: the 
item width must be less than the width of the UICollectionView minus the 
section insets left and right values, minus the content insets left and right 
values."

This is kind of odd since I go through a lot of trouble to make sure the cell 
item size is not too big. Here is what I see for the item size: Yet the app 
still crashes due to a cell that is too wide for the collection.

So, somewhere else the item size is getting set behind my back to something 
other than what I set in itemSize, estimatedItemSize, cell bounds, etc.

Before I go any further, I wanted to see if there's an official way to 
accomplish my goals without doing way more work, that is having to subclass the 
flow layout class. Should the default flow layout class even be able to do 
this? I see a lot of different ideas on the interwebs that involve doing things 
with the flow layout but I'm hesitant to go down that path. Shouldn't this very 
basic use case be doable without having to get into the complexity of the 
layout class? Honestly, the documentation for this is terrible. There's a lot 
of hand-waving and assumptions that don't quite spell out most of the details 
of this use case.

Thanks.

Doug Hill
___

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: Justification of collection cells in sections

[Doug Hill]

Hello Peter,

Thanks for the info. I'm still trying to see if I can do what I want with the 
stock flow layout.

FWIW, it appears that the behavior of the flow layout class is to center items 
when there is one section.

This appears to be a summary of the behavior:

Collection has one section:
• Items on each line are centered on the line, including multiple items per 
line.

Collection has multiple sections:
• If one item in the section, center on the line.
• Multiple items per section, flow from left-to-right, including across lines.

I wish the multiple section case was consistent flowing left-to-right.

Doug


> On Aug 3, 2016, at 1:12 PM, Peter Tomaselli <vast.gra...@gmail.com> wrote:
> 
> I remain a non-expert on this topic, but my assumption has always been that 
> the current “look” is by design. Ugly, but by design. “Equally distribute 
> cells across the row” could be taken to mean that in the case of one cell, it 
> belongs in the middle… [shrug]
> 
> This is some of the first Cocoa code I wrote so please forgive… almost 
> everything about it, but here’s the FlowLayout subclass I mentioned: 
> https://github.com/Peterbing/CV-AutoLayout/blob/master/TemplateProject/TheFlowLayout.m#L31
>  
> <https://github.com/Peterbing/CV-AutoLayout/blob/master/TemplateProject/TheFlowLayout.m#L31>
> 
> This is a completely “left-justified” layout and it works by overriding the 
> `layoutAttributesFor*` methods to call super, and then squishes everything 
> over to the left before returning the attributes to the caller. 
> 
> This is certainly not production-quality code but perhaps it’s a start! IIRC 
> there is Apple documentation (or perhaps it was a WWDC session) about 
> creating a simple “tweaked” UICollectionViewFlowLayout subclass — so my 
> impression is that this approach in general is kosher.
> 
> On Wed, Aug 3, 2016 at 3:38 PM, Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
> So, does anyone know if the current behavior I mentioned is a bug? Is the 
> behavior of Flow Layout documented? Should I file a bug with Apple?
> 
> Also, what would be some quick ways to modify the flow layout behavior to 
> handle this case with one item per section?
> 
> Doug Hill

___

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: Justification of collection cells in sections

[Doug Hill]

So, does anyone know if the current behavior I mentioned is a bug? Is the 
behavior of Flow Layout documented? Should I file a bug with Apple?

Also, what would be some quick ways to modify the flow layout behavior to 
handle this case with one item per section?

Doug Hill

> On Aug 2, 2016, at 6:11 PM, Peter Tomaselli <vast.gra...@gmail.com> wrote:
> 
> I’ve been in the same situation too (wanting a “left-justified” flow layout) 
> and the only way I am aware of to tackle it is to subclass 
> UICollectionViewFlowLayout and tweak the frames yourself. Luckily this is not 
> nearly as complicated as handling the whole layout yourself!
> 
> Peter
> 
> On Aug 2, 2016, at 7:51 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
>> I was hoping to allow the Flow Layout to handle this rather than me handling 
>> the layout. Given how the layout works for multiple items in a section, I 
>> would presume there is some way to make this work the same for a single item 
>> in a section. Am I wrong?
>> 
>> Doug Hill
> 


___

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: Justification of collection cells in sections

[Doug Hill]

Raglan,

Thanks for the response.

I was hoping to allow the Flow Layout to handle this rather than me handling 
the layout. Given how the layout works for multiple items in a section, I would 
presume there is some way to make this work the same for a single item in a 
section. Am I wrong?

Doug Hill


> On Aug 2, 2016, at 4:41 PM, Raglan T. Tiger <r...@crusaderrabbit.net> wrote:
> 
> 
>> 
>> Any ideas on how to make the single item section flow from left to right 
>> rather than centered?
> 
> Accessing the Layout Attributes 
> <https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionViewLayoutAttributes_class/index.html#//apple_ref/doc/uid/TP40012183-CH1-SW2>
>  <> <> <> <> <>frame
>  
> <https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionViewLayoutAttributes_class/index.html#//apple_ref/occ/instp/UICollectionViewLayoutAttributes/frame>
>  Property
>  <> <> <> <> <>bounds
>  
> <https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionViewLayoutAttributes_class/index.html#//apple_ref/occ/instp/UICollectionViewLayoutAttributes/bounds>
>  Property
>  <> <> <> <> <>center
>  
> <https://developer.apple.com/library/ios/documentation/UIKit/Reference/UICollectionViewLayoutAttributes_class/index.html#//apple_ref/occ/instp/UICollectionViewLayoutAttributes/center>
>  Property
___

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

Justification of collection cells in sections

[Doug Hill]

I'm trying to display a list of items in a UICollectionView. I have multiple 
sections for these items and a fixed cell width but dynamic height. I'm using 
the standard flow layout. The items are layed out in three columns by setting 
the estimated item size and auto-layout constraints. My collection view 
delegate/data source is extremely basic: I implement 
numberOfSectionsInCollectionView, numberOfItemsInSection, and 
cellForItemAtIndexPath with almost nothing except the bare minimum. I return a 
fixed number of sections and a variable number of items in each section based 
on a data model. cellForItemAtIndexPath dequeues one cell type and changes the 
text on two labels in the cell.

Now the funniness: When there is more than one item in a section, the cells 
fill in the space from left to right, flowing across multiple lines as needed. 
However, if there is one item in a section, it lays out that cell in the center 
of the collection view. This looks really weird and breaks up the flow.

Here is an ascii rendering of what this looks like:

-
|   |
|  Section 1   |
|  [cell 0]--[cell 1]---[cell 2]  |
|  [cell 3]   |
|   |
|  Section 2   |
| --- [cell 0]--|
|   |
|  Section 3   |
|  [cell 0]--[cell 1]- |
|   |
| Section 4|
| --- [cell 0]--|
|   |
-

Notice in section 2 and 4, the only cell is layed out in the middle of the 
collection view, while the cells in the other sections flow from left to right.

Any ideas on how to make the single item section flow from left to right rather 
than centered?

Thanks.

Doug Hill
___

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: Vertical orientation of UISlider

[Doug Hill]

A rotate transform will work fine if you don't have any customizations. For 
example, a thumb, min/max image will end up being rotated as well, so you'll 
need to transform those too.

Doug

On Jul 20, 2016, at 11:55 AM, Jeff Kelley  wrote:
> 
> Hi Carl,
> 
>   Have you tried applying a transform to the slider? A simple rotation 
> should do the trick.
> 
> 
> Jeff Kelley
> 
> slauncha...@gmail.com | @SlaunchaMan  | 
> jeffkelley.org 
>> On Jul 20, 2016, at 11:48 AM, Carl Hoefs  
>> wrote:
>> 
>> iOS 9
>> 
>> Is there a way to change the orientation of a UISlider to vertical instead 
>> of horizontal?
>> 
>> -Carl
> ___


___

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

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

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

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

Re: Hello. Is there a way to stop Apple CrashReporter from collecting crashes of my process?

[Doug Hill]

Maybe you could strip symbols from your binary? This would at least stop 
private info from being shown to the user.
You mgiht also remove any logging statements from your shipping binary if that 
also exposes private information.

Doug Hill

> On Jul 11, 2016, at 7:04 AM, Motti Shneor <motti.shn...@me.com> wrote:
> 
> Hi.
> 
> I develop a global daemon, maintained by launchd. Obviously It cannot be 
> distributed in the Mac App Store. To collect crash-reports from customers, I 
> integrated a mainstream 3rd party crash reporter library (PLCrashReporter). I 
> collect crashes of our daemon, and send them for analysis,  and all is well.
> 
> However, when crash happens, the user can still see a line in the Console 
> “All Messages” section, and also see the full crash-report in the “System 
> Diagnostic Reports”. I would want to avoid this, and disable this 
> crash-reporting that is unusable to me, and exposes private info about my 
> program  (I’m writing a security tool).
> 
> I could not find any process-specific behavior of CrashReporter. The only 
> thing I could find is how to stop the crash-reporter altogether from 
> collecting crashes. (see man ReportCrash) - and of course I don’t want this.
> 
> Is it possible at all to stop CrashReporter from collecting just MY crashes? 
> how? Is there a runtime API (xpc or other) to control CrashReporter behavior? 
> Any filtering mechanism?
> 
> Any hint will be greatly appreciated.
> 
> Thanks! 
> 
> Motti Shneor

___

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: Emailing from a daemon process

[Doug Hill]

Another thing to bring up is that users may not want an open Sendmail server 
running on their machine just so a background process can send email without 
the user's intervention. Huh, this is almost like what malware does.

Doug Hill

> On Jul 7, 2016, at 10:46 AM, Jens Alfke <j...@mooseyard.com> wrote:
> 
> 
>> On Jul 7, 2016, at 10:01 AM, Carl Hoefs <newsli...@autonomy.caltech.edu> 
>> wrote:
>> 
>> I seem to recall that in the distant past I accomplished issuing emails from 
>> a daemon process on Linux by directly interfacing to /usr/sbin/sendmail. Is 
>> this the 'Postfix mail tools' you mentioned?
> 
> Yes, and sendmail on macOS is just a front-end to the Postfix system. The 
> trouble is that Postfix isn’t actually configured, so it looks like all 
> sendmail will do is write the email to a mail queue that’s not being 
> processed by anything. (You can read the main page for sendmail for details.)
> 
> You can set up Postfix without much trouble, but I assume you want your 
> daemon to work on anyone’s machine without them having to spend 5 minutes 
> mucking about with command-line tools first...
> 
> —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/cocoadev%40breaqz.com
> 
> This email sent to cocoa...@breaqz.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: Scrolling table view when the keyboard appears

[Doug Hill]

> On May 24, 2016, at 4:38 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> 
>> On May 24, 2016, at 3:48 PM, Kyle Sluder <k...@ksluder.com> wrote:
>> 
>> On Tue, May 24, 2016, at 05:46 PM, Kyle Sluder wrote:
>>> On Tue, May 24, 2016, at 05:37 PM, Alex Zavatone wrote:
>>>> 
>>>> On May 24, 2016, at 4:02 PM, Kyle Sluder wrote:
>>>> 
>>>>> On Tue, May 24, 2016, at 12:33 PM, Doug Hill wrote:
>>>>>> OK, this might have been more obvious to people, but it finally came to
>>>>>> me how to handle the keyboard display.
>>>>>> 
>>>>>> Instead of changing the view size, I move the center of the view up, then
>>>>>> apply a content inset to the table to adjust for the part of the table
>>>>>> offscreen. Animations seem to work much better now.
>>>>> 
>>>>> Did you really mean “move the center of the view”? Or did you mean
>>>>> scrolling the center of the viewport?
>>>>> 
>>>>> Either way, contentInset is definitely the way to handle this.
>>>> 
>>>> Just checking.  You meant to use contentInset and not contentOffset? 
>>> 
>>> Yes, I meant contentInset. contentOffset is just another name for
>>> self.bounds.origin.
>> 
>> To clarify: you might want to change both the contentInset (to avoid the
>> keyboard) *and* the contentOffset (to move content that has been
>> obscured by the keyboard back into the visible part of the scrollview.)
>> 
>> --Kyle Sluder
> 
> Thanks for the tip, I’ll try that too.

OK, now I remember why I adjusted the center rather than the content offset. I 
have an aggregate view with a table and a text input field. The text input 
field is outside of the table since I don’t want it to scroll with the table. 
So, I move the aggregate view up as a single unit to be out of the way of the 
keyboard.

Doug Hill
___

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: Scrolling table view when the keyboard appears

[Doug Hill]

> On May 24, 2016, at 3:48 PM, Kyle Sluder <k...@ksluder.com> wrote:
> 
> On Tue, May 24, 2016, at 05:46 PM, Kyle Sluder wrote:
>> On Tue, May 24, 2016, at 05:37 PM, Alex Zavatone wrote:
>>> 
>>> On May 24, 2016, at 4:02 PM, Kyle Sluder wrote:
>>> 
>>>> On Tue, May 24, 2016, at 12:33 PM, Doug Hill wrote:
>>>>> OK, this might have been more obvious to people, but it finally came to
>>>>> me how to handle the keyboard display.
>>>>> 
>>>>> Instead of changing the view size, I move the center of the view up, then
>>>>> apply a content inset to the table to adjust for the part of the table
>>>>> offscreen. Animations seem to work much better now.
>>>> 
>>>> Did you really mean “move the center of the view”? Or did you mean
>>>> scrolling the center of the viewport?
>>>> 
>>>> Either way, contentInset is definitely the way to handle this.
>>> 
>>> Just checking.  You meant to use contentInset and not contentOffset? 
>> 
>> Yes, I meant contentInset. contentOffset is just another name for
>> self.bounds.origin.
> 
> To clarify: you might want to change both the contentInset (to avoid the
> keyboard) *and* the contentOffset (to move content that has been
> obscured by the keyboard back into the visible part of the scrollview.)
> 
> --Kyle Sluder

Thanks for the tip, I’ll try that too.

Doug
___

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: Scrolling table view when the keyboard appears

[Doug Hill]

> On May 24, 2016, at 1:02 PM, Kyle Sluder <k...@ksluder.com> wrote:
> 
> On Tue, May 24, 2016, at 12:33 PM, Doug Hill wrote:
>> OK, this might have been more obvious to people, but it finally came to
>> me how to handle the keyboard display.
>> 
>> Instead of changing the view size, I move the center of the view up, then
>> apply a content inset to the table to adjust for the part of the table
>> offscreen. Animations seem to work much better now.
> 
> Did you really mean “move the center of the view”? Or did you mean
> scrolling the center of the viewport?
> 
> Either way, contentInset is definitely the way to handle this.
> 
> --Kyle Sluder

When the keyboard comes up, I was trying to adjust the height of the view to be 
smaller so that it would move out of the way of the keyboard. This had a 
disadvantage of not keep the scroll offset, e.g. content offset. That is, if 
the table is scrolled to the bottom, adjusting the height will hide the last 
rows of the table but not keep the scroll area there.


Instead, I decided to move the view out of the way of the keyboard by adjusting 
the center. This has the advantage of not adjusting the content offset. That 
is, the table is scrolled to the same row. However, after the view is moved, 
part of it will be clipped by the superview since the view was moved above the 
origin of the superview. Adjusting the content inset of the table view will 
cause the content to move down so that it won’t be clipped. And scrolling will 
stop at the first row in the table.

Doug Hill

>> 
>> Doug Hill
>> 
>>> On May 20, 2016, at 5:21 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>>> 
>>> I’m implementing a chat message view with a table view and a text field 
>>> underneath it. I want the most recent messages at the bottom, and the 
>>> scroll position always to stay at the last row in the table.
>>> 
>>> There are some tricks to making sure the table scrolls to the bottom when 
>>> it’s first drawn and when adding new rows. I seem to be able to make this 
>>> work but I’m running into a problem keeping the table scrolled to the 
>>> bottom when the keyboard is shown. I listen for the 'keyboard shown’ 
>>> notification and adjust the height of my entire view by the height of 
>>> keyboard. This works but the scroll position ends up wrong, as it doesn’t 
>>> keep the same scroll position at the last row when the view is moved up. 
>>> OK, so I set the contentOffset to compensate for this.
>>> 
>>> Here is the code I use in the Keyboard Will show notification:
>>> 
>>> [UIView animateWithDuration:keyboardAnimDuration
>>> animations:
>>> ^{
>>>   self.view.frame = newViewFrame;
>>> }
>>> completion:^(BOOL finished)
>>> {
>>>   [self.myTableView setContentOffset:newContentOffset animated:NO];
>>> }];
>>> 
>>> So far, things work pretty well and things end up in the right place with. 
>>> However, the animation is weird.
>>> 
>>> • Even though the view frame is changed inside the animation block, it 
>>> moves into place immediately with no animation. No matter what duration I 
>>> set it seems to be ignored.
>>> • Then the keyboard scrolls into place. Because my view has already been 
>>> moved up, you see a blank space where the keyboard moves up and over. This 
>>> looks pretty bad.
>>> • The table scrolls with an animation even though contentOffset is changed 
>>> in the completion block and I set the animated param to NO.
>>> • The time for the table scroll to animate is fixed.
>>> 
>>> Here is an example of this animation:
>>> 
>>> https://youtu.be/SBSts2UOJXw
>>> 
>>> (Try on slow speed to see it better)
>>> 
>>> I know this can be done correctly because I see other iOS chat apps that 
>>> make the list view move up with the keyboard in a coordinated, smooth 
>>> animation. Any ideas?
>>> 
>>> Doug
>>> 
>>> ___
>>> 
>>> 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/cocoadev%40breaqz.com
>>> 
>>> This email sent to cocoa...@breaqz.com
>> 
>> 
>> ___
>> 
>

Re: Scrolling table view when the keyboard appears

[Doug Hill]

OK, this might have been more obvious to people, but it finally came to me how 
to handle the keyboard display.

Instead of changing the view size, I move the center of the view up, then apply 
a content inset to the table to adjust for the part of the table offscreen. 
Animations seem to work much better now.

Doug Hill

> On May 20, 2016, at 5:21 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
> I’m implementing a chat message view with a table view and a text field 
> underneath it. I want the most recent messages at the bottom, and the scroll 
> position always to stay at the last row in the table.
> 
> There are some tricks to making sure the table scrolls to the bottom when 
> it’s first drawn and when adding new rows. I seem to be able to make this 
> work but I’m running into a problem keeping the table scrolled to the bottom 
> when the keyboard is shown. I listen for the 'keyboard shown’ notification 
> and adjust the height of my entire view by the height of keyboard. This works 
> but the scroll position ends up wrong, as it doesn’t keep the same scroll 
> position at the last row when the view is moved up. OK, so I set the 
> contentOffset to compensate for this.
> 
> Here is the code I use in the Keyboard Will show notification:
> 
> [UIView animateWithDuration:keyboardAnimDuration
> animations:
> ^{
>self.view.frame = newViewFrame;
> }
> completion:^(BOOL finished)
> {
>[self.myTableView setContentOffset:newContentOffset animated:NO];
> }];
> 
> So far, things work pretty well and things end up in the right place with. 
> However, the animation is weird.
> 
> • Even though the view frame is changed inside the animation block, it moves 
> into place immediately with no animation. No matter what duration I set it 
> seems to be ignored.
> • Then the keyboard scrolls into place. Because my view has already been 
> moved up, you see a blank space where the keyboard moves up and over. This 
> looks pretty bad.
> • The table scrolls with an animation even though contentOffset is changed in 
> the completion block and I set the animated param to NO.
> • The time for the table scroll to animate is fixed.
> 
> Here is an example of this animation:
> 
> https://youtu.be/SBSts2UOJXw
> 
> (Try on slow speed to see it better)
> 
> I know this can be done correctly because I see other iOS chat apps that make 
> the list view move up with the keyboard in a coordinated, smooth animation. 
> Any ideas?
> 
> Doug
> 
> ___
> 
> 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/cocoadev%40breaqz.com
> 
> This email sent to cocoa...@breaqz.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

Scrolling table view when the keyboard appears

[Doug Hill]

I’m implementing a chat message view with a table view and a text field 
underneath it. I want the most recent messages at the bottom, and the scroll 
position always to stay at the last row in the table.

There are some tricks to making sure the table scrolls to the bottom when it’s 
first drawn and when adding new rows. I seem to be able to make this work but 
I’m running into a problem keeping the table scrolled to the bottom when the 
keyboard is shown. I listen for the 'keyboard shown’ notification and adjust 
the height of my entire view by the height of keyboard. This works but the 
scroll position ends up wrong, as it doesn’t keep the same scroll position at 
the last row when the view is moved up. OK, so I set the contentOffset to 
compensate for this.

Here is the code I use in the Keyboard Will show notification:

[UIView animateWithDuration:keyboardAnimDuration
animations:
^{
self.view.frame = newViewFrame;
}
completion:^(BOOL finished)
{
[self.myTableView setContentOffset:newContentOffset animated:NO];
}];

So far, things work pretty well and things end up in the right place with. 
However, the animation is weird.

• Even though the view frame is changed inside the animation block, it moves 
into place immediately with no animation. No matter what duration I set it 
seems to be ignored.
• Then the keyboard scrolls into place. Because my view has already been moved 
up, you see a blank space where the keyboard moves up and over. This looks 
pretty bad.
• The table scrolls with an animation even though contentOffset is changed in 
the completion block and I set the animated param to NO.
• The time for the table scroll to animate is fixed.

Here is an example of this animation:

https://youtu.be/SBSts2UOJXw

(Try on slow speed to see it better)

I know this can be done correctly because I see other iOS chat apps that make 
the list view move up with the keyboard in a coordinated, smooth animation. Any 
ideas?

Doug

___

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: Recurrent background thread

[Doug Hill]

I’ve had luck using dispatch queues to accomplish recurring events, 
specifically dispatch_after. For example:

- (void) doStuffAfterDelay
{
   dispatch_queue_t theQueue = dispatch_queue_create("Recurring work queue", 
DISPATCH_QUEUE_SERIAL);
dispatch_time_t futureTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(1 * 
NSEC_PER_SEC));
dispatch_after(futureTime, theQueue,
^{
DoStuff();

[self doStuffAfterDelay];
;});
}

You can also use an NSTimer that repeats, such as:

NSTimeInterval delaySecs = 5;
self.timer = [NSTimer scheduledTimerWithTimeInterval:delaySecs
target:self selector:@selector(doStuff:)
userInfo:nil repeats:YES];

Hope this helps.

Doug Hill


> On May 13, 2016, at 12:34 PM, Carl Hoefs <newsli...@autonomy.caltech.edu> 
> wrote:
> 
> I want a method running on a background thread to reissue itself after it is 
> done processing. How can I do this?
> 
> I'm using the following code but it runs just once and is never heard from 
> again...
> 
>// initial invocation from main thread
>[self performSelectorInBackground:@selector(_checkSensor:) withObject:@50];
> 
> 
> // target method on background thread
> -(void)_checkSensor:(NSNumber *)delaySecs
> {
>// check sensor...
>// processing...
> 
>// reschedule
>[NSObject cancelPreviousPerformRequestsWithTarget:self selector:_cmd 
> object:nil];
>[self performSelector:_cmd withObject:nil afterDelay: delaySecs];
> }
> 
> As a test, the above works if run on the main thread, so I'm guessing it has 
> something to do with there being no runloop after the background thread 
> exits. 
> -Carl
___

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

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

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

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

Re: Move views relative to other view with Autolayout

[Doug Hill]

> On Mar 10, 2016, at 1:35 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 
> On Mar 10, 2016, at 3:21 PM, Doug Hill <cocoa...@breaqz.com> wrote:
>> 
>> I can see that people use multiple constraints when moving between different 
>> layouts. But what I don’t get is how there can be an alignment constraint 
>> that doesn’t cause a layout update when views move? How does autolayout 
>> decide to use the constraint when originally laying out the view but ignores 
>> it when the view layout changes? Apparently I don’t understand this very 
>> well but the docs don’t seem to go out of their way to describe this 
>> difference either.
> 
> When using auto layout, the auto layout engine _determines_ the layout from 
> the constraints.  You can't change the layout other than by changing the 
> constraints.  You should not move a view by setting its frame or bounds or 
> whatnot.  If you do, the change will only be undone on the next layout pass, 
> anyway.  The "current" position of views is not an input to the auto layout 
> system.  The position of all views is an _output_ from that system.
> 
> Regards,
> Ken

Ken,

Thanks for the info, that really does explain it. I guess the biggest problem I 
have with autolayout is I know a view layout I want, but trying to come up with 
the constraints to produce that layout is non-obvious in most cases. It would 
be nice if one could use a final view state as the input to the layout engine 
and have it come up with the constraints that will produce it. I also 
understand this is probably not an easy problem to solve but still…

Given this, I’m now working on a new solution to moving my views together. 
Instead of aligning the origin of my views to the container or each other, I 
create another view for alignment. I then set the origin of the alignment view 
(e.g. leading) by autolayout constraints to the superview. Then my other views 
set alignment constraints to this view. I then change the leading constraint on 
the alignment view and the other views move with it. This allows me to change 
one constraint value and cause the other views to update automatically.

Thanks again for the responses.

Doug Hill
___

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: Move views relative to other view with Autolayout

[Doug Hill]

Unfortunately, we have an iOS 8 requirement so we can’t use stack views.

I can see that people use multiple constraints when moving between different 
layouts. But what I don’t get is how there can be an alignment constraint that 
doesn’t cause a layout update when views move? How does autolayout decide to 
use the constraint when originally laying out the view but ignores it when the 
view layout changes? Apparently I don’t understand this very well but the docs 
don’t seem to go out of their way to describe this difference either.

Thanks.

Doug Hill

> On Mar 10, 2016, at 1:15 PM, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Mar 10, 2016, at 12:59 , Doug Hill <cocoa...@breaqz.com 
> <mailto:cocoa...@breaqz.com>> wrote:
>> 
>> I set up an auto layout constraint so that an another view is a fixed number 
>> of pixels from the side view. I then want to move the origin of the side 
>> view and have the other view move with it.
>> 
>> If I set up an alignment constraint so trailing space from my first view to 
>> the side view is a fixed number of pixels. Let’s say 20 pixels. When I move 
>> the origin of the side view, the first view doesn’t keep the 20 pixel 
>> spacing. In fact does nothing.
> 
> Isn’t the issue what constraints you’ve put on the side view?
> 
> When using autolayout, you can’t “move the origin” of a view, except by 
> adjusting constraints programmatically. You have to come up with a set of 
> constraints that describes the relationship of the views in both 
> configuration (side view visible or not). You might be able to do this by 
> adding conflicting constraints to the first view (trailing to side view, 
> trailing to superview), then enable one constraint and disable the other. To 
> change configurations, toggle both enable properties and setNeedsLayout.
> 
> The easy way to do this, of course, is to use a horizontal stack view 
> (NSStackView, UIStackView), since that handles hiding and showing of views 
> without explicit constraints. NSStackView has been around since OS X 10.9 but 
> real autolayout compatibility only came in 10.11, UIStackView has been around 
> since iOS 9.0.
> 

___

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

Move views relative to other view with Autolayout

[Doug Hill]

I’m trying to implement a side panel that moves into place horizontally and 
push content over when it is shown. I set up an auto layout constraint so that 
an another view is a fixed number of pixels from the side view. I then want to 
move the origin of the side view and have the other view move with it.

If I set up an alignment constraint so trailing space from my first view to the 
side view is a fixed number of pixels. Let’s say 20 pixels. When I move the 
origin of the side view, the first view doesn’t keep the 20 pixel spacing. In 
fact does nothing.

Looking at the Googles, I see a number of cases where people try to handle this 
situation by doing one of the following:

• Creating another constraint from the first view to the superview margin. They 
then disable to first constraint to side view and and enable the alignment 
constraint to the superview margin.

• Manually change the value of the alignment constraint to the side view.

Neither seem all that satisfactory. I guess I’m wondering why the original 
alignment constraint doesn’t allow for dynamic changes to the view layout. Why 
won’t autolayout cause the views to layout again when views move?
FYI, I tried calling ‘updateConstraintsIfNeeded’ on all these view after 
changing the side view origin and this seems to have no effect.

I also checked Apple’s Autolayout programming guide and didn’t find anything 
that would answer this question. Thanks for any info/pointers about this.

Doug
___

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: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?

[Doug Hill]

Alex,

I guess I tried to make the distinction between Cocoa Bindings and language 
bindings, but I was referring to this.

https://en.wikipedia.org/wiki/Language_binding 
<https://en.wikipedia.org/wiki/Language_binding>

This is a general concept to bridge multiple languages.

The idea is that none of the bindings are automatic, you have to write them 
yourself. So, you would need to analyze the C library and figure out a set of 
interfaces in Objective-C that gives Obj-C developers access to that library.

Just as a hypothetical example (as I don’t have the knowledge or time to look 
up the SIP library you mentioned), let’s say the C library had the following 
functions:

SIPRef   CreateSIPRef(void);
voidDialNumber(SIPRef sipRef,  char *phoneNumber);

Then your Objective-C interface would be something like:

@interface SIPDialer

@private
SIPRef  privSIPRef;

- (instancetype) init;
- (void) dialNumber( NSString *phoneNumber);
@end

The implementation would do something like:

@implementation SIPDialer

- (instancetype) init
{
self = [super init];
if( self )
{
self.privSIPRef = CreateSIPRef();
}
return self;
}

- (void) dialNumber( NSString *phoneNumber)
{
char *cStrPhoneNumber = [phoneNumber cStringUsingEncoding: 
NSUTF8StringEncoding];
DialNumber( self.privSIPRef, cStrPhoneNumber);
}

@end

I think you get the general idea (ignore any typos or syntax errors, I’m just 
typing in my email here). Obviously you would also have to deal with all kinds 
of error handling and possibly exception handling. 

Good luck!

Doug Hill


> On Mar 4, 2016, at 3:36 PM, Alex Zavatone <z...@mac.com> wrote:
> 
> I guess I neglected to mention this was on iOS.
> 
> Your words make me happy to see that I’m at least thinking along a similar 
> line.  Basically, your class is a glue layer or a translation layer between 
> the C and Obj-C worlds.
> 
> Now, I love the concept of bindings, but iOS, since bindings aren’t 
> available, how would you suggest I approach the issue of the C method knowing 
> the appropriate Obj-C class to provide the response to.  
> 
> I’m afraid I’ve been insulated from the world of pointers in my time on iOS, 
> so I’m not rusty there, more than I am ignorant to those issues.
> 
> Thanks,
> 
> Alex Zavatone
> 
> On Mar 4, 2016, at 5:11 PM, Doug Hill <cocoa...@breaqz.com> wrote:
> 
>> The approach I took for my wrapper library was using bindings. Not the Cocoa 
>> type, but the language type. I created a series of Objective-C classes that 
>> serve as the Obj-C interface to the Cocoa developer. The Obj-C classes would 
>> make calls into the C/C++ libraries and do conversions between C/C++ types 
>> to Obj-C. For example the C-string to NSString conversion. This way, a 
>> convenient Objective-C framework could be created that Cocoa developers 
>> could use very easily. C arrays were converted to Foundation NSArrays, etc. 
>> There was also conversions of C++ exceptions to Obj-C exceptions, although 
>> this might be unified in CLang/LLVM.
>> Since I was wrapping a C++ library, I made up some special bindings that 
>> allowed me to call into C++ objects via templates and some special sauce 
>> that allowed us to store method pointers and call into them from any 
>> platform/language. This is probably more work than is needed though.
>> 
>> Anyways, I didn’t use delegates, notifications, etc. The easiest way to 
>> integrate these wrappers into your app is to have a pure Objective-C 
>> interface and do all work inside those, but probably the most effort to 
>> write.
>> 
>> Doug Hill
>> 
>>> On Mar 4, 2016, at 1:14 PM, Alex Zavatone <z...@mac.com> wrote:
>>> 
>>> Great!  It certainly does… but here's where my brain breaks.
>>> 
>>> The call is originating from the C lib and within the C function.  I am not 
>>> calling the C function from Objective-C.
>>> 
>>> I'm looking at somehow passing this as a string (UTF-8, yep) back to an OC 
>>> class instance, so this implies either a callback or some reference to the 
>>> OC instance that that cares about the response and a means to get that 
>>> message to it.
>>> 
>>> If this is as simple as setting up a callback or a pointer reference, from 
>>> the c class to the OC instance?  Is it sane programming for the C class to 
>>> have more than one callback to different OC object instances?
>>> 
>>> I was thinking one for data and one for method calls for organizational 
>>> purposes.
>>> 
>>> Or should there be one layer that serves as a clearly defined API to create 
>>> a walled garden between the OC world and

Re: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?

[Doug Hill]

The approach I took for my wrapper library was using bindings. Not the Cocoa 
type, but the language type. I created a series of Objective-C classes that 
serve as the Obj-C interface to the Cocoa developer. The Obj-C classes would 
make calls into the C/C++ libraries and do conversions between C/C++ types to 
Obj-C. For example the C-string to NSString conversion. This way, a convenient 
Objective-C framework could be created that Cocoa developers could use very 
easily. C arrays were converted to Foundation NSArrays, etc. There was also 
conversions of C++ exceptions to Obj-C exceptions, although this might be 
unified in CLang/LLVM.
Since I was wrapping a C++ library, I made up some special bindings that 
allowed me to call into C++ objects via templates and some special sauce that 
allowed us to store method pointers and call into them from any 
platform/language. This is probably more work than is needed though.

Anyways, I didn’t use delegates, notifications, etc. The easiest way to 
integrate these wrappers into your app is to have a pure Objective-C interface 
and do all work inside those, but probably the most effort to write.

Doug Hill

> On Mar 4, 2016, at 1:14 PM, Alex Zavatone <z...@mac.com> wrote:
> 
> Great!  It certainly does… but here's where my brain breaks.
> 
> The call is originating from the C lib and within the C function.  I am not 
> calling the C function from Objective-C.
> 
> I'm looking at somehow passing this as a string (UTF-8, yep) back to an OC 
> class instance, so this implies either a callback or some reference to the OC 
> instance that that cares about the response and a means to get that message 
> to it.
> 
> If this is as simple as setting up a callback or a pointer reference, from 
> the c class to the OC instance?  Is it sane programming for the C class to 
> have more than one callback to different OC object instances?
> 
> I was thinking one for data and one for method calls for organizational 
> purposes.
> 
> Or should there be one layer that serves as a clearly defined API to create a 
> walled garden between the OC world and the C interface to the compiled C lib? 
>  
> 
> I'm working with PJSIP and PJ's docs clearly state, "we are going to crater 
> unless you do everything SIP related on the main thread."  The code that I am 
> rewriting replacing has nasty try/catch clauses and forces many operations to 
> the main thread just in case they call PJSIP operations - which clearly makes 
> for a sucky user experience and really clunky application architecture.
> 
> I'm looking to avoid that nastiness by starting from ground zero so that we 
> can wrap a solidly conceived architecture around a neatly walled off 
> interface layer to PJSIP.
> 
> 
> Would it make sense to send a notification from the C method to an 
> Objective-C object to get the value from the C class?  Then I'd need to worry 
> about storing it,  that seems clunky and too involved just to return a string.
> 
> Thank you, sir.  Loads for me to learn here.  
> 
> Alex Zavatone
> 
> 
> 
> On Mar 4, 2016, at 3:48 PM, Doug Hill wrote:
> 
>> Alex,
>> 
>> I’ve worked on a few wrapper libraries, so I have some experience with this.
>> 
>> In your Obj-C wrapper, you would need to create the NSString yourself. So, 
>> if you have a C function:
>> 
>> char* MyCFunc(void);
>> 
>> The Objective-C wrapper method would do something like:
>> 
>> - (void) myObjcMethod
>> {
>>   char* cStr = MyCFunc();
>>   NSString* objcStr = [[NSString alloc] initWithUTF8String:cStr];
>> 
>>   return objCStr;
>> }
>> 
>> Depending on the C function implementation, you might have to deal with 
>> releasing the C string in your wrapper. Also, I assume UTF-8 encoding, which 
>> may or may not be true.
>> 
>> Hopefully this helps you.
>> 
>> Doug Hill
>> 
>> 
>>> On Mar 4, 2016, at 12:07 PM, Alex Zavatone <z...@mac.com> wrote:
>>> 
>>> I'm in the middle of some fun where there is a wrapper class to a lib 
>>> that's written in C and the c function has a char string that I'd like to 
>>> return back to or somehow pass on to an Cbjective-C class.
>>> 
>>> I'm sure there is an established practice for performing this type of task, 
>>> but while I have the opportunity to do this, I'd like to start be learning 
>>> the right way to handle this operation.
>>> 
>>> I've seen really poor use of a catch all delegate for this approach, but am 
>>> pretty unsure on viable and safe methods to handle this.
>>> 
>>> Any tips to how to handle this?
>>> 
>>> Thanks in advance,
>>> 
>>> Alex Zavatone
>> 
>> 
> 


___

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: Returning a string value from a c function to a Objective-C class method. Is there an approved approach?

[Doug Hill]

Alex,

I’ve worked on a few wrapper libraries, so I have some experience with this.

In your Obj-C wrapper, you would need to create the NSString yourself. So, if 
you have a C function:

char* MyCFunc(void);

The Objective-C wrapper method would do something like:

- (void) myObjcMethod
{
char* cStr = MyCFunc();
NSString* objcStr = [[NSString alloc] initWithUTF8String:cStr];

return objCStr;
}

Depending on the C function implementation, you might have to deal with 
releasing the C string in your wrapper. Also, I assume UTF-8 encoding, which 
may or may not be true.

Hopefully this helps you.

Doug Hill


> On Mar 4, 2016, at 12:07 PM, Alex Zavatone <z...@mac.com> wrote:
> 
> I'm in the middle of some fun where there is a wrapper class to a lib that's 
> written in C and the c function has a char string that I'd like to return 
> back to or somehow pass on to an Cbjective-C class.
> 
> I'm sure there is an established practice for performing this type of task, 
> but while I have the opportunity to do this, I'd like to start be learning 
> the right way to handle this operation.
> 
> I've seen really poor use of a catch all delegate for this approach, but am 
> pretty unsure on viable and safe methods to handle this.
> 
> Any tips to how to handle this?
> 
> Thanks in advance,
> 
> Alex Zavatone



___

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: Confusion with copyWithZone and Archiving

[Doug Hill]

> On Feb 29, 2016, at 2:37 PM, Graham Cox <graham@bigpond.com> wrote:
> 
> 
>> On 1 Mar 2016, at 1:58 AM, Dave <d...@looktowindward.com> wrote:
>> 
>> @interface LTWBaseClass : NSView <NSCoding,NSCopying>
> 
> 
>> Do I need to call the super version of this method too?
> 
> 
> 
> In general, yes. But NSView doesn’t conform to NSCopying, so there is no 
> super to call. You’ll have to do all of the copying needed to copy the 
> underlying view.

Given the amount of private implementation in NSView, my guess is that copying 
an NSView yourself without super support would be difficult/impossible in 
practice. However, I would be interested in others with more information to 
give an opinion.

Doug Hill
___

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: Confusion with copyWithZone and Archiving

[Doug Hill]

From the NSCopying protocol reference:

If a subclass inherits NSCopying from its superclass and declares additional 
instance variables, the subclass has to override copyWithZone: to properly 
handle its own instance variables, invoking the superclass’s implementation 
first.

There are many other good tidbits of info in there, check it out and hopefully 
it will cover what you want to know.

Doug Hill


> On Feb 29, 2016, at 6:58 AM, Dave <d...@looktowindward.com> wrote:
> 
> Hi,
> 
> I have an inheritance chain Classes that are NSCoding and NSCopying compliant 
> like so:
> 
> 
> @interface LTWBaseClass : NSView <NSCoding,NSCopying>
> 
> @interface LTWSubclassA : LTWBaseClass <NSCoding,NSCopying>
> 
> @interface LTWSubclassB : LTWSubclassA <NSCoding,NSCopying>
> 
> Each of these three classes contain properties that need to be archived and 
> unarchived. In initWithCoder and encodeWithCoder methods I call [super 
> initWithCoder] and  [super encodeWithCoder], but I’m not sure what to do for 
> copyWithZone? Do I need to call the super version of this method too?
> 
> Thanks a lot, All the Best
> Dave
___

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

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

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

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

Re: How to know if an NSView has pending draws

[Doug Hill]

Jeff,

I was wondering, are you attempting to sync the drawing with the music, or is 
this a performance issue you’re seeing?

Doug Hill


> On Feb 4, 2016, at 3:52 PM, Jeff Evans <jev...@ars-nova.com> wrote:
> 
> Clark, it's a music app; a piece is composed and placed on the screen; 
> there's a lot of massaging going on as the music adjusts visually. I want the 
> play of the example to begin once there are no more updates remaining. That 
> is no noticeable delay in terms of human time, but makes a difference in the 
> appearance.
> 
> So I figure: the system presumably knows if it is about to send more redraw 
> requests to that view. Is there any way I could know what it knows?
> 
> Jeff
> 
> 
> On Feb 4, 2016, at 3:31 PM, Clark S. Cox III wrote:
> 
> 
>> On Feb 4, 2016, at 15:07, Jeff Evans <jev...@ars-nova.com> wrote:
>> 
>> Suppose one wants to do a task in an NSView only once it has no drawRect 
>> calls pending. Is there any way to tell, for a particular NSView, if there 
>> are any drawing events coming up? Whether, that is, the view is up to date?
>> 
>> I've tried counting my explicit uses of setNeedsDisplay and decrementing 
>> that count at drawRect, but the trouble is that one can call setNeedsDisplay 
>> many times and that will not translate into the same number of drawRects.
>> 
>> One idea was to call getRectsBeingDrawn at drawRect and hope that the number 
>> of rects is equal to the number of update requests combined into that call. 
>> But the number of rects does not appear to equal the number of draw requests.
> 
> Multiple invalid regions can be merged.
> 
>> But there must be some place that contains a queue of upcoming draw 
>> requests. If so, is there access to it? 
> 
> There really isn't any such queue. There are only areas of the view that are 
> marked as invalid.
> 
>> I'm hoping this is a dumb question.
>> 
>> Thanks, Jeff
> 
> I hate to be "that guy", but what are you actually trying to do?
> 

___

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