Re: Subclassing NSCollectionViewFlowLayout
Yeah, good points. I solved it better by overriding my NSCollectionViewItem
subclass’ preferredContentSize and setting it from my
itemForRepresentedObjectAt dataSource function when I get access to the item.
Cheers,
Arved
> On 2019-10-22, at 03:41, David Duncan wrote:
>
>
>
>> On Oct 21, 2019, at 3:26 AM, Arved von Brasch via Cocoa-dev
>> wrote:
>>
>> Hello list,
>>
>> Thanks to someone on the list who provided me with a clue, I found that if I
>> add this to my NSCollectionViewItem subclass:
>>
>> override func viewWillAppear() {
>> super.viewWillAppear()
>> view.removeConstraints(view.constraints)
>
> Don’t do this – you don’t know what constraints may be attached to the view
> that you don’t know about.
>
>> view.addConstraint(NSLayoutConstraint.init(item: view, attribute:
>> .width, relatedBy: .greaterThanOrEqual, toItem: nil, attribute:
>> .notAnAttribute, multiplier: 1, constant: view.frame.size.width))
>> view.addConstraint(NSLayoutConstraint.init(item: view, attribute:
>> .height, relatedBy: .greaterThanOrEqual, toItem: nil, attribute:
>> .notAnAttribute, multiplier: 1, constant: view.frame.size.height))
>
> This doesn’t really make a whole lot of sense – this is basically saying
> “whatever frame you have at this point, you will never be smaller than” which
> kinda defeats the whole purpose.
>
>> }
>>
>> the Collection View loads as expected and all the items appear at the proper
>> size regardless of window resizes. However, I do end up with a large number
>> of NSAutoresizingMaskLayoutConstraint clash errors. Not quite sure how I’m
>> going to resolve this yet, but I thought I’d post it in case anyone else
>> follows in my footsteps.
>
> Not too surprising, since the constraints you made are in direct conflict
> with these auto resizing mask constraints (since the auto resizing mask
> constraints basically tell the auto layout engine what the frame size will
> be).
>
>>
>> Cheers,
>> Arved
>>
>>
>>> On 2019-10-20, at 21:54, Arved von Brasch wrote:
>>>
>>> Hello Cocoa List,
>>>
>>> I’m in the process of porting a hobby project to up-to-date Swift so it can
>>> be used on Catalina (and I can upgrade my work machine - still looking for
>>> a QuickTime 7 Pro replacement, though). I’ve encountered a phenomenon
>>> subclassing NSCollectionViewFlowLayout that I haven’t been able to resolve.
>>>
>>> I have a Core Data backed NSArrayController feeding data to a
>>> NSCollectionView (still using XIBs, as that made the porting easier). That
>>> all works fine, although was surprisingly tricky to get going. I
>>> implemented a NSCollectionViewFlowLayout subclass to provide a left
>>> justified layout. I then implemented the NSCollectionViewDelegateFlowLayout
>>> function sizeForItemAt: to provide custom sizes for my items. This all
>>> works as intended during testing when the collection view is first loaded.
>>> However, if I resize the enclosing window, all the items reduce in size to
>>> what appears to be a single pixel and I can’t work out where the tiny size
>>> is coming from. My output of sizeForItemAt always seems to have sensible
>>> values, and I can’t see an obvious place for where else the collection view
>>> would be getting sizes from.
>>>
>>> I’m only implementing an init function, to set the estimatedItemSize,
>>> sectionInset and spacing values, and then overriding
>>> layoutAttributesForElements, as that seems to be all that’s required for my
>>> use case. I do not have any headers or footers or sections in my scenario,
>>> so the Array Controller is pretty simple too, although it acts as the Data
>>> Source and Delegate for the Collection View.
>>>
>>> Can anyone give me pointers for what I am screwing up? My web searches for
>>> this only return a meagre set of results which don’t help much.
>>>
>>> Kind regards,
>>> Arved
>>
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com
>>
>> This email sent to david.dun...@apple.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: Subclassing NSCollectionViewFlowLayout
> On Oct 21, 2019, at 3:26 AM, Arved von Brasch via Cocoa-dev
> wrote:
>
> Hello list,
>
> Thanks to someone on the list who provided me with a clue, I found that if I
> add this to my NSCollectionViewItem subclass:
>
> override func viewWillAppear() {
>super.viewWillAppear()
>view.removeConstraints(view.constraints)
Don’t do this – you don’t know what constraints may be attached to the view
that you don’t know about.
>view.addConstraint(NSLayoutConstraint.init(item: view, attribute:
> .width, relatedBy: .greaterThanOrEqual, toItem: nil, attribute:
> .notAnAttribute, multiplier: 1, constant: view.frame.size.width))
>view.addConstraint(NSLayoutConstraint.init(item: view, attribute:
> .height, relatedBy: .greaterThanOrEqual, toItem: nil, attribute:
> .notAnAttribute, multiplier: 1, constant: view.frame.size.height))
This doesn’t really make a whole lot of sense – this is basically saying
“whatever frame you have at this point, you will never be smaller than” which
kinda defeats the whole purpose.
>}
>
> the Collection View loads as expected and all the items appear at the proper
> size regardless of window resizes. However, I do end up with a large number
> of NSAutoresizingMaskLayoutConstraint clash errors. Not quite sure how I’m
> going to resolve this yet, but I thought I’d post it in case anyone else
> follows in my footsteps.
Not too surprising, since the constraints you made are in direct conflict with
these auto resizing mask constraints (since the auto resizing mask constraints
basically tell the auto layout engine what the frame size will be).
>
> Cheers,
> Arved
>
>
>> On 2019-10-20, at 21:54, Arved von Brasch wrote:
>>
>> Hello Cocoa List,
>>
>> I’m in the process of porting a hobby project to up-to-date Swift so it can
>> be used on Catalina (and I can upgrade my work machine - still looking for a
>> QuickTime 7 Pro replacement, though). I’ve encountered a phenomenon
>> subclassing NSCollectionViewFlowLayout that I haven’t been able to resolve.
>>
>> I have a Core Data backed NSArrayController feeding data to a
>> NSCollectionView (still using XIBs, as that made the porting easier). That
>> all works fine, although was surprisingly tricky to get going. I
>> implemented a NSCollectionViewFlowLayout subclass to provide a left
>> justified layout. I then implemented the NSCollectionViewDelegateFlowLayout
>> function sizeForItemAt: to provide custom sizes for my items. This all
>> works as intended during testing when the collection view is first loaded.
>> However, if I resize the enclosing window, all the items reduce in size to
>> what appears to be a single pixel and I can’t work out where the tiny size
>> is coming from. My output of sizeForItemAt always seems to have sensible
>> values, and I can’t see an obvious place for where else the collection view
>> would be getting sizes from.
>>
>> I’m only implementing an init function, to set the estimatedItemSize,
>> sectionInset and spacing values, and then overriding
>> layoutAttributesForElements, as that seems to be all that’s required for my
>> use case. I do not have any headers or footers or sections in my scenario,
>> so the Array Controller is pretty simple too, although it acts as the Data
>> Source and Delegate for the Collection View.
>>
>> Can anyone give me pointers for what I am screwing up? My web searches for
>> this only return a meagre set of results which don’t help much.
>>
>> Kind regards,
>> Arved
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com
>
> This email sent to david.dun...@apple.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: Subclassing NSCollectionViewFlowLayout
Hello list,
Thanks to someone on the list who provided me with a clue, I found that if I
add this to my NSCollectionViewItem subclass:
override func viewWillAppear() {
super.viewWillAppear()
view.removeConstraints(view.constraints)
view.addConstraint(NSLayoutConstraint.init(item: view, attribute:
.width, relatedBy: .greaterThanOrEqual, toItem: nil, attribute:
.notAnAttribute, multiplier: 1, constant: view.frame.size.width))
view.addConstraint(NSLayoutConstraint.init(item: view, attribute:
.height, relatedBy: .greaterThanOrEqual, toItem: nil, attribute:
.notAnAttribute, multiplier: 1, constant: view.frame.size.height))
}
the Collection View loads as expected and all the items appear at the proper
size regardless of window resizes. However, I do end up with a large number of
NSAutoresizingMaskLayoutConstraint clash errors. Not quite sure how I’m going
to resolve this yet, but I thought I’d post it in case anyone else follows in
my footsteps.
Cheers,
Arved
> On 2019-10-20, at 21:54, Arved von Brasch wrote:
>
> Hello Cocoa List,
>
> I’m in the process of porting a hobby project to up-to-date Swift so it can
> be used on Catalina (and I can upgrade my work machine - still looking for a
> QuickTime 7 Pro replacement, though). I’ve encountered a phenomenon
> subclassing NSCollectionViewFlowLayout that I haven’t been able to resolve.
>
> I have a Core Data backed NSArrayController feeding data to a
> NSCollectionView (still using XIBs, as that made the porting easier). That
> all works fine, although was surprisingly tricky to get going. I implemented
> a NSCollectionViewFlowLayout subclass to provide a left justified layout. I
> then implemented the NSCollectionViewDelegateFlowLayout function
> sizeForItemAt: to provide custom sizes for my items. This all works as
> intended during testing when the collection view is first loaded. However,
> if I resize the enclosing window, all the items reduce in size to what
> appears to be a single pixel and I can’t work out where the tiny size is
> coming from. My output of sizeForItemAt always seems to have sensible values,
> and I can’t see an obvious place for where else the collection view would be
> getting sizes from.
>
> I’m only implementing an init function, to set the estimatedItemSize,
> sectionInset and spacing values, and then overriding
> layoutAttributesForElements, as that seems to be all that’s required for my
> use case. I do not have any headers or footers or sections in my scenario, so
> the Array Controller is pretty simple too, although it acts as the Data
> Source and Delegate for the Collection View.
>
> Can anyone give me pointers for what I am screwing up? My web searches for
> this only return a meagre set of results which don’t help much.
>
> Kind regards,
> Arved
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Subclassing NSCollectionViewFlowLayout
Hello Cocoa List, I’m in the process of porting a hobby project to up-to-date Swift so it can be used on Catalina (and I can upgrade my work machine - still looking for a QuickTime 7 Pro replacement, though). I’ve encountered a phenomenon subclassing NSCollectionViewFlowLayout that I haven’t been able to resolve. I have a Core Data backed NSArrayController feeding data to a NSCollectionView (still using XIBs, as that made the porting easier). That all works fine, although was surprisingly tricky to get going. I implemented a NSCollectionViewFlowLayout subclass to provide a left justified layout. I then implemented the NSCollectionViewDelegateFlowLayout function sizeForItemAt: to provide custom sizes for my items. This all works as intended during testing when the collection view is first loaded. However, if I resize the enclosing window, all the items reduce in size to what appears to be a single pixel and I can’t work out where the tiny size is coming from. My output of sizeForItemAt always seems to have sensible values, and I can’t see an obvious place for where else the collection view would be getting sizes from. I’m only implementing an init function, to set the estimatedItemSize, sectionInset and spacing values, and then overriding layoutAttributesForElements, as that seems to be all that’s required for my use case. I do not have any headers or footers or sections in my scenario, so the Array Controller is pretty simple too, although it acts as the Data Source and Delegate for the Collection View. Can anyone give me pointers for what I am screwing up? My web searches for this only return a meagre set of results which don’t help much. Kind regards, Arved ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
