Haven't read all the thread but i would use a custom property with overridden setter to call setNeedsDisplay with combination of keyPathsForValuesAffectingValueForKey: I think you can get rid of the glue code.
On Sat, May 23, 2015 at 3:42 PM, Jonathan Taylor < jonathan.tay...@glasgow.ac.uk> wrote: > On 23 May 2015, at 00:21, Graham Cox <graham....@bigpond.com> 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 (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/xhruso00%40gmail.com > > This email sent to xhrus...@gmail.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
