- New hacks, Gibson, EtruscanVenus and Scooter.
- BSOD supports Tivo and Nintendo.
- New color options in RomanBoy, ProjectivePlane, Hypertorus and Klein.
- "Use random screen saver" works again on macOS 10.15.
- iOS supports dark mode.
- Image loading works again on iOS 13.
- Fixed rotation on iOS 13 (Apple incompatibly breaks rotation every two years as a matter of policy).
- Performance tweaks for Eruption, Fireworkx, Halftone, Halo, Moire2 and RD-Bomb.
- Various bug fixes.
It was recently the 25th anniversary of Hackers, you know.
Sadly, if you install the DMG on macOS, it no longer includes WebCollage or the stand-alone terminal-program versions of Apple2 or Phosphor. This is because I couldn't figure out how to sign them in a way that would allow "stapler" to function (it's losing its damned mind because an .app bundle has an executable command-line helper program inside it), so, fuck it, I guess they're gone.
Apple and code signing: every day, worse in every way.
Update: I think I figured out the latest pointless codesign firedrill. I pushed out a DMG (only) of 5.44.1. Let me know if it works.
I'd like to help with stapler (co-worker wrote it). Can you email me the notary request UUID of your upload and the error you get from stapler?
Taking a random guess, it sounds like you may have dropped the CLI tool into the bundle after codesign or modified it. This invalidates the bundle signature. Stapler uses the signature hash to look up a ticket so if you're getting a "ticket not found error", that could be the cause.
The solution is to put the CLI tool into the bundle, codesign the bundle (which will cover the CLI tool), then zip up and notarize the whole thing. Tickets are hierarchical so a ticket for your top-level installer (dmg, pkg, or zip of an app bundle) includes hashes for everything within it.
It could also be that the CLI helper is in ./Contents/Resources, which is not a regular code execution subdirectory. This means that if you code-sign the bundle in one swoop, the helpers will not be **signed as code**, as they would e.g. in ./Contents/Library or ./Contents/Frameworks etc. Instead they will only be registered in the bundle's code resources, and that might cause problems down the road. So solutions could be to sign (and notarize?) the helpers first, while leaving them where they are, and then do the main bundle itself… or (better) just find a proper macOS-approved code location for them in the bundle.
Phosphor.app contains Phosphor.saver inside Resources, and that didn't work no matter how I signed or didn't sign the internal thing.. In the last release, it worked to sign the .saver first then sign the .app again. This release, none of the obvious permutations worked. Webcollage is different: it contains a non-bundle stand-alone executable "webcollage-helper", which you cannot sign.
So, yeah, "Maybe you should figure out where Apple wants you to put shit and how they want you to sign it" is super helpful advice that I did not think of.
Wow, you're an ugly person. Took me literally 1 web search, and the top result already has everything you need:
https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG201
Contents/MacOS – Helper apps and tools
Contents/Frameworks – Frameworks, dylibs
Contents/PlugIns – Plug-ins, both loadable and Extensions
Contents/XPCServices – XPC services
Contents/Helpers – Helper apps and tools
Contents/Library/Automator – Automator actions
Contents/Library/Spotlight – Spotlight importers
Contents/Library/LoginItems – Installable login items
Contents/Library/LaunchService – Privileged helper tools installed by the ServiceManagement framework
Hey guess what, this is not my first rodeo and IT'S NOT THAT SIMPLE. Fuck off.
In High Sierra, 5.44 crashes System Preferences the first time any saver is manually chosen. Reverting to 5.43 it works fine.
Well, it worked for me on my test machine...
I was not foolish enough to install 10.15 on a computer I actually care about.
I haven't installed 10.15 either. The crashes are happening in 10.13.
You had me at '"Use random screen saver" works again on macOS 10.15.'
I'd swear I remember, years ago, you (jwz) posted something about running the hacks in a window. I can't find it now, though, and the Interwebs aren't being at all helpful. I'm wondering if that was from the dark days when I ran Linux as my desktop OS ("THIS will be the year of Linux on the desktop for sure!").
Am I misremembering? Or is there a way to run the hacks in a windowed mode?
Thanks!
Under X11 if you run them directly with no arguments they open in a window. (That works on Mac X11 as well). On "real" macOS, if you build from Xcode there's a "SaverTester" app, but I don't ship that in the DMG. I think there are some 3rd party apps out there (or used to be) that let you run savers in a window, which is basically all that SaverTester does.
Good to know I'm not misremembering then. Maybe doing a build from XCode will be tonight's side project.
Or maybe installing Linux in a VirtualBox or something.
You (and the guy that delivers booze to my door) are doing god's work. Thank you.
Today I am the Venn diagram between screen savers and alcohol delivery.
"Phantom Freak"? That would have been Phreak on any BBS I remember.
Fucking Autocorrupt.
I believe there is a bug in XScreenSaver (this version included). I set it to blank screen instantly (yeah, I'm a killjoy just like this):
And this works just fine, turning the screen off as soon as it kicks in. The problem is, however, that when I invoke the unlock dialog and dismiss it, the screen won't turn off again. My laptop once spent half of the night showing blackness with full backlight.
Just writing this here because I don't know where else to write it.
As you probably already know, as I'm sure you get a fair amount of mail about, xscreensaver fails^H^H^H^H^H chooses not to inhibit itself when many sorts of videos or games are playing since those apps utilize "modern" ways of inhibiting screensavers on Linux desktops, rather than using xscreensaver's interface (xscreensaver-command -deactivate or what have you) to do so.
I wanted to see if I could hack xscreensaver to get it to inhibit itself the "modern" way.
This "modern" way typically means two things are done to cover both bases:
1) The XScreenSaverSuspend function is called - this is a new addition by Xorg to X11R7, introduced about 10 years ago now. I'll come back to this...
2) Send a dbus method of "inhibit" to org.freedesktop.ScreenSaver.
#2 sounded a lot cleaner and more modern, so I looked into it, but being new to C in general, trying to wrap my head around the glib "GDBus" API was simply not a rabbit hole I wanted to go down.
So I looked into #1 and it turns out that this "new" X11R7 function was basically added the Xorg folks extending and reworking the old "MIT-SCREEN-SAVER" API.
So I basically brute-force un-#if-0'd all of your code that is still there to handle MIT-SCREEN-SAVER, and as a side effect "modern" screensaver inhibiting works perfectly. Yes, I get that slight flicker but I can live with it.
So the moral of the story is, sometimes if you write code in 1992 that becomes obsolete, it can be resurrected nearly 30 years later and it will become modern again...
"E-mail" is an invention you should investigate.
But the only sane way to do what you want is for video playing apps to do the xscreensaver-command heartbeat. Everything else you are trying is a bottomless hole of grief.