eyesee

Reminds me of an app I built ~20 years ago now.

We wanted a cross-platform C++ layer and native Cocoa front end. Objective C++ wasn’t a thing then, and having built a plain C shim previously I didn’t want to repeat the experience.

We built our own bridge by registering our C++ classes with the Obj-C runtime, generating selectors for all the methods so you could send messages to (carefully constructed) C++ objects using Obj-C syntax, or even subclass from C++ to Obj-C.

It was a pretty neat trick, but would’ve been difficult to port to the Obj-C 2 runtime.

MacBooks don’t ship with OLED displays, only micro LED (“XDR”) displays which shouldn’t be susceptible. iPhones however do have OLED displays.

The problem is that you’re always at a sensor deficit because you need so much more resolution to cover a wide field of view. When sensors and chipsets would finally catch up, user expectations would grow to match. Now we’re up against physics: Can’t add more resolution past the diffraction limit, and larger sensors are impractical for super fisheye lenses.

I worked on 360 cameras / software for many years. Looking forward to the day when an article like this comes out for one of the products I worked on.

When you’re in the heart of it it’s so easy to take pride in the technical challenges you’ve overcome, but completely miss the realities of the marketplace.

I mean this is an intriguing rationalization, but I don’t buy it.

Buying votes simply doesn’t cost this much, by orders of magnitude. Burning your empire to ashes as a loyalty test doesn’t hold water either: It’s politicians that partake in loyalty tests, not donors.

More often than not I was opening documents, not apps. But with spatial windows in Finder I used to just arrange my Applications folder the way I wanted (sometimes using Aliases) and have it open on the left of my screen, then have my Documents on the right. I kept a row of Desktop icons visible with an In and Out box.

There wasn’t a default folder structure in the early days. Your hard drive had a “System” folder with merely a few hundred files in it (in a hierarchy) that you can ignore day-to-day. Otherwise the whole drive was your playground.

It’s interesting: my recollection of that period was I rarely stored anything on the desktop. The file system was so much smaller and easier to handle that I stored things in folders and didn’t have trouble finding them again. Not until OS X did I pick up the desktop-as-staging-area habit because navigation was so painful.

Spam was a losing battle. I stopped running a bulletin board around the same time I stopped hosting a mail server.

It was Sony, not IBM. They built the PowerBook 100 based on Apple’s 150 and 170 models.

As it is likely that the number of launch customers for this node is one (continuing the trend), this may be necessary simply to reach agreed upon volumes.

APIs existed for fractional scale and assets in early Mac OS X versions (10.4 I think). I remember building out 1.25, 1.5 and 2x assets for an application at the time. These were never to be shipped to consumers for a few reasons.

There were intractable issues with window spanning across displays with different scale factors. Ultimately this was resolved by not allowing window spanning on the platform anymore.

It’s cheaper to build two at the same time than shutting down production for years and trying to build another one. Tooling doesn’t last forever, and the process and skills required to build one can help you build the second one cheaper. But if you wait, that knowledge is often lost. For example, we have no way to build a Saturn V rocket today even having spent R&D and NRE decades ago.

Surprisingly my rate was not effected (around $1200/yr), though I have been a customer for more than 20 years without a claim.