One Byte

That's all you'll need.

Get It Try It

One byte. One byte more. From 12993 to 12994. In Changes.nib, from one copy to another. That's the only difference.

The two files are not otherwise identical, not in the least, it seems at first glance, but this might be down to alignment issues. But in file size they differ by one byte.

Changes.app: Put it in your Dock, fire it up, all is fine, the changes start dropping in. Now go to another app and then click the Changes Dock icon again.

Oops. You've suddenly got yourself another window. Where'd that come from?

Changes.app is a singleton, right? So only one window, right? So no 'New', 'Open', or 'Close' on the File menu, right? Perhaps no File menu at all, right?

Right. That's the 'oops'.

It's not easy making a singleton into multi-doc or vice-versa. The singleton will start with all the objects in a single NIB file, default MainMenu.nib, and the multi-doc will have separate NIBs for the main window and the menu. The default menus will be different as well.

Changes.app started as multi-doc. Back then we didn't know for sure what we wanted. We guessed we'd want multi-doc, but gradually it became apparent that Changes wanted to be a singleton. So we manicured the menu a bit, promised ourselves we'd endure the ordeal of transforming the configuration file one fine day, and then let it rest. Changes.app worked fine - didn't it?

Yes it did. (Cool utility.) Until the other day, that is, with the 'oops'.



What does Changes.app do? Good question. Changes.app is something we built for ourselves. We took a lot of time thinking through things. We concluded we needed something akin to Microsoft's file change notifications for what we were ultimately after.

https://docs.microsoft.com/en-us/windows/win32/fileio/obtaining-directory-change-notifications

Oddly, you may think, the title at the URL refers to directories, but the APIs refer to files. But this is all about directories, no matter the type of change implied. Those critters are synchronisation objects, and Cutler's NT is full of them. File change notifications signal that a change has been made to a directory, not a file. And we wanted to watch directories.

We wanted to be able to see when files were being downloaded. When files do this today on Apple boxes, they're smacked with a bunch of post-its that immediately on arrival, amongst other things, get them sent into quarantine, where they become good citizens of the Land of the Living Dead™.

We wanted to stop that. We wanted to give ourselves and other developers and even ordinary schmoes the ability to get back into their older harassment-free environment.

But Unix doesn't have anything like the MSFT FCNs, and Apple (NeXT) didn't either. Safari emits a 'workspace' notification of its own on downloads (see our Seahaven technology, see the Lightman Notifications tab). But that's for Safari, not for the entire disk or for the entire system.

Apple's FSEvents looked interesting. FSEvents is what Apple created to power Spotlight, a feature we've never used. (OK, one of us, on occasion, but she doesn't broadcast that all over the place. Spotlight's a strange idea with an even stranger implementation and you don't need it anyway when you have the ACP.)

FSEvents compared to Microsoft's file change notifications? FSEvents is 'busy', as many Apple technologies are. (FSEvents is not NeXT - it's Apple.)

But, conversely, it's sophisticated, and offers reams of data you don't get from Microsoft.

What we wanted was to pick up when directories changed. That's why we created Changes.app, so we could see how FSEvents worked.

So this 'oops' thing again. The first thing to troubleshoot was the squigglies at the top of the config file (pbxproj). Perhaps there's something there? Sometimes they're different. The one file has 42, the other 50, for 'objectVersion'. Could it be that simple? Let's try. And lo and behold, it works!

So let's just move the new binary into the collection and we're done, right?

No, wait. Let's compare the binaries first with Rixcomp, the current one and the new one. Both are a tidy 18752 bytes. What does Rixcomp say?

'Items are identical.'

Oh?

OK, so maybe it's some secret sauce in Info.plist? Check them both. Nope, nothing there.

OK, dammit, so what's different between the two bundles? Time to drag out Apple's (NeXT's) FileMerge.



Only one file differs, says FileMerge. Changes.nib. They differ by one byte in file size. It makes no sense. Time and again we test them, both versions in the Dock, time and again the old version pops up the 'oops' window and the new version does not.

But NIBs in production are PLISTs, right? So we can try saving them as text and then comparing them as text, right?

So we download the latest ACP release, pluck out Changes.nib, open it with PlistEdit, copy the text in the PlistEdit window to Rixedit and save that to disk, then do the same for the new Changes.nib, and then compare both of the text files with FileMerge.

FileMerge - a utility based on Doug McIlroy's brilliant diff - finds one diff. The older 'oops' version uses NSPanel for the main window, the new version uses NSWindow. NSPanel versus NSWindow: that's it.

It's not understood what the 42/50 discrepancy in the project files had to do with anything. Evidently NSPanel and NSWindow behave differently when it comes to clicks on Dock icons.

Why was Changes.nib changed in the first place? It's time to ask along Memory Lane.

NSPanel refuses to go into Kiosk Mode. And we hate Kiosk Mode as a replacement for maximise (zoom). That's for window lickers. You can evade Kiosk Mode by pressing option when clicking the green button of course - but that's extra work to keep things as they were to opt out of a new feature. That's 'Apple'. Reverse the two however, and make Kiosk Mode an option by pressing option, that would have been OK. Opt-ins are generally better until you find that people actually prefer them and would prefer them as default.

Someone here wanted Changes to default to the old default and evidently changed the class of the Changes window from NSWindow to NSPanel.

So yes of course it's all Apple's fault again. So there.

PS. See the brilliant paper by Doug McIlroy, linked above.

PPS. Remember The Plague by Albert Camus? Enjoy the meaningless moments.

PPPS. Editing Changes.nib directly with PlistEdit and changing 'NSPanel' to 'NSWindow' reduces the file size to 12862 bytes, reasons unknown, but it seems to work fine.