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 <david.dun...@apple.com> wrote: > > > >> On Oct 21, 2019, at 3:26 AM, Arved von Brasch via Cocoa-dev >> <cocoa-dev@lists.apple.com> 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 <co...@atgo.org> 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