Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
- Subject: Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
- From: Jonathan Taylor <email@hidden>
- Date: Sat, 23 May 2015 09:42:49 +0100
On 23 May 2015, at 00:21, Graham Cox <email@hidden> wrote:
> My advice is: forget it. What you’re doing is fine, and it’s the normal way to make views repaint when a property changes. It’s not code ‘bloat’ either - @synthesize produces code just as if you’d written it yourself. Any other way than simply adding a call to -setNeedsDisplay: is MORE code than that.
Just to be clear, I meant source code bloat - in the process of refactoring the code I have been rather horrified at how much of my codebase is really just "glue" code for user interface stuff, in what should be just a GUI wrapper on some scientific code.
> What would be quite nice (though maybe too much of a special case and very unlikely to happen) is a qualifier for properties that would add the -setNeedsDisplay: automatically as part of the @synthesize, but I doubt that will ever happen because it a) only pertains to views b) might not be optimal for some situations, where only part of the view needs updating, and c) made somewhat redundant by layers, which have a flag that causes a redisplay on a property change.
Ah, now it sounds like layers could be something I should be reading up on then! Maybe another one of those cases of me asking the wrong question because I don't know what the right one is...
All of you wrote:
> Since you're talking about properties on an NSView subclass, and NSView is documented as being not thread-safe, the atomicity thing sounds like a big red herring (or red flag, depending on your preference for fish or cloth).
[rambling off the original topic...]
You are quite right of course. If I am concerned about atomicity on this particular object then I am definitely doing something wrong. There was probably some end-of-week thinking behind what I did, but the rough train of thought went:
- There is necessarily a fair bit of multithreading in my codebase, and I have not found a completely foolproof way of guaranteeing it remains isolated from GUI code (though I know I must do that). I want to use [non-gui-related] properties on other threads, but then sooner or later I end up accidentally causing an interaction with GUI-bound properties and causing an obscure and hard-to-debug crash
- A recent such crash involved a double-free of an NSNumber (where to begin looking...!?), and brainstorming this lead me to imagine that accessing a nonatomic property returning an objc object could lead to that happening.
- As a result I decided I had no good reason to have any nonatomic properties, and that I would try and remove any use of nonatomic rather than try and decide on a case-by-case basis
- This led to warnings about custom setters paired with auto-synthesized getters, which got me looking at this setNeedsDisplay code and wondering if there was a better way of doing that anyway.
Probably an overreaction (and very probably not the actual cause of the crash), but I was pretty sure that technically speaking my universal use of nonatomic [for reasons lost in the mists of time] was not correct.
If only there was a way of annotating properties as only-to-be-used-from-the-main-thread. I've asked something to that effect previously, though, and nobody had any suggestions. I feel there must be a way of designing-in the safety that I need, but I haven't worked out what it might be.
_______________________________________________
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