Re: Screen saver settings don't take effect (again) under Sonoma
> On Feb 1, 2024, at 11:53, Gabriel Zachmann wrote: > > NSRegistrationDomain > The domain consisting of a set of temporary defaults whose values can be set > by the application to ensure that searches will always be successful. Yes. Remember that registered defaults DO NOT appear in the on-disk defaults. They’re only used in-memory in case you ask for a default that the user hasn’t actually set/changed. > I noticed something rather curious: my screensaver continues to run, even > though I quit System Settings. > But I can see messages from my screen saver appearing in the log even a long > time afterwards. > Could that be related to me problem with the persistence of the settings? That’s a new bug Apple gave us. I’ve reported it, but you should too so it gets some attention. I’ve changed to doing most of my “shut down” code in response to the screensaver stopped notification (not at a computer right now to say what it actually is) to work around that glaring bug. I’m guessing they forgot that people will still use normal screensavers and not just their new “It’s a desktop! It’s a screensaver! It’s both!” thing. If you’re caching values from defaults in some variable/property of your screensaver view, it could be that the view never actually gets deallocated. I’d suggest adding LOTS of logging all over your code. Use something like a #define LOG(s) etc so you can turn it on and off with a compiler directive and not have to put in dozens of #ifs. Put them on each method entrance and exit, log display names, log user defaults, everything. Then you can filter on your screensaver’s name in Console, start the log in Console, then start your screensaver, stop it, stop logging, and see what’s going on. Steve via iPad ___ 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: Screen saver settings don't take effect (again) under Sonoma
: > displayname]; > > Then, I read the actual values from monitor_user_prefs. > > When the user changes a setting, I do the inverse, like this: > > .. create a new dictionary monitor_user_prefs, containing all the key/value > pairs of the settings .. > [defaults_ setObject: monitor_user_prefs forKey: displayName_]; > bool success = [defaults_ synchronize]; > > > -- next part -- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 5821 bytes > Desc: not available > URL: > <https://lists.apple.com/archives/cocoa-dev/attachments/20231012/e3a91277/attachment.bin> > > -- > > Message: 2 > Date: Thu, 12 Oct 2023 08:22:21 -0500 > From: Steve Mills > To: Cocoa dev > Subject: Re: Screen saver settings don't take effect (again) under > Sonoma > Message-ID: <0d02e197-d36a-4a4b-ac48-297848fe9...@mac.com> > Content-Type: text/plain; charset=us-ascii > >> On Oct 12, 2023, at 04:54, Gabriel Zachmann via Cocoa-dev >> wrote: >> >> Now, under Sonoma (14.0), I have an issue with the settings (user defaults) >> of my screen saver, again. >> >> I go into System Settings, change some settings of my screen saver, they >> take effect immediately in the little Preview window in SysSettings, but >> when I click on "Preview" or let the screen saver come on automatically, the >> new settings are *not* in effect. >> >> From one user, I heard that the new settings take effect only after >> rebooting. >> >> So, maybe, something has changed in the way macOS 14.0 handles the >> NSUserDefaults, and/or maybe I make an error with using the API. Maybe there >> is a bug in macOS 14.0 ? >> >> Below you can find a recap of how I handle the settings using NSUserDefaults. >> Interestingly, the same code works fine in a regular app (not screensaver). >> >> My screensaver stores different settings for different monitors in the >> [NSUserDefaults standardUserDefaults]. >> To do so, I generate >> defaults_ = [NSUserDefaults standardUserDefaults]; >> >> Then, I create a dictionary containing the default settings and register >> them, like this: >> >> NSDictionary * monitor_defaults = [NSDictionary >> dictionaryWithObjectsAndKeys: defaultsForMonitor, displayname, nil ]; >> [defaults_ registerDefaults: monitor_defaults]; >> NSDictionary * monitor_user_prefs = [defaults_ dictionaryForKey: >> displayname]; >> >> Then, I read the actual values from monitor_user_prefs. >> >> When the user changes a setting, I do the inverse, like this: >> >> .. create a new dictionary monitor_user_prefs, containing all the key/value >> pairs of the settings .. >> [defaults_ setObject: monitor_user_prefs forKey: displayName_]; >> bool success = [defaults_ synchronize]; > > registerDefaults isn't doing what you think it's doing. Read its docs more > carefully. > > And there's no need to call synchronize. The docs clearly point that out: > "this method is unnecessary and shouldn't be used." > > To set a new default, simply use setObject:forKey:. To read them, simply use > objectForKey: or dictionaryForKey:, since you're using one. > > What you haven't shown is how you're coming up with a screen name. Are you > sure it's the same every time for each screen? > > Also, you *are* using the correct NSUserDefaults object, yes? > > NSUserDefaults* defaults = [ScreenSaverDefaults > defaultsForModuleWithName:@"com.yourcompany.yourscreensaver"]; > > -- > Steve Mills > Drummer, Mac geek > > > > -- > > Message: 3 > Date: Thu, 12 Oct 2023 06:43:49 -0700 > From: Michael Diehr > To: Cocoa dev > Subject: Re: Screen saver settings don't take effect (again) under > Sonoma > Message-ID: <50200ccb-4313-4898-b9f1-c72b15257...@xochi.com> > Content-Type: text/plain; charset=us-ascii > > There's an active discussion rying to reverse-engineer the screen saver > settings in Sonoma over on GitHub: > https://github.com/JohnCoates/Aerial/issues/1332 > > > > -- > > Subject: Digest Footer > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins (at) lists.apple.com > > https://lists.apple.com/mailman/listinfo/cocoa-dev > > > -- > > End of Cocoa-dev Digest, Vol 20, Issue 55 > * smime.p7s Description: S/MIME cryptographic signature ___ 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: Screen saver settings don't take effect (again) under Sonoma
There's an active discussion rying to reverse-engineer the screen saver settings in Sonoma over on GitHub: https://github.com/JohnCoates/Aerial/issues/1332 ___ 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: Screen saver settings don't take effect (again) under Sonoma
> On Oct 12, 2023, at 04:54, Gabriel Zachmann via Cocoa-dev > wrote: > > Now, under Sonoma (14.0), I have an issue with the settings (user defaults) > of my screen saver, again. > > I go into System Settings, change some settings of my screen saver, they take > effect immediately in the little Preview window in SysSettings, but when I > click on "Preview" or let the screen saver come on automatically, the new > settings are *not* in effect. > > From one user, I heard that the new settings take effect only after rebooting. > > So, maybe, something has changed in the way macOS 14.0 handles the > NSUserDefaults, and/or maybe I make an error with using the API. Maybe there > is a bug in macOS 14.0 ? > > Below you can find a recap of how I handle the settings using NSUserDefaults. > Interestingly, the same code works fine in a regular app (not screensaver). > > My screensaver stores different settings for different monitors in the > [NSUserDefaults standardUserDefaults]. > To do so, I generate > defaults_ = [NSUserDefaults standardUserDefaults]; > > Then, I create a dictionary containing the default settings and register > them, like this: > > NSDictionary * monitor_defaults = [NSDictionary > dictionaryWithObjectsAndKeys: defaultsForMonitor, displayname, nil ]; > [defaults_ registerDefaults: monitor_defaults]; > NSDictionary * monitor_user_prefs = [defaults_ dictionaryForKey: > displayname]; > > Then, I read the actual values from monitor_user_prefs. > > When the user changes a setting, I do the inverse, like this: > > .. create a new dictionary monitor_user_prefs, containing all the key/value > pairs of the settings .. > [defaults_ setObject: monitor_user_prefs forKey: displayName_]; > bool success = [defaults_ synchronize]; registerDefaults isn't doing what you think it's doing. Read its docs more carefully. And there's no need to call synchronize. The docs clearly point that out: "this method is unnecessary and shouldn't be used." To set a new default, simply use setObject:forKey:. To read them, simply use objectForKey: or dictionaryForKey:, since you're using one. What you haven't shown is how you're coming up with a screen name. Are you sure it's the same every time for each screen? Also, you *are* using the correct NSUserDefaults object, yes? NSUserDefaults* defaults = [ScreenSaverDefaults defaultsForModuleWithName:@"com.yourcompany.yourscreensaver"]; -- Steve Mills Drummer, Mac geek ___ 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
