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

[Graham Cox]

> 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



___

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

Please do not post admin requests or moderator comments to the list.
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

[Peter Tomaselli]

I definitely remember feeling like there was a bit of a mismatch between the 
“declarative” feel of auto layout and the more procedural feel of all the 
necessary collection view layout overrides and whatnot. Bridging that gap was 
the main reason for all the shenanigans in that code (well, that and me only 
being a Cocoa hobbyist).

And you're quite right to perhaps not want to clutter up all your classes with 
that gunk if it can be avoided! Count me as one very interested to hear DTS’s 
suggestions if it's possible for you to share them. 

Cheers,

Peter

> On Aug 10, 2016, at 6:49 PM, Doug Hill  wrote:
> 
> Peter,
> 
> […] 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

___

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

Please do not post admin requests or moderator comments to the list.
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  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 
> 
> 
> 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  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 
> 
>   
> 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 > > 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 >> > 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 > wrote:
 
> 
> On Aug 10, 2016, at 11:10 AM, Doug Hill  > 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

[Peter Tomaselli]

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

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

[Jonathan Hull]

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.

That said, I did additional research and found other people with your issue.  
Relevant posts:
https://github.com/imyoungyang/DynamicHeight

http://stackoverflow.com/questions/25895311/uicollectionview-self-sizing-cells-with-auto-layout

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.

Thanks,
Jon

> On Aug 10, 2016, at 2:27 PM, Doug Hill  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 > > 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 >> > wrote:
>>> 
 
 On Aug 10, 2016, at 11:10 AM, Doug Hill > 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  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 > > wrote:
>> 
>>> 
>>> On Aug 10, 2016, at 11:10 AM, Doug Hill >> > 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 
>  wrote:
> 
> On Aug 10, 2016, at 13:42 , Doug Hill  > 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

[Quincey Morris]

On Aug 10, 2016, at 13:42 , Doug Hill  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.
___

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

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

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

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

Re: Cocoa File Close Notification

[Sandor Szatmari]

Have you considered using a dispatch source?

You might have to do some manual checking when you get a notification about 
activity with your file, but it might be suitable to your needs.

Here's a link I was reading:

http://stackoverflow.com/questions/11355144/file-monitoring-using-grand-central-dispatch

Sandor Szatmari

> On Aug 10, 2016, at 15:30, Jens Alfke  wrote:
> 
> 
>> On Aug 10, 2016, at 12:10 PM, Gurkan Erdogdu  wrote:
>> 
>> I try to get file close notification in Cocoa/Swift. Is there any way to do 
>> this? I tried to use FSEvent API but this does not provide any notification 
>> for file close events.
> 
> I don’t think there’s any such notification. File handles are private to a 
> process.
> 
>> Any help is appreciated. What I want to do is when word or PDF file is 
>> closed, I want my Cocoa application do sometnig?
> 
> If you want to do something when the file is changed, then watch for 
> file-changed events. You’ll probably want to wait a few seconds after the 
> last such event, because you may get several in a row if the changes take a 
> while (for example if a file is being downloaded.)
> 
> If you want to do something when a _document_ is closed in an app like 
> Preview or Word, that’s entirely different. Closing a document has nothing to 
> do with closing a file. When most apps open a document they open the file, 
> read its contents, and then close the file. They don’t leave it open while 
> the document is open. As far as I know there is no reliable way to detect 
> when some other app closes a document.
> 
> —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/admin.szatmari.net%40gmail.com
> 
> This email sent to admin.szatmari@gmail.com

___

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

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

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/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 
>  wrote:
> 
> On Aug 10, 2016, at 13:29 , Doug Hill  > 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

[Nicolas Kozic]

performa 640 pizza live
> On Aug 10, 2016, at 10:29 PM, Doug Hill  wrote:
> 
> 
>> On Aug 10, 2016, at 11:10 AM, Doug Hill  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 

Re: Dynamic-width Collection View

[Quincey Morris]

On Aug 10, 2016, at 13:29 , Doug Hill  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.

___

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

Please do not post admin requests or moderator comments to the list.
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  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, and change the layout attributes' frame 
property to use this.

2) The app still crashes
When scrolling, it will show some number of cells correctly, then I'll see one 
that has an incorrect width and 

Re: Cocoa File Close Notification

[Jens Alfke]

> On Aug 10, 2016, at 12:10 PM, Gurkan Erdogdu  wrote:
> 
> I try to get file close notification in Cocoa/Swift. Is there any way to do 
> this? I tried to use FSEvent API but this does not provide any notification 
> for file close events.

I don’t think there’s any such notification. File handles are private to a 
process.

> Any help is appreciated. What I want to do is when word or PDF file is 
> closed, I want my Cocoa application do sometnig?

If you want to do something when the file is changed, then watch for 
file-changed events. You’ll probably want to wait a few seconds after the last 
such event, because you may get several in a row if the changes take a while 
(for example if a file is being downloaded.)

If you want to do something when a _document_ is closed in an app like Preview 
or Word, that’s entirely different. Closing a document has nothing to do with 
closing a file. When most apps open a document they open the file, read its 
contents, and then close the file. They don’t leave it open while the document 
is open. As far as I know there is no reliable way to detect when some other 
app closes a document.

—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

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

