Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
The closest I got was creating a macro that uses np_thread_main() (or whatever it was called exactly, it’s part of the pthreads API, IIRC) and throws if it’s not the main thread. I call that e.g. in observeValueForKeyPath overrides whenever I make thread-unsafe calls, so I don’t accidentally make a threaded call. Ah, that's a good idea. I had wanted to do something like that but had been put off by the very large number of possible entry points. observeValueForKeyPath is a great idea that is sure to fire if any GUI-bound properties change. Of course, it’s only a runtime check, but it’s better than nothing. Sure would be fine if the Static Analyzer could be made to understand KVO and threading and complain about such uses. I have a suspicion that if you can get the static analyzer to understand that then you have probably solved a number of officially Hard problems along the way! ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 27 May 2015, at 11:00, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: Of course, it’s only a runtime check, but it’s better than nothing. Sure would be fine if the Static Analyzer could be made to understand KVO and threading and complain about such uses. I have a suspicion that if you can get the static analyzer to understand that then you have probably solved a number of officially Hard problems along the way! Was thinking more of making it mark certain calls it knows aren’t thread-safe as such, and marking every method that is passed to detachNewThreadSelector: or the likes as “threaded”, and then warning if the former is used inside or in a call hanging off the latter. That sounds like it would lie well within the abilities of the static analyzer. But I’m not saying I know that would work. I’m really just saying it “Sure would be fine” :-) Sounds like a heuristic that might work if it doesn’t give too many false positives and is kept conservative, though. Doesn’t have to catch all cases, as long as it catches a few and avoids false positives. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 23 May 2015, at 10:42, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: 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. The closest I got was creating a macro that uses np_thread_main() (or whatever it was called exactly, it’s part of the pthreads API, IIRC) and throws if it’s not the main thread. I call that e.g. in observeValueForKeyPath overrides whenever I make thread-unsafe calls, so I don’t accidentally make a threaded call. You could probably write a macro roughly equivalent to @synthesize that implements this additional behaviour. Of course, it’s only a runtime check, but it’s better than nothing. Sure would be fine if the Static Analyzer could be made to understand KVO and threading and complain about such uses. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 2015 May 23, at 07:10, Marek Hrušovský xhrus...@gmail.com wrote:
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.
Yes, but you don’t need an overridden setter. Amy Worral explains it here:
http://stackoverflow.com/questions/6354368/how-to-observe-change-in-nsobject-properties
My interpretation is to declare a phantom property such as
@property NSInteger lookMaStuffChanged ;
then,
+ (NSSet*)keyPathsForValuesAffectingValueForLookMaStuffChanged {
return [NSSet alloc] initWithObjects:
@“whatever1”,
@“whatever2”,
…
nil] ;
}
Finally, observe lookMaStuffChanged with KVO.
In fact, the phantom property lookMaStuffChanged is never affected by anything;
it’s never even set to anything.
Works for me.
___
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: Custom NSView subclass - expressing the fact that a property affects the displayed image
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
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
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 22 May 2015, at 6:03 am, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
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.
How about cooking up a macro for defining the accessors?
#define DECLARE_PROPERTY(PROPERTY,TYPE) \
@property (nonatomic, copy) TYPE PROPERTY;
#define DEFINE_PROPERTY(PROPERTY,TYPE) \
- (TYPE)PROPERTY \
{ \
return _##PROPERTY; \
} \
\
- (void)set##PROPERTY:(TYPE)x \
{ \
_##PROPERTY = x; \
[self setNeedsDisplay]; \
} \
...
@interface Foo
DECLARE_PROPERTY(widgetName, NSString *);
@end
...
@implmenetation Foo
DEFINE_PROPERTY(widgetName, NSString *);
@end
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...
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).
b
___
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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 22 May 2015, at 15:03, Jonathan Taylor jonathan.tay...@glasgow.ac.uk 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 (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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 22 May 2015, at 9:51 pm, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: I’m trying to think if there is an elegant way of handling the situation I find in some of my display code. I have a class which inherits from NSView and which overrides drawRect. The class has a number of properties, and if they change then the view needs redrawing. At present I have custom setters that call through to setNeedsDisplay:YES. This results in quite a lot of code bloat (since I would otherwise just @synthesize the properties and be done with it). 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. View properties can’t be usefully atomic either, so that isn’t going to matter. Really, you are trying to save yourself a tiny bit of extra work by making things far more complicated than necessary. Remember, it wasn’t very long ago that all properties had to be implemented by hand. How we used to spend many a happy hour writing endless getters and setters! 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. —Graham ___ 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
Custom NSView subclass - expressing the fact that a property affects the displayed image
I’m trying to think if there is an elegant way of handling the situation I find in some of my display code. I have a class which inherits from NSView and which overrides drawRect. The class has a number of properties, and if they change then the view needs redrawing. At present I have custom setters that call through to setNeedsDisplay:YES. This results in quite a lot of code bloat (since I would otherwise just @synthesize the properties and be done with it). I could set an observer on each property, but that would be a bit tedious (especially since, as I understand it, I have to remove EACH of the observers individually as well on dealloc). I am trying to think if there is a way I can leverage keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite a fan of using that where I can. It would be great if I could say that all my properties affect some particular property of NSView that would trigger a redraw. I can’t think of one that would do the trick, though. [If you think about it, the property needsDisplay is NOT the one I want to say is affected by my keys…] 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. Does anybody have any thoughts about what I might do? I feel this is probably a relatively common problem that people must have a way of dealing with… Cheers Jonny ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
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. 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... ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 22 May 2015, at 13:51, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: I’m trying to think if there is an elegant way of handling the situation I find in some of my display code. I have a class which inherits from NSView and which overrides drawRect. The class has a number of properties, and if they change then the view needs redrawing. At present I have custom setters that call through to setNeedsDisplay:YES. This results in quite a lot of code bloat (since I would otherwise just @synthesize the properties and be done with it). I could set an observer on each property, but that would be a bit tedious (especially since, as I understand it, I have to remove EACH of the observers individually as well on dealloc). I am trying to think if there is a way I can leverage keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite a fan of using that where I can. It would be great if I could say that all my properties affect some particular property of NSView that would trigger a redraw. I can’t think of one that would do the trick, though. [If you think about it, the property needsDisplay is NOT the one I want to say is affected by my keys…] 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. Does anybody have any thoughts about what I might do? I feel this is probably a relatively common problem that people must have a way of dealing with… 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. 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. ___ 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
