Re: KVO question

Hi guys, thanks for your replies - sorry took a while to get back to this, was in a long meeting. Anyway, Quincey, I’m not trying to get notified for mutations to the dictionary. The dictionary is being replaced as a single entity wholesale. The way the font manager works is that for a given

Re: KVO question

> On 19 Nov 2015, at 08:38, Quincey Morris > wrote: > > (sorry, posted the incomplete message by accident) > > On Nov 18, 2015, at 16:29 , Roland King > wrote: >> >> I didn’t read his original question as saying that > > I could easily have got it wrong, but I believe

Re: KVO question

(sorry, posted the incomplete message by accident) On Nov 18, 2015, at 16:29 , Roland King mailto:r...@rols.org>> wrote: > > I didn’t read his original question as saying that I could easily have got it wrong, but I believe what he was saying was that much of his system was working. The part t

Re: KVO question

On Nov 18, 2015, at 16:29 , Roland King wrote: > > I didn’t read his original question as saying that I could easily have got it wrong, but I believe what he was saying was that much of his system was working. The part that doesn’t work is when (e.g.) the Font Manager updates the dictionary di

Re: KVO question

> On 19 Nov 2015, at 08:15, Quincey Morris > wrote: > > On Nov 18, 2015, at 14:35 , Graham Cox wrote: >> >> it’s just that if other code changes the attributes dictionary (such as the >> Font Manager) then I need these split out properties to trigger their >> notifications so that the UI sh

Re: KVO question

On Nov 18, 2015, at 14:35 , Graham Cox wrote: > > it’s just that if other code changes the attributes dictionary (such as the > Font Manager) then I need these split out properties to trigger their > notifications so that the UI shows the change I think I understand, finally. No, what you’re d

Re: KVO question

> On 18 Nov 2015, at 6:43 PM, Quincey Morris > wrote: > > As a matter of principle, I always think using a dictionary as an API to > properties is a terrible idea. You’re much better off defining an object that > actually has the properties, even if there are a lot of them. That would > solv

Re: Installing older OS X

On Nov 18, 2015, at 12:16 , Lee Ann Rucker wrote: > > Hmm... it's the same path as the big button Ah, I see what happened. I didn’t realize that the Big Button was a separate choice, I thought it was a picture that illustrated what the list entries meant. Why? Because my selection color is set

Re: Installing older OS X

> On Nov 17, 2015, at 9:21 PM, Quincey Morris > wrote: > > On Nov 17, 2015, at 21:03 , Charles Srstka wrote: >> >> I can personally vouch for Mountain Lion running well in VMWare. Where it >> gets hard is when you are running Snow Leopard or earlier, and not for any >> technological reason—

Re: Assigning an element of a swift array to a userdata parameter triggers didSet

> On Nov 18, 2015, at 11:12 AM, Quincey Morris > wrote: > On Nov 18, 2015, at 10:57 , Jens Alfke wrote: >> >> Doesn’t the pointer become invalid as soon as myElement goes out of scope? >> (There’s a reason that type is called *Unsafe*Pointer…) > > Yes, but so does &myArray[0] in the original

Re: Assigning an element of a swift array to a userdata parameter triggers didSet

> On Nov 18, 2015, at 7:24 AM, Eric Gorr > wrote: > > Yes, that all makes sense. So, the question is what can I do about it? The > number of tooltips I need is the same number of elements in the array and the > number of elements in the array can change over the lif

Re: Assigning an element of a swift array to a userdata parameter triggers didSet

On Nov 18, 2015, at 10:57 , Jens Alfke wrote: > > Doesn’t the pointer become invalid as soon as myElement goes out of scope? > (There’s a reason that type is called *Unsafe*Pointer…) Yes, but so does &myArray[0] in the original code. According to your hypothesis, it’s copied into a temporary,

Re: Assigning an element of a swift array to a userdata parameter triggers didSet

> On Nov 18, 2015, at 10:17 AM, Quincey Morris > wrote: > > If the array element (a dictionary, in your original post) is small enough, > you can pass a pointer to a copy of the element instead of a pointer to the > element. That is: > > var myElement = myArray[0] > view.addToolT

Re: Assigning an element of a swift array to a userdata parameter triggers didSet

On Nov 18, 2015, at 05:24 , Eric Gorr wrote: > > Yes, that all makes sense. So, the question is what can I do about it? The > number of tooltips I need is the same number of elements in the array and the > number of elements in the array can change over the lifetime of the > application. So, i

Re: KVO question

One possible issues is that `self.thingy=x;` will trigger two change notifications for `thingy`: one for `self.dictionaryOfThings = temp;` (due to keyPathsForValuesAffectingThingy), and one when the setter exits. Depending one what your observer does this may have unforeseen side effects. A po

Re: KVO question

Are you implying that one KVO is blocking the others? Sent from my iPhone > On Nov 17, 2015, at 8:18 PM, Graham Cox wrote: > > I’m using KVO to observe a bunch of properties. > > Most of these properties are split out into simple things that set a single > value, but internal to my object, so

Re: Installing older OS X

Hy, that's a nice little tip. Thanks, man. Sent from my iPhone On Nov 18, 2015, at 2:31 AM, Charles Srstka wrote: >> On Nov 18, 2015, at 1:22 AM, Quincey Morris >> wrote: >> >>> On Nov 17, 2015, at 23:13 , Charles Srstka >> > wrote: >>> >>> Oh, sorry, I

Re: Assigning an element of a swift array to a userdata parameter triggers didSet

Yes, that all makes sense. So, the question is what can I do about it? The number of tooltips I need is the same number of elements in the array and the number of elements in the array can change over the lifetime of the application. So, it is natural to store the information needed by the toolt

Re: KVO question

On Nov 17, 2015, at 7:18 PM, Graham Cox wrote: > > I’m using KVO to observe a bunch of properties. > > Most of these properties are split out into simple things that set a single > value, but internal to my object, some end up setting a common dictionary of > attributes, which is also a proper