Re: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 11:43,Jerome Krinock  wrote:
> 
> 
>> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann  wrote:
>> 
>> 
>>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>>> 
 On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>>> 
 Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
 return NSNull instead of old or new values.
>>> 
>>> That only happens during that first spurious call, when the observer is 
>>> added.
>> 
>> Happens for me all the time. Never seen anything other than NSNull.
> 
> Well, then there is something weird in your app, or in mine.  I would bet on 
> yours, because if such change notifications were broken in 10.12, thousands 
> of apps would not work.  Create a small demo project and try to reproduce.

I have just done this (can send it to you if you are interested).
Messing around with this test app I found a few bugs (or to be cautious: a few 
things I did not expect):

Bug1:   no NSKeyValueObservingOptionOld. Should have old value, but just has 
NSNull

Bug2:   called at start (after applicationDidFinishLaunching) - although 
nothing has changed yet

Bug3:   any change is observed twice

Bug4:   changes not keep on quit
Check:  change a TextField; do not use CR or leave the TextField; quit the app. 
Start it again.
Maybe this is the way it should be. But in the age of autoSave 
it feels a bit strange though.

Bug5:   changing a TextField to empty string reverts to registrationDefaults 
for this TextField.
Check:  start app; set both TextFields to other than registrationDefaults; quit.
start app again; select any TextField; hit "delete", then CR or 
tab to other TextField →
empty string will be replaced by the registrationDefault.

This happens only once per TextField. Replacing the 
registrationDefault again with an empty
string just keeps this empty string.
At the next start of the app, the empty string will again be 
replaced by the registrationDefault.

Maybe this is the way it should be: empty string → nil and nil 
→ registrationDefault.
Feels a bit strange though.

Bug6:   sometimes the first change in any TextField reverts to 
registrationDefaults for both TextFields
Check:  not reproducible. Just happens when it feels like it: sometimes bug a 
few times in a row,
sometimes no bug half a dozen times.

Here I finally caught the bug:

start app, the two textfields are “a3" resp. "b3":

