Re: Subclassing NSCollectionViewFlowLayout
Re: Subclassing NSCollectionViewFlowLayout
- Subject: Re: Subclassing NSCollectionViewFlowLayout
- From: Arved von Brasch via Cocoa-dev <email@hidden>
- Date: Thu, 24 Oct 2019 20:01:41 +1100
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 <email@hidden> wrote:
>
>
>
>> On Oct 21, 2019, at 3:26 AM, Arved von Brasch via Cocoa-dev
>> <email@hidden> 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 <email@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden