The same goes for your preferences, your screensaver will read preferences, assuming you already use ScreenSaverDefaults in your screensaver and don't try something fancy (don't, you can't) in the container : ~/Library/Containers/.legacyScreenSaver/Data/Library/Application Support/Aerial So to give you an example, if you want to create an Aerial folder in "Application Support", while you would expect it to be created inĪs it is in Mojave, in Catalina your folder using the same system commands go here : legacyScreenSaver is the one that is sandboxed, and *all* our 3rd party screen savers are living with it's constraints, within it's container. Screen savers are now plugins that are ran by legacyScreenSaver. Hey sorry for not following up with you, I don't get notifications for this forum (despite "following", whatever that means), so you may not see this or it might be too late. Rejecting read of from process 1281 (myScreensaver) because accessing preferences outside an application's container requires user-preference-read or file-read-data sandbox access app tries to read (using CFPreferneces) I get these sorts of errors. The problem is that I'm trying to share preferences between the. Log("# Configure Process Launch, \(dump(arguments)) path=\(path)")ĬonfigProcess?.terminationHandler = configTerminatedHandler Let f3 = self.window?.convertToScreen(f2) Log(" Config Process already running, bringing frontmost") If (configProcess != nil & configProcess!.isRunning) if already running, just bring it frontmost saver bundle contains a helper app, and when the preferences are launched, it simply creates a new Process task and launches the app: I can also confirm that we are called that one time with the preview flag on which is not nice.ĭId you solve this problem? I have a similar architecture: my. For some reason it's on my secondary screen, main screen doesn't get the view init. I can confirm that we are only called once in multiple monitor configuration (you used to get called once per screen).
#Hi tech video screensaver update#
This breaks my workaround for Xcode to compile my screensaver's control panel as an app in a window, and breaks update path for settings for customers migrating from Mojave to Catalina. Preferences also are located in that container (/Preferences/ByHost/ instead of /Caches in previous url) Using the second one works, files are located there as expected, I don't think the first one is usable ? The first one looks weird ? I'm unfamiliar with sandboxing, anyone with more info please chime in. legacyScreenSaver is a sandboxing mechanism ! So if you ask for cache paths, you'll get this :
#Hi tech video screensaver install#
Your screensaver needs to be signed/notarized, while you can override on install an unknown developper build, it will error out again every time you open System Preferences