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: Mike Abdullah <email@hidden>
- Date: Fri, 22 May 2015 23:35:06 +0200
> On 22 May 2015, at 15:03, Jonathan Taylor <email@hidden> wrote:
>
> Thanks for your reply Mike:
>
>> Well you could have a single key which you observe internally, and which all the other keys feed into. Whenever it “changes”, treat that as time to mark as needing display. That way you’re asking AppKit to do the work of creating all the other observations for you.
>
> I think this is what I was describing here, isn’t it (or am I misunderstanding you?):
>>> I could create a single “dummy” property of my own, say that changes to all these other properties affect that key, and then monitor that single key using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other property change). That would do what I want, but feels a little bit hacky.
Yeah, same thing I think. Was just talking it through more for my own benefit really :-)
>
>
>> It all seems rather wasteful though. You’ve added a couple of layers of indirection into the system to save a handful of lines of code. Is it really that big a deal to write some custom setters? They’re only four lines long each.
>
> I agree that it’s extra indirection, but since performance is never going to be an issue, I feel it’s a slight gain on tidiness and maintainability. I agree that it’s not a big deal for one property, but when there are lots it starts to add up. And it’s not just the setters - what finally spurred me into action was the decision that I wanted all my properties to be atomic (which may or may not be related to an occasional crash I have been seeing). That means writing a correct threadsafe getter for each one as well…
That’s a good point about how atomic accessors make the story a lot more complicated. BUT, why would atomic accessors help your crash? Views are pretty fundamentally tied to the main thread for the most part. Atomic accessors won’t help there.
_______________________________________________
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