JohnCoates
Screen Saver problems in macOS 26 Tahoe Beta
Seeing a few issues - some may be affect Aerial, some are more general:
- Tahoe no longer has a Screen Saver pane! It's been removed and is now a modal dialog from within the Wallpaper settings. The modal window is even smaller than the System Settings window, and it's not resizable either.
- There may be a problem again with "previewMode" being misreported by the LegacyScreensaver process? There have been bugs in Sequoia and Sonoma with
ScreensaverView.Init(frame: isPreview)with both the frame and isPreview boolean being incorrect, and I think something similar is happening in Tahoe.
I'm running it now too and can confirm.
Tahoe no longer has a Screen Saver pane! It's been removed and is now a modal dialog from within the Wallpaper settings. The modal window is even smaller than the System Settings window, and it's not resizable either.
This is shameful, seriously, it's way way buried down in menus now.
There may be a problem again with "previewMode" being misreported by the LegacyScreensaver process? There have been bugs in Sequoia and Sonoma with ScreensaverView.Init(frame: isPreview) with both the frame and isPreview boolean being incorrect, and I think something similar is happening in Tahoe.
Let's unfix what we fixed... this is aggravating. I'll check that one and let you know !
I saw the API didn't change (I don't even know why I looked), and didn't check if there was a way to set a default screensaver now.
What I did see though... At install they conveniently replace your set screensaver with a new one ! Again !
How helpful...
Edit: And Safari is atrocious...
I'm also seeing a problem with screensavers that use WKWebView, they seem to be invisible on the second screen on a dual monitor system. Any Aerial problems on 2+ monitor systems?
Yeah massive, seems like it doesn't start on the second monitor at all right now. I thought it worked yesterday, but since they rolled back the fixes for the preview state, maybe they rolled back the multimonitor fixes too ?
I had disabled my workarounds for the latest versions of sequoia but if it's broken again...
Side note, I don't know if you have a mode where you put your screensaver on the desktop, but that has issues too. In Companion if you use destkop mode, I set a window below the icons, and that window does have shader outline thing all around it. Here's a screenshot of it between my two monitors, it's easier to see that way :
I'll look at the multi monitor issue tomorrow and keep you posted. Right now it firmly works on main monitor only, somehow.
Haven't had a chance to investigate much yet, but updated to beta 2, every issue remains.
One thing that confused me : If you use spaces now, you can't set a screensaver easily on all spaces, you have to go to every single one manually, and choose the saver. It's infuriating.
Side note, there's a "Show color in tab" option that appeared in Safari. It dosn't work for me when I disable it, sadly.
just because I haven't seen it mentioned, I'm also experiencing an issue where if I try to change the format in Advanced, a semitransparent blank modal window appears with no way to quit, tab, or otherwise dismiss it besides Force Quit-ting the System Settings app. I wonder if anyone else is experiencing it - if you're willing to have to force quit your settings app if it is so. I just wonder because I copied across my 100+GB cache folder across several installations at this point, so I wonder if it's something there. either way not ideal behaviour even if it is only in my edgy case (is that what they're called? heh)
macOS 26 Tahoe DP Beta 2 btw. I get that there's little sense in leaping to fix even major issues (unlike this) at this point given how little Apple seems interested in actually making life easy for third party screen saver developers, so it makes sense to see how things shape up towards the GM etc... sending love to all you amazing people contributing to this project
Testing in Tahoe Beta 3, I've figured out one of the issues:
When you are in Preview mode (e.g. System Settings / Wallpaper, click the "Screen Savers" button), the OS is launching two instances of legacyScreensaver.
One is fullscreen on the main monitor (which should not be happening at all).
The other has isPreview=true which is correct, but has a Frame of 0,0,0,0, which is wrong.
Reported as FB18697726
That's interesting. I haven't checked my log yet but here on that panel, but I think I may not be in preview mode in that window ? Or maybe I am and I don't remember my workarounds !
I can confirm the two instances though and that's annoying:
They also remain when you close that popup window. Even if you change to another view in System Settings (click monitor, etc), they don't get killed...
And unless I'm mistaken, closing System Settings only kill one. the wallpaper one remains
Ok so I can confirm that we do get things as you described. We get launched twice, once with preview set correctly and 0,0,0,0 as you described, and once again with what I think is the resolution of my main screen (sadly my two screens have the same size here) :
2025-07-08 18:36:42.499 : 🌉 seting up CompanionBridge
2025-07-08 18:36:42.502 : 🖼️ AVinit (.saver) (0.0, 0.0, 0.0, 0.0) p: true o: true
2025-07-08 18:36:42.502 : 🖼️ <AerialView: 0xaed1ab000> viewDidMoveToWindow frame: (0.0, 0.0, 0.0, 0.0) window: Optional(<NSServiceViewControllerWindow: 0xaeccf6000>)
2025-07-08 18:36:42.502 : 🌉 seting up CompanionBridge
2025-07-08 18:36:42.503 : 🖼️ AVinit (.saver) (0.0, 0.0, 2560.0, 1440.0) p: false o: false
2025-07-08 18:36:42.503 : 🖼️ <AerialView: 0x7651a6d00> viewDidMoveToWindow frame: (0.0, 0.0, 2560.0, 1440.0) window: Optional(<NSServiceViewControllerWindow: 0x764cee400>)
-
Just to be sure, I disconnected my second screen and I still get this horrible double startup. I end up having tiny text in the preview because my many workaround layers end up trying to match the screens.
-
Also this happens with Aerial only enabled on one screen (but multiple spaces on that screen).
Other stuff :
-
Multi monitor still badly borked here. I need to set aside some time (sadly I don't have much) to look hard at it, because the log looks fine. I tried various versions with different fixes but I'm a bit lost here :
- Setting it up on one monitor only is always fine.
- Setting it up on two monitors, second monitor is always blank, main monitor is either OK or blank.
This is about what I saw since the first Tahoe so no change here.
There's a thread over on the Apple DevForums which has attracted the attention of DTS Engineer Quinn - if you submit any feedback cases, it may be a good idea to add them to that thread as well:
See https://developer.apple.com/forums/thread/787444
Testing Beta 4, and... It's not good.
I think all of the beta 1-3 issues are there, and there may be a new issue - seems almost like when you exit the screen saver, it's launching another copy? Or maybe transforming it from the process named "... (Screen Saver)" to "...(Wallpaper)"
This was the issue we dealt with a long time ago where calling
exit(0)
was the solution, I wonder if that hack no longer works?
Sigh..
Testing Beta 4, and... It's not good.
Wow you weren't kidding.
I think all of the beta 1-3 issues are there, and there may be a new issue - seems almost like when you exit the screen saver, it's launching another copy?
So, yes, definitely it launches a new copy right now with current exit(0) workaround. I'm not 100% sure the old one is lingering or not, I think it's not.
Or maybe transforming it from the process named "... (Screen Saver)" to "...(Wallpaper)"
So as far as I understand this is what always happened. I'm not sure if the name changes or if we are passed around (my first assumption) but this part isn't new. If you force kill that, it kills all lingering instances.
This was the issue we dealt with a long time ago where calling
exit(0)
Logging is always iffy just before calling exit like we do so I'm not 100% sure yet, but it "looks like" we don't receive the willstop event at all? Or maybe it's just the logging.
3 theories :
- we no longer receive
com.apple.screensaver.willstop, so we don't exit, and somehow we are launched again - we are getting killed by legacyScreenSaver as we should, because they fixed the bug, but somehow the fix launches us again
- we successfully exit, and legacyScreenSaver tries to be helpful and launches us again in case we crash 🥶
I kinda hope it's 2, I wouldn't be surprised it's 3. I'll try to dig around today and see if I can narrow it down.
was the solution, I wonder if that hack no longer works?
A proper api that doesn't rely on legacyScreenSaver.appex ? 😮💨
Short term, force quitting legacyScreenSaver (Wallpaper) is the way to go, but this is localized. It's called legacyScreenSaver (Fond d'écran) in french in Activity Monitor for example, so probably needs to dig a bit more to see how we can narrow it down.
The exit(0) fix didn't work all of the time here, I had users for which it would do it probably at the wrong time (my theory was around the time the processed was passed between the (Screen Saver) and (Wallpaper) processes). So I was considering using the resident app to monitor for those events and do a timed killing there (maybe wait 2 seconds to make sure the transfer was done, all the people that complained had older macs so that's why I wanted to add some delay).
This may be the fix.
Sigh..
Well said
Ok so narrowing it down a bit.
From our point of view :
- We STILL receive
com.apple.screensaver.willstop
16:07:32.220637+0200 legacyScreenSaver Aerial: 🖼️ 📢📢📢 willStop
- We get restarted around 700ms after that :
16:07:32.917351+0200 legacyScreenSaver Aerial: Checking for companion
- I think we still exit legacyScreenSaver and it still works
par défaut 16:07:32.223469+0200 legacyScreenSaver Entering exit handler.
par défaut 16:07:32.223577+0200 legacyScreenSaver Queueing exit procedure onto XPC queue. Any further messages sent will be discarded. activeSendTransactions=0
par défaut 16:07:32.223977+0200 legacyScreenSaver Cancelling XPC connection. Any further reply handler invocations will not retry messages
par défaut 16:07:32.224092+0200 legacyScreenSaver [0x93cc94280] invalidated because the current process cancelled the connection by calling xpc_connection_cancel()
par défaut 16:07:32.224245+0200 legacyScreenSaver Exiting exit handler.
par défaut 16:07:32.224263+0200 legacyScreenSaver XPC connection invalidated (daemon unloaded/disabled)
I don't think it's happy about it.
- It gets relaunched :
par défaut 16:07:32.493391+0200 legacyScreenSaver Extension `/System/Library/Frameworks/ScreenSaver.framework/PlugIns/legacyScreenSaver.appex/Contents/MacOS/legacyScreenSaver` of type: `` launched.
par défaut 16:07:32.493483+0200 legacyScreenSaver Hello, I'm launching as euid = 501, uid = 501, personaid = 1001, type = DEFAULT, name = <private>
(hello indeed...)
It's kinda inscrutable logging after that, but after it does its relaunchy, thing, it relaunches us.
Looking at stuff around us :
- Shield unlock (that's when the lock screen gets removed and desktop comes back) happens AFTER we quit. But wayyy before legacyScreenSaver gets effectively relaunched (although, us quitting too fast could be what triggers it down the road)
par défaut 16:07:32.232992+0200 loginwindow -[LWShieldWindowController lowerShieldWindow] | inform UA unlocked
par défaut 16:07:32.233944+0200 NotificationCenter Received screen lock shield hidden update notification
- Wallpaper agent spews things about changing selection around the time legacyScreenSaver restarts. I don't use that wallpaper extension (it's the built in aerial clone) here but it gets triggered somehow.
par défaut 16:07:32.524405+0200 WallpaperAgent 2D92A18A: BEGIN - [com.apple.wallpaper.extension.aerials] selectedChoicesDidChange
par défaut 16:07:32.525531+0200 WallpaperAgent 2D92A18A: END - [com.apple.wallpaper.extension.aerials] selectedChoicesDidChange
par défaut 16:07:32.525691+0200 WallpaperAgent Scheduling disconnection for 5 minutes from now for com.apple.wallpaper.extension.aerials
par défaut 16:07:32.529620+0200 WallpaperAgent 7A700691: BEGIN - [com.apple.wallpaper.extension.aerials] selectedChoicesDidChange
So to recap, killing still works, but legacyScreenSaver doesn't like that, it restarts itself and restarts us after the shield is already up.
Maybe they changed some timings and we kill too early. Or they added an auto restart somehow to legacyScreenSaver.
I'll try to disable the exit and see what it does, and play around with it more.
I can confirm what you say, using iScreensaver:
- com.apple.screensaver.willstop is still being received - this is good
- calling exit(0) kills the process - this is good (maybe?)
- however, about 700msec later, a new process is launched again, but nothing is visible onscreen at that point (presumably because the screensaver isn't actually supposed to be running)
How can we address this:
- could it be that exit(0) is not needed any longer?
- or perhaps exit(0) is still needed, but we should call it on a delay?
- Or, how about when the second instance gets launched, can we tell that LWSheildWindowControl is missing and exit(0) again? Or would this just trigger an infinite loop of exit(0) - > relaunch ?
Have to go but will be back in an hour or so to try more.
My guess is 2 is maybe the best option, a 2 sec delay on exit is what I'm thinking. I still hold hope 1 is right and they fixed it but who knows right now.
Also when I force quit the legacyScreenSaver (Wallpaper), afaik, it never gets relaunched (and that was the case before too), and from that point on doesn't relaunch us.
Wow, just realized that if you don't kill the legacyScreenSaver (Wallpaper) process, it can get stuck in some sort of Exception loop running 200% CPU:
Analysis of sampling legacyScreenSaver-x86_64 (pid 789) every 1 millisecond
Process: legacyScreenSaver-x86_64 [789]
Path: /System/Library/Frameworks/ScreenSaver.framework/PlugIns/legacyScreenSaver-x86_64.appex/Contents/MacOS/legacyScreenSaver-x86_64
Load Address: 0x100f1a000
Identifier: com.apple.ScreenSaver.Engine.legacyScreenSaver.x86-64
Version: 1.0 (1)
Code Type: X86-64 (translated)
Platform: macOS
Parent Process: launchd [1]
Target Type: live task
Date/Time: 2025-07-23 08:09:24.420 -0700
Launch Time: 2025-07-23 07:43:40.224 -0700
OS Version: macOS 26.0 (25A5316i)
Report Version: 7
Analysis Tool: /usr/bin/sample
Physical footprint: 40.2M
Physical footprint (peak): 40.2M
Idle exit: untracked
----
Call graph:
1869 Thread_8485: Main Thread
+ 1869 start (in dyld) + 3457 [0x201129781]
+ 1869 NSExtensionMain (in Foundation) + 168 [0x7ff808173923]
+ 1869 EXExtensionMain(_:_:) (in ExtensionFoundation) + 766 [0x7ffb0f103f0e]
+ 1869 ??? (in PlugInKit) load address 0x7ff818c1d000 + 0x20d91 [0x7ff818c3dd91]
+ 1869 ??? (in PlugInKit) load address 0x7ff818c1d000 + 0x20425 [0x7ff818c3d425]
+ 1869 ??? (in PlugInKit) load address 0x7ff818c1d000 + 0x20796 [0x7ff818c3d796]
+ 1869 ??? (in PlugInKit) load address 0x7ff818c1d000 + 0x20945 [0x7ff818c3d945]
+ 1869 -[NSXPCListener resume] (in Foundation) + 262 [0x7ff80815014c]
+ 1869 xpc_main (in libxpc.dylib) + 56 [0x7ff806bd4241]
+ 1869 _xpc_main (in libxpc.dylib) + 33 [0x7ff806be21cf]
+ 1869 _xpc_objc_main (in libxpc.dylib) + 720 [0x7ff806bd4684]
+ 1869 NSApplicationMain (in AppKit) + 800 [0x7ff80ad0d3fd]
+ 1869 -[NSApplication run] (in AppKit) + 655 [0x7ff80ad21d96]
+ 1869 -[NSApplication reportException:] (in AppKit) + 724 [0x7ff80b2754d0]
+ 1869 ??? (in <unknown binary>) [0x7ff898a2c190]
Reported this as FB19023176
What a mess. So as far as I can tell, we still don't get killed if I remove the exit() call.
2025-07-23 18:26:42.447 : 🖼️ 📢📢📢 willStop
2025-07-23 18:26:42.447 : 🖼️ <AerialView: 0x9fed7f000> stopAnimation
2025-07-23 18:26:42.447 : 🖼️ <AerialView: 0x9fed7f000> teardown
2025-07-23 18:26:42.447 : 🖼️ <AerialView: 0x9fed7f000> clear notif
2025-07-23 18:26:42.447 : 🖼️ <AerialView: 0x9fed7f000> clear anims
2025-07-23 18:26:42.460 : 🖼️ <AerialView: 0x9fed7f000> observeValue Optional("readyForDisplay") false
I don't see any event coming up after that in the logs.
When I launch again 5 mins after :
2025-07-23 18:31:15.608 : 🖼️ <AerialView: 0x9fed7f000> startAnimation frame (0.0, 0.0, 2560.0, 1440.0) bounds (0.0, 0.0, 2560.0, 1440.0)
Start animation is called again on the previous instance (f000).
2025-07-23 18:31:15.621 : 🌉 seting up CompanionBridge
2025-07-23 18:31:15.621 : 🖼️ AVinit (.saver) (0.0, 0.0, 2560.0, 1440.0) p: false o: false
2025-07-23 18:31:15.621 : 🖼️ <AerialView: 0x9fe4ac600> viewDidMoveToWindow frame: (0.0, 0.0, 2560.0, 1440.0) window: Optional(<NSServiceViewControllerWindow: 0x9fed44c00>)
New instance is created on c600.
2025-07-23 18:31:16.117 : 🖼️ <AerialView: 0x9fe4ac600> startAnimation frame (0.0, 0.0, 2560.0, 1440.0) bounds (0.0, 0.0, 2560.0, 1440.0)
c600 (second instance) receives startAnimation too.
As far as I know in that situation, c600 is the one that displays.
f000 doesn't seem to receive anything else , including the stop events, only c600 gets it.
2025-07-23 18:31:19.695 : 🖼️ 📢📢📢 willStop
2025-07-23 18:31:19.695 : 🖼️ <AerialView: 0x9fe4ac600> stopAnimation
2025-07-23 18:31:19.695 : 🖼️ <AerialView: 0x9fe4ac600> teardown
2025-07-23 18:31:19.695 : 🖼️ <AerialView: 0x9fe4ac600> clear notif
2025-07-23 18:31:19.695 : 🖼️ <AerialView: 0x9fe4ac600> clear anims
2025-07-23 18:31:19.700 : 🖼️ <AerialView: 0x9fe4ac600> observeValue Optional("readyForDisplay") false
And when I launch it a 3rd time :
2025-07-23 18:38:50.640 : 🖼️ <AerialView: 0x9fed7f000> startAnimation frame (0.0, 0.0, 2560.0, 1440.0) bounds (0.0, 0.0, 2560.0, 1440.0)
2025-07-23 18:38:50.718 : 🖼️ <AerialView: 0x9fe4ac900>
- I get a new instance : c900
- The very first instance is still here (f000)
- But I don't see c000 again?
Rinse repeat 4th time :
2025-07-23 18:43:14.134 : 🖼️ <AerialView: 0x9fed7f000> startAnimation frame (0.0, 0.0, 2560.0, 1440.0) bounds (0.0, 0.0, 2560.0, 1440.0)
2025-07-23 18:43:14.152 : 🖼️ <AerialView: 0x9fe4acc00> viewDidMoveToWindow frame: (0.0, 0.0, 2560.0, 1440.0) window:
- cc00 is the new one
- f000 is still kicking ?
- c000, c600, c900 are nowhere to be found
I'm not sure if my logging is flawed or if they "tried" to fix by closing instances. I'll try spending some time with my minimalscreensaver testbed as it's a better platform to try and analyze it more.
I'm really surprised that :
- some instances "may be destroyed" (but not 1st one)
- the very first one may remain but seems to be "semi frozen" (I usually spew log events for many things, and there's nothing kicking as far as I can see)
It could be part of a fix they are trying right now. Maybe they kill everything but the first one, or they don't send some events (like startAnimation) to anything but the first one and current one. Need to think more about this, it's hopefully weird ?
Ok let's kill the hopeful part of the weird, I think this is just because my attempts at tearing down on my own were a bit too good, it's still definitely stacking instances!
2025-07-23 19:03:45.002 : 🖼️ 📢📢📢 willStop
2025-07-23 19:03:45.002 : 🖼️ <AerialView: 0xabc538c00> stopAnimation
2025-07-23 19:03:45.003 : 🖼️ 📢📢📢 willStop
2025-07-23 19:03:45.003 : 🖼️ <AerialView: 0xabc538600> stopAnimation
2025-07-23 19:03:45.004 : 🖼️ 📢📢📢 willStop
2025-07-23 19:03:45.004 : 🖼️ <AerialView: 0xabc538300> stopAnimation
2025-07-23 19:03:45.005 : 🖼️ 📢📢📢 willStop
2025-07-23 19:03:45.005 : 🖼️ <AerialView: 0xabcd7f000> stopAnimation
startAnimation is still only sent to the first one (still f000 here) so at least that's one weirdness.
But we're still stacking instances and hogging memory if we don't exit(0).
Will try the delayed exit and report.
Ok good news, the 2 second delay seems to work perfectly.
par défaut 19:15:37.401387+0200 legacyScreenSaver Aerial: 🖼️ 📢📢📢 willStop
par défaut 19:15:37.401902+0200 legacyScreenSaver Aerial: 🖼️ ⏱️ Setting up 2-second delayed exit
par défaut 19:15:37.402920+0200 legacyScreenSaver Aerial: 🖼️ <AerialView: 0xb46d87900> stopAnimation
par défaut 19:15:37.406944+0200 legacyScreenSaver Aerial: 🖼️ <AerialView: 0xb46d87900> teardown
par défaut 19:15:37.407285+0200 legacyScreenSaver Aerial: 🖼️ <AerialView: 0xb46d87900> clear notif
par défaut 19:15:37.407434+0200 legacyScreenSaver Aerial: 🖼️ <AerialView: 0xb46d87900> clear anims
par défaut 19:15:37.418839+0200 legacyScreenSaver Aerial: 🖼️ <AerialView: 0xb46d87900> observeValue Optional("readyForDisplay") false
par défaut 19:15:39.502413+0200 legacyScreenSaver Aerial: 🖼️ 🚪 Exiting application now
We don't get launched again. We get properly relaunched on subsequent launches. You can see legacyScreenSaver(Wallpaper) dying (with maybe a bit of glee) in Activity Monitor, and not get restarted.
Code wise I just do an asyncAfter when receiving willstop :
debugLog("🖼️ ⏱️ Setting up 2-second delayed exit")
DispatchQueue.main.asyncAfter(deadline: .now() + 2.0) {
debugLog("🖼️ 🚪 Exiting application now")
exit(0)
}
One thing I didn't check yet is what happens on onSleepNote. @xmddmx I don't know if you looked there if our exit(0) strategy also failed by getting restarted ? Maybe it could use a delay ?
Great work! - Seems like a decent workaround. I wonder if 2.0 seconds is the "right" delay - too long and a person might launch the screensaver again (e.g. with HotCorner or the Preview button), too short and you might trigger the "re-launch" behavior.
One thing I didn't check yet is what happens on onSleepNote
Sorry, what is onSleepNote - when does that happen?
Great work! - Seems like a decent workaround. I wonder if 2.0 seconds is the "right" delay - too long and a person might launch the screensaver again (e.g. with HotCorner or the Preview button), too short and you might trigger the "re-launch" behavior.
Preview is a separate thread, so that shouldn't be an issue.
But I hear your point about the hotcorner in succession. I did try (2 seconds is hard) and it seems to still work, but I see some blinking which is weird ! I'll stick to that for now but I think you are right in that we could probably do 1 sec, or 500ms. I think it's a hard balance to tweak, if you consider old macs etc
One thing I didn't check yet is what happens on onSleepNote
Sorry, what is onSleepNote - when does that happen?
This is when the screensaver exits before going fully to sleep. Look for screen lock settings in macOS
This is on a desktop, basically if you set that for one hour, your mac will have the screensaver working for one hour before going to sleep. On battery it's when it goes fully to sleep.
And in that case we stacked instances too .So my workaround was to also exit(0) when the willSleep notification is shown.
NSWorkspace.shared.notificationCenter.addObserver(
self, selector: #selector(onSleepNote(note:)),
name: NSWorkspace.willSleepNotification, object: nil)
This is how you catch that notification.
Interesting - we use a different technique in which we read the display sleep time:
/usr/bin/pmset -g | /usr/bin/grep displaysleep | /usr/bin/awk '{ print $2 }'
then set a timer that will fire at that time.
We don't call exit(0), but do tear down all resources and stop animation.
I think this approach might leave an orphan legacyScreenSaver process running, but since it's doing nothing it shouldn't be using much CPU or RAM.
Your approach may be better?
re: multi-monitor behavior in Beta 4 - still not working properly, however at least once, upon exiting the screensaver, I saw a brief flash of the correct content on the second monitor, as if it was running perfectly, just hidden -
I wonder if there's some sort of mistaken blocking window covering up the content on the second monitor?
We don't call exit(0), but do tear down all resources and stop animation.
Yeah in that case it 100% stack an instance. It's not that terrible if you teardown as much as you can, because when the next time you do a hot corner/exit of it, it gets cleaned up with the exit(0), but I avoided it that way too.
I'll check on my end what happens tomorrow with my fix, see if it still works there.
I wonder if there's some sort of mistaken blocking window covering up the content on the second monitor?
Yeah that could be it actually.
It's pretty clear it's broken, but it's not the same kind of broken as it used to be because the fix doesn't fix it, and removing the fix doesn't help either. There's something different this time. And same, needs more investigating, will keep you posted.
Ok tiny update, I've started working on the ScreenSaverMinimal base code (https://github.com/AerialScreensaver/ScreenSaverMinimal) to try and narrow down some of the issues. I've added some instance count tracking to know how many are in memory, and which one we are. This should be helpful to track things more.
Some insights :
- As we suspected, what is shown on screen is always the newly created instance, not a previous one.
- Previously, System Settings launched a completely separate context as far as I know from the screensaver ones. No longer the case (and maybe why the isPreview is bugged). You could see this before where you could update the screensaver, system settings would be still on the old version, but the new one would show as the screensaver. So now that's not true, Screensaver AND System Settings are run in the same context and instances are part of the same pile.
- The tiny preview and the one that shows full screen are each a separate instance <- we will need to take this into account with the timed exit trick. This is extra bad now because we can't detect previews.
- The tiny preview is NOT reinstanced every time you open the panel while System Settings is still open. Even if you go to another panel (like spotlight, then back to wallpaper and click screensaver, it won't recreate then)
- If you close System Settings and reopen it, then the tiny preview is a new instance again
- Haven't played yet too much with multiple monitor but that should be next
My goal is to add switches for the various bugs and our workarounds in the settings (I've started with the exit one but not implemented yet) and add corresponding radar numbers so it can be shared on forums/radars and hopefully eskimo will hurry things there.
Still digging but found this which I think confirm the é&@-é&@^rpé" of the situation :
par défaut 15:19:09.509004+0200 WallpaperAgent A85D5DF3: BEGIN - makeWallpaper for '[screenSaver] /Users/guillaume/Library/Screen Savers/ScreenSaverMinimal.saver'
par défaut 15:19:09.509489+0200 WallpaperAgent A555DFCB: BEGIN - Initialize screen saver wallpaper for module Optional("com.glouel.ScreenSaverMinimal")
par défaut 15:19:09.516292+0200 WallpaperAgent A555DFCB: END - Initialize screen saver wallpaper for module Optional("com.glouel.ScreenSaverMinimal")
par défaut 15:19:09.516324+0200 WallpaperAgent A85D5DF3: END - makeWallpaper for '[screenSaver] /Users/guillaume/Library/Screen Savers/ScreenSaverMinimal.saver'
I think the expectation is set that every saver could be a wallpaper (which it could in the old days). And that would be cool, but clearly that's likely what causes this entire mess. Allow it and make it work, or don't 🙄
And the new UI in System Settings, if anything, goes completely against this. Unless you want to make legacy savers disappear, and have only appex that can do wallpaper AND saver with transitions to one another. All for it, but API needed.
I wonder if there's a way to opt-out of the "makeWallpaper" function.
I think Apple has some of their own screensavers which still use the Legacy system? Or did they finally update all of them to the new API?
We should look and see if perhaps there's an undocumented plist entry which says "don't make me a wallpaper"?
Floating Message and Random are still .saver, in '/System/Library/Screen Savers'
I didn't see anything in the Info.plist but maybe you'll see something.
I didn't see anything either, comparing various .saver files.
I also noticed that in the new .APPEX screensavers, the "use as wallpaper" option exists for some, but not all of them.
I compared a few plists and couldn't find anything that corresponds.
Guessing it's some sort of internal call, perhaps something like the existing 'hasConfigureSheet' boolean?