VenturaSaver2Cpx: the Ventura Screensaver and Mouse Events bug

Let's take this as given: macOS screensavers should, optionally, be programmed to let users interact with keyboard or mouse while the screensaver is running. I believe "Mowing Man" was one of the first to do this?

What about recent versions of macOS?

• in macOS High Sierra, Apple removed the ability for a screensaver to launch a helper app which could display content by creating a new window at level 2002 or higher. The helper app, being a regular macOS app, had full keyboad / mouse permissions, and was easy to test & debug. This macOS change broke a lot of code (iScreensaver, SETI @ home...) We reworked our apps to deal with it.
• in macOS Mojave, Apple added a bunch of new restrictions on keyboard and mouse usage, but we figured out ways to get around almost all of them them.
• in macOS Catalina, Apple blocked screensavers from using any keyboard events, and made using Mouse events difficult (especially with 2+ monitor systems). We could not figure out how to enable keyboard events, but we did figure out a workaround to handle mouse events on 2+ screens
• in macOS Ventura, Apple again changed things. There still appears to be no way to get keyboard events to a running screensaver. In addition, techniques used in Catallina to receive mouseEvents are stymied.
• (through beta 9) In a Ventura .saver, even if you try to capture mouse events, once the mouse has moved 200 pixels (in either X or Y direction) the screensaver exits.
• it appears that the event or responsder order is different in Ventura: In a Monterey screensaver, you can use NSEvent addLocalMonitorForEvents to capture an event, forward it to your NSView, and then return nil (to prevent the parent Screen Saver app from seeing it). In Ventura something has changed - my best guess is that the ScreenSaverEngine reads the mouseMoved event before sending it to the .saver process. So there's no way to block events by returning 'nil' (although this may only apply to .mouseMoved events, see below)

In any case, I propose we call this the VenturaSaver2Cpx bug to have a nice search keyword. I don't think it's worth registering a new domain name 😄

There seemed to be no way around this.

Until now.

I belive I have found a workaround for the VenturaSaver2Cpx bug.

The workaround is ugly - basically, you have to trap the mouse cursor, figure out how far it's moving, and if it moves more than 200px, move it back, all the while maintaining a "simulated" cursor position that you forward on to your NSViews.

When you do this, you can have a screensaver which shows an onscreen display (OSD) also called a Heads Up Display (HUD) which allows a user to interact with a running screensaver using mouse or trackpad move / click events.

Would that be of interest to Aerial users?

No file, test, or entry point is named. Start by locating Aerial’s screensaver implementation and determine whether the proposed Ventura mouse-event workaround is wanted; done requires an agreed scope and implementation plan.