Hacker News Reader

Comment by RodgerTheGreat | Hacker News Reader

An impressive proof-of-concept.

The UI elements look rather odd. What's the rationale for using a custom immediate-mode UI library instead of using the Mac's native forms and toolbox routines for them?

View on HN

Sure, I felt like having a simple immediate mode library would make UI programming on old Macs a lot easier. I still think that’s true after getting the UI library working and having used it for a project. I wrote a blog post explaining my reasoning here as well: https://henlin.net/2021/12/21/Introducing-Nuklear-for-Macint...

It makes a lot of sense and toolbox programming is a pain - it was quite low-level in its day too. The downside is the you end up with an app that runs on classic MacOS but doesn't look anything like a classic MacOS app. I think that's a problem somewhat inherent in the platform - the system-provided GUI programming model was primitive but users cared about the look/feel of the UI just as much if not more than now.

I'm not sure I'd agree that the Mac toolbox is primitive. Reflowing forms to reflect a resizable window wasn't a common technique at the time; Macs had a predictable screen size and DPI. Abstracting the layout of a form from code via a resource was a very forward-thinking approach for the day. Among other advantages, fiddling with ResEdit was very empowering for users who might not even have access to the source code of an application!

It's not really primitive by intent but it's quite primitive in reality because of the drastic constraints on the original target platform. So yes, things like resources are a place where intent and implementation are relatively close but much of the rest of it isn't. Consider that System 6/7 are of the same vintage as Nextstep and the Nextstep model is still in very wide practical use today.

Probably familiarity and ease of development.

Reply on news.ycombinator.com