Re: Thoughts on productivity
> On Oct 24, 2019, at 5:16 PM, James Walker via Cocoa-dev > wrote: > > On 10/24/19 3:57 PM, Rob Petrovec via Cocoa-dev wrote: >>> On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote: >>> >>> On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev >>> wrote: If its a ranty bug report, which apparently happens a lot, it goes into a black-hole never to see the light of day if it doesn’t just get closed right off the bat. So try to keep opinions & criticisms out of it. Just the facts and keep it professional. >>> >>> Not fixing an issue because the bug report is ranty is definitely not >>> professional. >> Apple Engineers aren’t in the service industry. So they don’t have to >> sit there and take it with a smile. > > When Apple engineers deal with bug reports, they're not just doing it as a > favor to the person who filed the report. Bugs may affect many developers > and end users, only a few of whom have the ability and the time to file a bug > report. So I agree that it would be unprofessional to ignore a report just > because it's not worded calmly. Most ranty bugs don’t have any actionable content in them though. They are just complaining and being insulting with no content of value, like most rants. They typically don’t have steps to reproduce or logs or video or anything like that. If there is anything actionable in it the engineers will typically copy/paste that actionable content into a new bug and send the original back to be closed. Put yourself in the Apple Engineers shoes. If someone sent you a long ranty, critical, & insulting email, or came up to you and started screaming at you about something, would you want to continue to interact with that person? I seriously doubt it. That person will probably continue to respond in the same way as their initial correspondence and provide nothing of value. —Rob ___ 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: Thoughts on productivity
>> One of the problems the Mac has is OLD crap software build on legacy APIs, seeing the black & white Watch Icon makes me want to vomit. >> I’m thankful Apple is prepared to force laggards, who want to keep Mac software back in the last century, quit the platform. Yep, they are very effective at that. An architect called us last week because they need a replacement for TimeSlips on Mac. It does architectural billing. Started out as Mac-only in the 80s, then went cross-platform, then went Windows-only in the early 00s rather than pivot to Carbon. The caller strung it along on a Mac as long as they could. Presumably they will switch to Windows, as many of our users have already done. Casey McDermott TurtleSoft.com On Thu, Oct 24, 2019 at 4:48 PM iLike computing ltd wrote: > I’m sorry you missed moving to Obj-C and Cocoa at the right time, most of > us here made this transition. > > It’s not easy, and to be honest jumping to Obj-C now is a mistake, you > have already missed the bus. Swift is Apples recommended language, I’ve > already made this move and it works fine with Cocoa. A good programmer > constantly renews and "skates to where the puck will be”. If you want to be > on the Apple platforms you need to listen to Apple. > > One of the problems the Mac has is OLD crap software build on legacy APIs, > seeing the black & white Watch Icon makes me want to vomit. I’m thankful > Apple is prepared to force laggards, who want to keep Mac software back in > the last century, quit the platform. > > You’ve made your point, now give us a rest, unless you want help with > Cocoa issues which is what this List is for... > > Cheers > Bill ___ 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: Fullscreen window problems
On 10/24/19 8:45 AM, Ray, Jeffrey R. {Jeff} (AFRC-630) via Cocoa-dev wrote:
I have a multi-platform OpenGL app (most code is c++, a tiny bit is Obj-C++).
It switches between windowed and full screen mode by having an allocated-once
window, and an allocated-and-destroyed full screen that comes and goes as
needed.
This worked correctly under Xcode 4. Due to local policy, I was prohibited
from upgrading until it suddenly became mandatory, and I jumped from Xcode 4 to
Xcode 10. Now my code no longer works correctly. Specifically, the window
works, and going to full screen works, but when I try to switch back to
windowed mode (by deallocating the full screen window and letting it go away on
its own), it no longer goes away.
I think I recall something on this list about changes to auto pools and ARC in
newer Xcode, but a search didn’t produce it. I’m no expert in Obj-C, so I’m
hoping someone can point me in the right direction. My attempts have only
resulted in memory faults.
Thanks in advance!
I think the trick is that you have to say [window orderOut: something]
rather than just releasing the window. Not sure when that changed.
___
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
Fullscreen window problems
I have a multi-platform OpenGL app (most code is c++, a tiny bit is Obj-C++). It switches between windowed and full screen mode by having an allocated-once window, and an allocated-and-destroyed full screen that comes and goes as needed. This worked correctly under Xcode 4. Due to local policy, I was prohibited from upgrading until it suddenly became mandatory, and I jumped from Xcode 4 to Xcode 10. Now my code no longer works correctly. Specifically, the window works, and going to full screen works, but when I try to switch back to windowed mode (by deallocating the full screen window and letting it go away on its own), it no longer goes away. I think I recall something on this list about changes to auto pools and ARC in newer Xcode, but a search didn’t produce it. I’m no expert in Obj-C, so I’m hoping someone can point me in the right direction. My attempts have only resulted in memory faults. Thanks in advance! -j -- Jeff Ray M/S 4840A Official Correspondence Only: NASA jeff@nasa.gov Armstrong Flight Research Centerjeffrey.r@nasa.gov P. O. Box 273 Edwards, CA 93523-0273 All Others:jeff...@mac.com (661) 276-3754 ___ 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: Thoughts on productivity
On 10/24/19 3:57 PM, Rob Petrovec via Cocoa-dev wrote: On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote: On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev wrote: If its a ranty bug report, which apparently happens a lot, it goes into a black-hole never to see the light of day if it doesn’t just get closed right off the bat. So try to keep opinions & criticisms out of it. Just the facts and keep it professional. Not fixing an issue because the bug report is ranty is definitely not professional. Apple Engineers aren’t in the service industry. So they don’t have to sit there and take it with a smile. When Apple engineers deal with bug reports, they're not just doing it as a favor to the person who filed the report. Bugs may affect many developers and end users, only a few of whom have the ability and the time to file a bug report. So I agree that it would be unprofessional to ignore a report just because it's not worded calmly. ___ 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: Thoughts on productivity
> On Oct 24, 2019, at 4:50 PM, Stephane Sudre wrote: > > On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev > wrote: >> If its a ranty bug report, which apparently happens a lot, it goes into a >> black-hole never to see the light of day if it doesn’t just get closed right >> off the bat. So try to keep opinions & criticisms out of it. Just the >> facts and keep it professional. > > Not fixing an issue because the bug report is ranty is definitely not > professional. Apple Engineers aren’t in the service industry. So they don’t have to sit there and take it with a smile. —Rob ___ 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: Thoughts on productivity
On Fri, Oct 25, 2019 at 12:38 AM Rob Petrovec via Cocoa-dev wrote: > If its a ranty bug report, which apparently happens a lot, it goes into a > black-hole never to see the light of day if it doesn’t just get closed right > off the bat. So try to keep opinions & criticisms out of it. Just the facts > and keep it professional. Not fixing an issue because the bug report is ranty is definitely not professional. ___ 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: Thoughts on productivity
> On Oct 24, 2019, at 4:01 PM, Gabriel Zachmann via Cocoa-dev > wrote: > >>> >>> >>> >>> https://developer.apple.com/account/#/feedback-assistant >>> >>> https://developer.apple.com/account/#/forums >> >> >> Good luck with that. I've been using OSX/macOS since the Panther days and >> quite frankly I don't think Apple cares. > > Occasionally, I send a bugreport via https://feedbackassistant.apple.com/ > And occasionally, I do get a response, usually they ask for additional > information. > > So, i think, they do listen to the feedback on that channel, at least. > > Best regards, Gabriel My experience is similar. I’ve had numerous bug reports I’ve written fixed over the years. Some took longer than others, but they do get fixed. From talking to some Apple engineers I’m friends with, the key is to write an actionable bug (e.g. provide screen shots, screen recordings, logs and most importantly reproducible steps). If you write a bug that isn’t actionable then there isn’t much they can do with it. If its a ranty bug report, which apparently happens a lot, it goes into a black-hole never to see the light of day if it doesn’t just get closed right off the bat. So try to keep opinions & criticisms out of it. Just the facts and keep it professional. If you run with any haxies and system mods then that makes it even harder for them to diagnose & fix issues. Especially if it uses code injection to do it’s thing. Chances are high the bug is in the haxie/system mod not the OS. Otherwise they would likely have gotten more reports about it and have fixed it. As for forums & mailing lists, some Apple engineers do lurk on them and do reply from time to time. But it isn’t part of their job. They do it on their own. So I agree that if you want to provide feedback, do it via a bug report not via the forums & mailing lists. —Rob ___ 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: Thoughts on productivity
>> >> >> >> https://developer.apple.com/account/#/feedback-assistant >> >> https://developer.apple.com/account/#/forums > > > Good luck with that. I've been using OSX/macOS since the Panther days and > quite frankly I don't think Apple cares. Occasionally, I send a bugreport via https://feedbackassistant.apple.com/ And occasionally, I do get a response, usually they ask for additional information. So, i think, they do listen to the feedback on that channel, at least. Best regards, Gabriel ___ 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: i386 Deprecated Warning in Xcode 9.4.1
> On Oct 24, 2019, at 11:46 AM, Sandor Szatmari via Cocoa-dev > wrote: > > Is there a flag I can set in Xcode to squash these? If these are compiler (Clang) warnings, then: 1. Right-click on a warning in the Xcode issues browser 2. Select "Show In Log" — this should take you to the build log with that warning message visible 3. At the end of the warning message should be something like "(-Wsomething)", which is the name of the Clang compiler flag that enables that warning. 4. Go to your target build settings, and in the custom warning flags add "-Wno-something", which will suppress that warning. —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: Thoughts on productivity
> On Oct 24, 2019, at 7:47 AM, Richard Charles via Cocoa-dev > wrote: > > Before September 2014 the developer documentation was excellent. Excellent > online documentation with downloadable and searchable pdfs. Now all pdfs are > gone and online documentation is like art on display in a museum. Great to > look at but not very usable. Have you tried the app Dash*? It's a general-purpose documentation browser, and it will automatically index and search installed Apple docsets, much better than Xcode does. I can't live without it. (I'm not doing so much Apple-specific coding these days, but I'm still constantly using Dash to look up C++ library classes, Mac man pages, SQLite syntax, Python syntax, etc. It's one of eight apps I've got hot-keys for.) —Jens * https://kapeli.com/dash ___ 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
i386 Deprecated Warning in Xcode 9.4.1
Migrating some code to 64 bit… Making a pit stop at Xcode 9.4.1/32 bit as the last stable 32 bit build. 40+ projects with multiple targets make for a lot of i386 is deprecated noise. I’d like to silence these warnings while I straighten out actual issues. Is there a flag I can set in Xcode to squash these? Much thanks in advance, Sandor ___ 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: Thoughts on productivity
>>I think you missed a step when learning Cocoa. A great way to start is with something like Cocoa Programming for Mac OS X by Aaron Hillegass No, working through the Hillegass books was the first thing we did- first the current edition for Swift, then the previous one for Objective-C. We also read through every other book in existence about Cocoa, before even starting to code. That may have flattened the learning curve. We started by programming with nibs and bindings, as the books teach. Then we gradually discovered that it was very hard to scale it up to a large working app. Moving as much as possible from nibs to code solved a lot of problems. Casey McDermott TurtleSoft.com On Thu, Oct 24, 2019 at 10:47 AM Richard Charles wrote: > > > On Oct 24, 2019, at 7:04 AM, Turtle Creek Software via Cocoa-dev < > cocoa-dev@lists.apple.com> wrote: > > > Is there a way to fix this stuff? > > > For the rest, Apple really needs to listen to developers more. > > Some random thoughts. > > Before September 2014 the developer documentation was excellent. Excellent > online documentation with downloadable and searchable pdfs. Now all pdfs > are gone and online documentation is like art on display in a museum. Great > to look at but not very usable. > > I think you missed a step when learning Cocoa. A great way to start is > with something like Cocoa Programming for Mac OS X by Aaron Hillegass. It > has lots of examples to reinforce what you are learning. > > Hopefully the Feedback Assistant will bring better results than the Bug > Reporter. > > Apple Developer Forums are perhaps like the current documentation. Nice to > look at but not very useful. Interesting that this list has had somewhat of > a resurgence in recent months. > > Apple sample code should compile and run on the current version of Xcode. > Period. What good is sample code if it takes a day to get it up and running. > > --Richard Charles > > ___ 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: Thoughts on productivity
> > This is how you move towards a solution. > > https://developer.apple.com/account/#/feedback-assistant > > https://developer.apple.com/account/#/forums Good luck with that. I've been using OSX/macOS since the Panther days and quite frankly I don't think Apple cares. I've submitted dozens of feature requests in the feedback form over the past decade, never received an answer or saw one realized. Same thing with the Webkit bugs that I have reported over the years. All are still open and received very little attention from the devs. AFAIK Apple's forums are for the community only. ___ 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: Thoughts on productivity
> On Oct 24, 2019, at 7:04 AM, Turtle Creek Software via Cocoa-dev > wrote: > Is there a way to fix this stuff? > For the rest, Apple really needs to listen to developers more. Some random thoughts. Before September 2014 the developer documentation was excellent. Excellent online documentation with downloadable and searchable pdfs. Now all pdfs are gone and online documentation is like art on display in a museum. Great to look at but not very usable. I think you missed a step when learning Cocoa. A great way to start is with something like Cocoa Programming for Mac OS X by Aaron Hillegass. It has lots of examples to reinforce what you are learning. Hopefully the Feedback Assistant will bring better results than the Bug Reporter. Apple Developer Forums are perhaps like the current documentation. Nice to look at but not very useful. Interesting that this list has had somewhat of a resurgence in recent months. Apple sample code should compile and run on the current version of Xcode. Period. What good is sample code if it takes a day to get it up and running. --Richard Charles ___ 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: Thoughts on productivity
> > These days, Cocoa is pretty much the only tool that creates native > software for Apple hardware. There's iOS too which has a lot more devs (outside from Apple) than macOS. No wonder Apple is "merging" the two SDKs (SwiftUI, Catalyst, etc). ___ 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: Thoughts on productivity
On Oct 24, 2019, at 6:08 AM, Turtle Creek Software via Cocoa-dev wrote: > Is there a way to fix this stuff? … > For the rest, Apple really needs to listen to developers more. This is how you move towards a solution. https://developer.apple.com/account/#/feedback-assistant https://developer.apple.com/account/#/forums -- Gary L. Wade http://www.garywade.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
Thoughts on productivity
TurtleSoft has shipped software built with 3 different programming tools: Excel, HyperCard and CodeWarrior C++/PowerPlant. We started but abandoned projects using 4 others: FileMaker, Omnis, Serius Developer and Think Pascal/C++/TCL. There were another 6 app-development tools that we bought and poked at for a while, but decided not to use. Cocoa's status is still pending. I've been thinking about what it was that made some platforms work well, and some not. Rather than anything specific, it pretty much came down to productivity. With some tools, we chugged along steadily and eventually shipped software. The rest bogged down for one reason or another. When a product release started looking too far off, it was time to bail. Programming seems like one of those things that works best in a state of "flow". Get totally focused and immersed. In the groove. It's possible to get a lot done in that state. One phone call can kill it. So can getting stuck on a problem. If you have to wander too far looking for a solution, your concentration shifts elsewhere and it can be hard to go back. In the 3 years moving from Carbon to Cocoa, we got stuck many, many times. Surprisingly, it wasn't just a learning curve. The frustrations were remarkably constant. It may even have grown harder with time, rather than easier. I'd estimate that our time with Cocoa was about 25% highly-productive flow state. Looking back, Excel macro programming was about the same, but spreadsheet setup was much faster. HyperTalk and C++ ran about 90% high-productivity. Here's where we stumbled the most with Cocoa: 1. Documentation. Class and method naming is usually quite reasonable in Cocoa. But when something was confusing, online docs rarely helped. Too often, they either stated the obvious, or linked to lengthy theoretical background. To stay productive, what we really needed was usage examples, code snippets, warnings about pitfalls. Sometimes deep knowledge is worthwhile, but sometimes you just need a bit of code to copy/paste. 2. Example projects. Apple has a good selection, but most for Mac are outdated and useless. Many don't even run. Some show features that are nifty, but deprecated. Anything recent is Swift-only, and usually iOS rather than Mac. Sample code from blogs has the same problems. Cocoa is complex enough that it really helps to run working examples. Jump-starting with existing code saves days or weeks, and keeps the workflow going. 3. Nibs. The graphic "GUI builder" environment is a great idea in theory, but overly complex in practice. Too many minor settings with unexpected consequences. Too hard to debug problems caused by small errors. Constraints were a constant hassle. Woe to anyone needing to add a new item in the middle. I suspect that nibs and storyboards are supposed to let non-programmers create an entire app without writing code. Two of the tools we abandoned (Serius and Prograph) had a similar goal, and both were disasters. Text is easier to read. Easier to comment and debug. 4. Memory management. I complained about this previously. ARC sounds great in theory, but it's too complicated in practice. Our C++ code rarely crashes. It had just one small memory leak, hidden somewhere in PowerPlant's LWindow (now removed). In contrast, we wasted too much time on mystery deallocs in Cocoa classes. There are too many subtle ways to create leaks. 5. Missing features. Cocoa includes all the basics and more, but there were small deficiencies which made it more difficult. The first one that bit us was NSComboBox not having a way to restrict choices to existing items only. Apple's docs mentioned that it was possible, but we never found a way to make it work, despite help from this list. Multiply that by 100. I get the sense that most Cocoa features were created to run Safari, Finder, Preview or some other Apple product. Not enough focus on the needs of folks who develop other types of apps. 6. Changes too rapid. The assumption seems to be that Mac and iOS developers should rewrite code frequently. That alone is more than some of us can afford, but the pace of change also made problem-solving more difficult. It was the root cause of problems #1 and #2. There is a whole ecosystem of bloggers and Stack Overflow contributors who provide free support for iOS and macOS, but they can't keep up. As a result, most online help is outdated and unreliable. BTW Microsoft seems to err in the opposite direction. They rarely toss anything, so their dev tools are a confusing mess of options and duplications. Surely there is a sweet spot somewhere in the middle? 7. MVC needs a more cooperative C layer. Right now the Cocoa controller classes work fine with outside model code, but they don't coordinate well with an outside controller. I think the key might be to have deeper access to event handling within NSWindowController and NSViewController, but that's just a guess. It would take some experimenting to figure how best to connect
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
