Not sure if it is worth it for your use case, but I was successful in creating a virtual display - second screen - and putting the window there. That did work. I was trying to get kb input and mouse clicks to work, but then realized that that was even more useless than spinning a window to begin with (lol) so backed out all that effort for this much simpler implementation.
EDIT: private APIs — CGVirtualDisplay / CGVirtualDisplayDescriptor /
│ CGVirtualDisplayMode (the same ones BetterDisplay uses)
Same issue — I never found a way around the clamp. I park the window's top-left at (maxX - 1, maxY - 1) of the union of all displays' CGDisplayBounds, i.e. just inside the bottom-right corner of the whole arrangement. The clamp is much looser going off the bottom/right than up/left — pushing to something like (-30000, -30000) gets snapped back near the top-left and leaves a full-height sliver, whereas bottom-right leaves just the corner pixel (plus its shadow, which I also haven't beaten).
Since the target is derived from the union, a display disconnect or resolution change shrinks the desktop and the parked window pops back into view. I listen for display-config changes and re-apply the position.
SpinWin is an open source menu bar app to visually rotate any individual window. You can rotate / spin as many as you want one by one.
I was scrolling reels when one came on where the content creator suggested "turning the phone upside down" for a portion. I was sitting at my mac, and decided to see if I could find something that did this. To my surprise, nothing exists, so I decided to build it.
Turns out macOS doesn't provide any public API to do anything like this, so I wound up using the Accessibility API to move the target window offscreen, where it keeps rendering. Then we capture it's contents with ScreenCaptureKit, and display that on a transparent, borderless overlay window which has a CALayer to rotate it.
It's written in Swift, open source, MIT license, and signed/notarized.
While I understand your skepticism, there are a few use cases for which I use HA which would be either painful manually, or would require alternate devices such as timers/etc:
1 - outside lights - various lights which light our home's pathway or areas we prefer to have lit at night come on automatically at sundown and turn off at sun-up.
2 - scenes; with HA, we can click one button - a switch with scene control in our case - and have the lights in the room go to a specific set point, receiver come on, select sonos, and tune in to a particular station - an activity which would conventionally require several manual steps with various input devices.
3 - notifications; with HA, I get notifications when the front door or garage doors are opened/closed.
There are several things I plan to implement:
1 - using presence detection and adjusting temps/lights/etc based upon that
2 - fan control; we are heavy users of ceiling fans, and integrating them into home automation would be a significant upgrade. Haven't found a replacement for our Minka controllers which supports zwave (or anything else).
All of this has been possible for years - usually with single vendor solutions which are very costly; HA integrates nearly all automation platforms into a single system allowing each platform's features to work together relatively seamlessly. It's a moving target, but has become very stable/reliable with recent releases.
Very cool; currently the bash script assumes the old "OS X" naming convention of the installation app. To make it work with "macOS" Sierra, some simple changes are required.
EDIT: private APIs — CGVirtualDisplay / CGVirtualDisplayDescriptor / │ CGVirtualDisplayMode (the same ones BetterDisplay uses)