12:04:58.755044  +[AppDelegate initialize] registerDefaults {
12:04:58.894584  -[AppDelegate field1:] "a3"
12:04:58.901718  -[AppDelegate applicationDidFinishLaunching:] Done
12:04:59.056890  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField2 = "b3";
12:04:59.057120  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField2 = "b3"
12:04:59.057336  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField1 = "a3";
12:04:59.057365  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField1 = "a3"

changing field2 to "b4":

12:05:03.028507  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField2 = "text2";
12:05:03.028605  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField2 = "text2"
12:05:03.030307  -[AppDelegate field2:] "b4"
12:05:03.049222  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField2 = "text2";
12:05:03.049275  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField2 = "text2"
12:05:03.049579  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaultsController.values.TextField1 = "text1";
12:05:03.049600  -[AppDelegate observeValueForKeyPath:ofObject:change:context:] 
UserDefaults.TextField1 = "text1"



>> Current work-around: just ignore every second notification (i.e. ginore 1., 
>> 3rd, 5th etc.).
>> Not a very good solution, rather bound to break sooner or later. But okay 
>> for the time being.
> 
> “Not a very good solution”, indeed.  If I understand you correctly, if you 
> ran your app in 10.11 with this “solution”, it wouldn’t work.  
Highly probable that it won’t work.

> The workaround that I suggested …
But your workaround is based on the observation that the change dictionary has 
different content in different situations - which is something I never see here.


Kind regards,

Gerriet.


___

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

Re: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 09:55, Gary L. Wade  wrote:
> 
> I have a thought.  Do you have a binding somewhere on a property in 
> NSUserDefaults?  

I just made a small test app: not document based, two TextFields bound to User 
Defaults Controller at values.TextField1, resp. …2.
Both observed via addObserver:forKeyPath:…

> Maybe your document is getting synchronised to iCloud and/or getting 
> autosaved very often?  

As far as I know, I am not using iCloud at all. Neither using auto save or 
anything.

If you (or anyone else) are interested, I can send you the test app project.

Kind regards,

Gerriet.


> These are things I’ve seen that can cause uncharacteristically often updates.
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Oct 18, 2016, at 7:32 PM, Gerriet M. Denkmann  wrote:
>> 
>> 
>>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>>> 
 On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
 
 My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 
 12 observeValueForKeyPath:… is called at the start of the program, 
 although nothing has changed yet.  When the value actually changes, it is 
 called twice.
>>> 
>>> I just added some code to one of my apps, to test this.  It confirmed your 
>>> observations, although I only tested in 10.12.
>>> 
 Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
 return NSNull instead of old or new values.
>>> 
>>> That only happens during that first spurious call, when the observer is 
>>> added.
>> 
>> Happens for me all the time. Never seen anything other than NSNull.
>> 
>> Current work-around: just ignore every second notification (i.e. ginore 1., 
>> 3rd, 5th etc.).
>> Not a very good solution, rather bound to break sooner or later. But okay 
>> for the time being.
>> 
>>> 
 If indeed this behavior is new in 10.12, it certainly warrants a Bug 
 Report.
>> 
>> Ok, will do so.
>> 
>> Kind regards,
>> 
>> Gerriet.
> 


___

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: inconsistencies in view renderings

[Quincey Morris]

On Oct 18, 2016, at 19:43 , Alan Snyder  wrote:
> 
> Well, try this on Sierra:
> 
> Use the Open File… menu item of Safari to open a dialog. Then activate a 
> different application. On my system, the Cancel button in the dialog grays 
> out (although it still looks different than the disabled Open button). Now 
> click the Cancel button. Even though the button is grayed out, on my system 
> the dialog is dismissed.

Yup, that works as you say. Guess why? (You won’t like the answer.)

The buttons change appearance when they’re in a window margin at the bottom of 
an inactive window (and, I would expect, when they’re in a toolbar at the top). 
If they’re in the body of the window, they don’t change.

I’ve lost track of what the point is here. Apparently there is no programmatic 
way to control to inactive appearance, and “acceptsFirstResponder” only affects 
the inactive behavior. Is there something you were trying to do that you 
couldn’t, or was it only about explaining the apparent inconsistency?

___

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: observeValueForKeyPath:... called too often in macOS 12

[Jerome Krinock]

> On 2016 Oct 18, at 19:32, Gerriet M. Denkmann  wrote:
> 
> 
>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>> 
>>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>> 
>>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
>>> return NSNull instead of old or new values.
>> 
>> That only happens during that first spurious call, when the observer is 
>> added.
> 
> Happens for me all the time. Never seen anything other than NSNull.

Well, then there is something weird in your app, or in mine.  I would bet on 
yours, because if such change notifications were broken in 10.12, thousands of 
apps would not work.  Create a small demo project and try to reproduce.

> Current work-around: just ignore every second notification (i.e. ginore 1., 
> 3rd, 5th etc.).
> Not a very good solution, rather bound to break sooner or later. But okay for 
> the time being.

“Not a very good solution”, indeed.  If I understand you correctly, if you ran 
your app in 10.11 with this “solution”, it wouldn’t work.  The workaround that 
I suggested (filtering for substantive changes), you know, at least it has a 
logical basis, and if Apple changes this undocument behavior back to the old 
undocumented behavior, it should still work.


___

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: observeValueForKeyPath:... called too often in macOS 12

[Gary L. Wade]

I have a thought.  Do you have a binding somewhere on a property in 
NSUserDefaults?  Maybe your document is getting synchronized to iCloud and/or 
getting autosaved very often?  These are things I’ve seen that can cause 
uncharacteristically often updates.
--
Gary L. Wade
http://www.garywade.com/ 
> On Oct 18, 2016, at 7:32 PM, Gerriet M. Denkmann  wrote:
> 
> 
>> On 19 Oct 2016, at 02:00,Jerome Krinock :
>> 
>>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>>> 
>>> My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 
>>> 12 observeValueForKeyPath:… is called at the start of the program, although 
>>> nothing has changed yet.  When the value actually changes, it is called 
>>> twice.
>> 
>> I just added some code to one of my apps, to test this.  It confirmed your 
>> observations, although I only tested in 10.12.
>> 
>>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
>>> return NSNull instead of old or new values.
>> 
>> That only happens during that first spurious call, when the observer is 
>> added.
> 
> Happens for me all the time. Never seen anything other than NSNull.
> 
> Current work-around: just ignore every second notification (i.e. ginore 1., 
> 3rd, 5th etc.).
> Not a very good solution, rather bound to break sooner or later. But okay for 
> the time being.
> 
>> 
>>> If indeed this behavior is new in 10.12, it certainly warrants a Bug Report.
> 
> Ok, will do so.
> 
> Kind regards,
> 
> Gerriet.

___

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: inconsistencies in view renderings

[Alan Snyder]

That sounds rather mysterious. What kind of project configuration would affect 
the display of buttons?

Well, try this on Sierra:

Use the Open File… menu item of Safari to open a dialog. Then activate a 
different application. On my system, the Cancel button in the dialog grays out 
(although it still looks different than the disabled Open button). Now click 
the Cancel button. Even though the button is grayed out, on my system the 
dialog is dismissed.

(I believe Cancel and Open are textured buttons on Sierra, as clicking them 
flashes gray, not blue.)


> On Oct 18, 2016, at 6:07 PM, Quincey Morris 
>  wrote:
> 
> If you are seeing a difference, something else is going one, such as a slight 
> configuration difference in my test project.

___

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: observeValueForKeyPath:... called too often in macOS 12

[Gerriet M. Denkmann]

> On 19 Oct 2016, at 02:00,Jerome Krinock :
> 
>> On 2016 Oct 14, at 23:08, Gerriet M. Denkmann  wrote:
>> 
>> My app (macOS 12) observes a value in NSUserDefaults.  Starting with macOS 
>> 12 observeValueForKeyPath:… is called at the start of the program, although 
>> nothing has changed yet.  When the value actually changes, it is called 
>> twice.
> 
> I just added some code to one of my apps, to test this.  It confirmed your 
> observations, although I only tested in 10.12.
> 
>> Also: NSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld just 
>> return NSNull instead of old or new values.
> 
> That only happens during that first spurious call, when the observer is added.

Happens for me all the time. Never seen anything other than NSNull.

Current work-around: just ignore every second notification (i.e. ginore 1., 
3rd, 5th etc.).
Not a very good solution, rather bound to break sooner or later. But okay for 
the time being.

> 
>>  If indeed this behavior is new in 10.12, it certainly warrants a Bug Report.

Ok, will do so.

Kind regards,

Gerriet.


___

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: inconsistencies in view renderings

[Quincey Morris]

On Oct 18, 2016, at 17:58 , Alan Snyder  wrote:
> 
> Sounds like you were not using textured rounded buttons, which are the ones 
> that I wrote about.

I tried one of those and one regular button, and the textured rounded didn’t 
seem to change at all. Note that IIRC you’d normally use textured rounded in a 
tool or status bar, and the bar background changes color when the window goes 
inactive, but I can’t see any difference in the button itself. And there was no 
visible difference in the IB window, where it was stuck in the middle of a view.

If you are seeing a difference, something else is going one, such as a slight 
configuration difference in my test project.
___

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: inconsistencies in view renderings

[Alan Snyder]

Sounds like you were not using textured rounded buttons, which are the ones 
that I wrote about.



> On Oct 18, 2016, at 1:00 PM, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 12:17 , Alan Snyder  > wrote:
>> 
>> The implication is that AppKit is probing the application at unspecified 
>> times with a fake event?
> 
> Well, I had to try it in a test project. I don’t see *any* difference in 
> appearance in the buttons, with acceptsFirstResponder YES or NO, regardless 
> of window state, regardless of IB canvas or running application, *except* 
> that colored highlights (the blue indicating a default button, or the blue 
> menu indicator on a popup button) change to gray in an inactive window.
> 
> This is with macOS Sierra. It’s possible that earlier iterations of the OS X 
> UI did have an inactive appearance for buttons, and my feeble recollection is 
> that this was so for a while in the 10.6-10.8 era, at least.
> 
> Perhaps what I did at the time was disable the button when the window went 
> inactive.
> 
>> Nothing in the documentation of acceptsFirstMouse suggests such a thing.
> 
> Well, the event parameter is allowed to be nil (and AppKit headers have been 
> audited for nullability, so it’s not likely to be an oversight).
> 

___

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: inconsistencies in view renderings

[Quincey Morris]

On Oct 18, 2016, at 12:17 , Alan Snyder  wrote:
> 
> The implication is that AppKit is probing the application at unspecified 
> times with a fake event?

Well, I had to try it in a test project. I don’t see *any* difference in 
appearance in the buttons, with acceptsFirstResponder YES or NO, regardless of 
window state, regardless of IB canvas or running application, *except* that 
colored highlights (the blue indicating a default button, or the blue menu 
indicator on a popup button) change to gray in an inactive window.

This is with macOS Sierra. It’s possible that earlier iterations of the OS X UI 
did have an inactive appearance for buttons, and my feeble recollection is that 
this was so for a while in the 10.6-10.8 era, at least.

Perhaps what I did at the time was disable the button when the window went 
inactive.

> Nothing in the documentation of acceptsFirstMouse suggests such a thing.

Well, the event parameter is allowed to be nil (and AppKit headers have been 
audited for nullability, so it’s not likely to be an oversight).

___

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: inconsistencies in view renderings

[Alan Snyder]

I was afraid you would say that…

The implication is that AppKit is probing the application at unspecified times 
with a fake event? Nothing in the documentation of acceptsFirstMouse suggests 
such a thing.

I have not found any other API so far.

  Alan



> On Oct 18, 2016, at 9:51 AM, Quincey Morris 
>  wrote:
> 
> On Oct 18, 2016, at 08:00 , Alan Snyder  wrote:
>> 
>> Is the choice to gray or not to gray when inactive under programmer control?
> 
> IIRC you can control this by the the value of “acceptsFirstMouse”. The NSView 
> default is NO, but NSButton overrides it to return YES. To change it back 
> again, you need to subclass NSButton and override the method. (But it’s a 
> while since I’ve had to deal with this, and there may be other API for 
> directly controlling the appearance.)
> 
> 


___

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: inconsistencies in view renderings

[Quincey Morris]

On Oct 18, 2016, at 08:00 , Alan Snyder  wrote:
> 
> Is the choice to gray or not to gray when inactive under programmer control?

IIRC you can control this by the the value of “acceptsFirstMouse”. The NSView 
default is NO, but NSButton overrides it to return YES. To change it back 
again, you need to subclass NSButton and override the method. (But it’s a while 
since I’ve had to deal with this, and there may be other API for directly 
controlling the appearance.)



___

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: inconsistencies in view renderings

[Alan Snyder]

Is the choice to gray or not to gray when inactive under programmer control?


> On Oct 18, 2016, at 12:08 AM, Quincey Morris 
>  wrote:
> 
> Keep in mind that buttons have *two* kinds of graying these days. One 
> indicates that the button is disabled. The other indicates that the button is 
> in an inactive window and does not accept mouse clicks until the window has 
> first been made active (thus preventing an inadvertent click on a non-front 
> window’s controls).
> 
> Typically, buttons in inactive windows *do* accept mouse clicks, and retain 
> their ungrayed appearance, which is why the appearance doesn’t change when 
> one of your windows is inactive.

___

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: inconsistencies in view renderings

[Quincey Morris]

On Oct 17, 2016, at 21:16 , Alan Snyder  wrote:
> 
> In IB, when the IB window is inactive, the buttons display in a grayed out 
> fashion. In the actual application, when the application window is inactive, 
> the button displays do not change.
> 
> What might be causing this difference in rendering?

Keep in mind that buttons have *two* kinds of graying these days. One indicates 
that the button is disabled. The other indicates that the button is in an 
inactive window and does not accept mouse clicks until the window has first 
been made active (thus preventing an inadvertent click on a non-front window’s 
controls).

Typically, buttons in inactive windows *do* accept mouse clicks, and retain 
their ungrayed appearance, which is why the appearance doesn’t change when one 
of your windows is inactive. Buttons in IB are really just graphic elements 
(clicking them selects them rather than performing an IBAction), so IB gets to 
draw them in inactive windows however it wants. Perhaps it’s intentionally 
indicating there’s no click-through behavior in this case, or perhaps it’s just 
a quirk of IB that it draws things grayed out.

___

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