On 27 May 2015, at 11:00, Jonathan Taylor 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 stat
> 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 accid
On 23 May 2015, at 10:42, Jonathan Taylor 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
> On 2015 May 23, at 07:10, Marek Hrušovský 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 ne
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 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
> On 22 May 2015, at 9:51 pm, Jonathan Taylor
> 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
> th
> On 22 May 2015, at 15:03, Jonathan Taylor
> 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
On 22 May 2015, at 6:03 am, Jonathan Taylor
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
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 fo
> On 22 May 2015, at 13:51, Jonathan Taylor
> 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
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 set
12 matches
Mail list logo