[Andrew Keller]

Am 10.08.2016 um 2:48 vorm. schrieb Quincey Morris 
:
> On Aug 9, 2016, at 20:47 , Andrew Keller  > wrote:
>> 
>> 2. When utilizing Mike’s approach to limiting the number of parallel tasks 
>> down to, say, 1-8, I have been completely unable to reproduce the deadlock.
>> 3. When utilizing Mike’s approach to limiting the number of parallel tasks, 
>> Xcode is still saying that threads a being created like crazy — almost one 
>> thread per block submitted to the queue.
> 
> I’m not a big fan of Mike’s proposed solution. If you want to use N-wide 
> parallelism, then use NSOperationQueue, not GCD.
> 
> Blocks dispatched to GCD queues should not contain any internal waits, such 
> as for I/O. Instead, a dispatched block should occupy the CPU continuously, 
> and at the end do one of 3 things:
> 
> 1. Just exit.
> 
> 2. Start an asynchronous action, such as GCD I/O, with a completion handler 
> that’s not scheduled until the action is done.
> 
> 3. Queue another block that represents another processing step in the overall 
> task being performed.
> 
> The point of #3 is that I think it’s also a mistake to queue large numbers of 
> blocks to GCD all at once, for the pragmatic reason that if you accidentally 
> violate the non-internal-waits rule, the size of the thread explosion depends 
> on the amount of combustible material that’s queued. It’s better for *each 
> operation* to queue its successor, and to start the whole thing off by 
> priming the pump with a modest number of blocks.
> 
> The other thing to be very careful of is global locks. If your code (perhaps 
> outside your direct control) hits any global locks that affect multiple 
> threads, *and* if the kind of lock being used is slower to test when locked 
> than when unlocked, then more parallelism can be counterproductive.
> 
> I’ve run into this in cases where adding more operations on more CPUs just 
> adds a disproportionate amount of system overhead, decreasing the throughput 
> of the actual calculation.
> 
> The point of all this is that you may not have enough control of the internal 
> behavior of those NSImage methods to safely use GCD parallelism for a job 
> like this. NSOperationQueue might be a better solution.

Interesting idea.  I’ve modified my scheduler to use existing work to post the 
next work to GCD.  This implementation has no semaphores and no custom dispatch 
queues at all.  Interestingly, I get roughly the same results: no crazy 
swapping to disk, no deadlock, and Xcode is still saying that threads are 
piling up like crazy.  (Note that I’m not letting the concurrent procedure 
count past 8)

That said, this implementation does “feel” better than before from an 
architectural point of view.  I believe I have more along the lines of 
“computationally intensive things I can do to iteratively improve the UI” 
rather than “a long list of work to do”.  Based on what the user is doing, I 
can prioritize certain parts of the UI being rendered before others, and using 
existing work to post the next work in GCD makes a lot of sense because the 
concept of “future work” can change so easily.  I know NSOperationQueue 
supports giving certain tasks priority, but I’d have to actually set all of 
those values — whereas with blocks posting other blocks, I get this behavior 
almost for free because there is always “the next most useful thing to render 
in the UI”.  If some distant future work happens to become irreverent because 
the user moved to another screen, then this approach simply never gets around 
to queueing that work, which is usually good.

Thanks,
 - Andrew

___

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

Please do not post admin requests or moderator comments to the list.
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

[Quincey Morris]

On Aug 9, 2016, at 20:47 , Andrew Keller  wrote:
> 
> 2. When utilizing Mike’s approach to limiting the number of parallel tasks 
> down to, say, 1-8, I have been completely unable to reproduce the deadlock.
> 3. When utilizing Mike’s approach to limiting the number of parallel tasks, 
> Xcode is still saying that threads a being created like crazy — almost one 
> thread per block submitted to the queue.

I’m not a big fan of Mike’s proposed solution. If you want to use N-wide 
parallelism, then use NSOperationQueue, not GCD.

Blocks dispatched to GCD queues should not contain any internal waits, such as 
for I/O. Instead, a dispatched block should occupy the CPU continuously, and at 
the end do one of 3 things:

1. Just exit.

2. Start an asynchronous action, such as GCD I/O, with a completion handler 
that’s not scheduled until the action is done.

3. Queue another block that represents another processing step in the overall 
task being performed.

The point of #3 is that I think it’s also a mistake to queue large numbers of 
blocks to GCD all at once, for the pragmatic reason that if you accidentally 
violate the non-internal-waits rule, the size of the thread explosion depends 
on the amount of combustible material that’s queued. It’s better for *each 
operation* to queue its successor, and to start the whole thing off by priming 
the pump with a modest number of blocks.

The other thing to be very careful of is global locks. If your code (perhaps 
outside your direct control) hits any global locks that affect multiple 
threads, *and* if the kind of lock being used is slower to test when locked 
than when unlocked, then more parallelism can be counterproductive.

I’ve run into this in cases where adding more operations on more CPUs just adds 
a disproportionate amount of system overhead, decreasing the throughput of the 
actual calculation.

The point of all this is that you may not have enough control of the internal 
behavior of those NSImage methods to safely use GCD parallelism for a job like 
this. NSOperationQueue might be a better solution.

___

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

Please do not post admin requests or moderator comments to the list.
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