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: Marek Hrušovský <email@hidden>
- Date: Sat, 23 May 2015 21:10:35 +0700
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 <
email@hidden> wrote:
> 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
>
_______________________________________________
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