3 ms·
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 ha
by nxobject 3y ago
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.
[1] https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbon-and-building-Classic-Mac-OS-apps-in-OS-X https://www.highcaffeinecontent.com/blog/20150124-MPW,-Carbo...
- Someone 3y ago> 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)