> On Apr 19, 2025, at 4:53 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>
>>
>> The only thing I can think of is that, if legacyScreenSaver is still running
>> an old instance of your screensaver (which you've learned can now happen),
>> it is somehow caching the special screensaver defau
I ran into this recently with something else. The pList was being modified at
some time by another program.
I set up a process watcher on the file to detect when it was being changed and
which process was changing it.
If you need, I can send you the app I used to do that.
> On Apr 19, 2025, a
On Apr 19, 2025, at 04:53, Gabriel Zachmann via Cocoa-dev
wrote:
>
>
> Is there an easy way to check, if other instances are still running?
I log stuff to see what's going on. Either using standard logging (OSLog, etc)
or write to your own file if trying to filter in Console is too horrible (
PS:
When a Mac is connected to multiple displays, then multiple instances will run
in parallel (on per display).
So, the method to make older instances of a screensaver quit should not kill
those legitimate instances.
>
> The only thing I can think of is that, if legacyScreenSaver is still runn
>
> The only thing I can think of is that, if legacyScreenSaver is still running
> an old instance of your screensaver (which you've learned can now happen), it
> is somehow caching the special screensaver defaults objects and values, so it
> doesn't read from disk the next time you invoke it.
On Apr 18, 2025, at 06:32, Gabriel Zachmann via Cocoa-dev
wrote:
>
>
> This is what I do once the user clicks OK:
>
> [defaults_ setObject: monitor_user_prefs forKey: displayName_];
> [defaults_ synchronize];
The only thing I can think of is that, if legacyScreenSave
>
> Looking at my code to handle the OK and Cancel actions for the config sheet,
> I still have these calls from way back:
>
> [defaults synchronize]; // It says this isn't needed, but it sure seems to be
> for a screensaver pref,
This is what I do once the user clicks OK:
[defaults_ setObject
On Apr 15, 2025, at 07:57, Gabriel Zachmann via Cocoa-dev
wrote:
>
> But that does not explain, why new settings will not become persistent, does
> it?
> I mean, when I do
> [defaults_ setObject: monitor_user_prefs forKey: displayName_];
> the Mac *could* write the new settings into persi
>
> No, that's not what I mean. You won't see multiple legacyScreenSaver
> processes, but you should note that each time you start and stop your
> screensaver, you should see the memory and cpu (depending on how much
I see, yes that seems to be the case , at least for the memory part.
Over time
On Apr 13, 2025, at 16:01, Gabriel Zachmann via Cocoa-dev
wrote:
>
>
> I don't see this on my side.
> I have let macOS launch my screensaver several times,
> but still I see exactly one process:
>legacyScreenSaver (Wallpaper)
> Also, I don't see any process "ArtSaver" (the name of my plug
>
> My screensaver has never experienced this problem with any OS version.
Interesting!
I was losing hope ...
I seem to remember that about 2 years ago a few other people on this list
experienced something similar as I did ...
> You *are* using the correct NSUserDefaults object, right?
> [Scr
On Apr 12, 2025, at 06:34, Gabriel Zachmann via Cocoa-dev
wrote:
>
> The settings of screen savers used to be broken for a long time, i.e., macOS
> would not make them persistent, or it would not "deliver" them to the plugin
> through the regular NSUserDefaults API.
>
> A while ago, I think I
12 matches
Mail list logo
