I think the tradeoff with the Toolbox is that positioning controls with relative coordinates, and updating views when scrolling etc, is a huge PITA since you have to do it in application code – for example, I'm not aware of many classic Toolbox applications that had bottom window status bars before that required relative positioning. A few early applications just assumed 512x342 fullscreen (i.e. MacPaint.)
On the point of GrafPort still existing – Carbon was insanely backwards source compatible until QuickDraw was deprecated in the transition to 64-bit! [1] Conservatively-written 80s Toolbox code would work with some switching around of headers, and shimming getting/setting members of structs with functions.
> for example, I'm not aware of many classic Toolbox applications that had bottom window status bar
I think that’s more either because they yet had to be invented or because giving up 16 or so pixels on a screen (the menu bar was 20 pixels high, IIRC) that’s only 342 pixels high wasn’t desirable.
> A few early applications just assumed 512x342 fullscreen (i.e. MacPaint.)
I think MacPaint can be forgiven for that. It was a miracle that it ran on a Mac with 128kB RAM.
An application on that machine had about 28kB free for a program. MacPaint allowed you to edit a 50kB bitmap, double-buffering the screen to avoid flicker, with full undo.
(And yes, paging to floppy disk isn’t fast. It did work, though)
On the point of GrafPort still existing – Carbon was insanely backwards source compatible until QuickDraw was deprecated in the transition to 64-bit! [1] Conservatively-written 80s Toolbox code would work with some switching around of headers, and shimming getting/setting members of structs with functions.
[1] https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbo...