How to start with UI on the Mac? #255
Replies: 4 comments 12 replies
-
|
You will want to browse old documentation about the "Window Manager", "Menu Manager", "Dialog Manager" and "Control Manager", and maybe about the "TextEdit package". For Retro68-specific sample code, look at Samples/Dialog, Samples/WDEF (ignoring the stuff that is actually about WDEFs) and maybe LaunchAPPL/Server; and, especially if you're using Nix, at the https://github.com/autc04/Retro68NixSample repository. By modern standards, Apple's old UI libraries are very basic and low-level. |
Beta Was this translation helpful? Give feedback.
-
|
What would it take to get PowerPlant working? From my limited understanding it is built on top of the Universal Libraries and Interfaces, so assuming you had access to that and the PowerPlant sources, could it compile? |
Beta Was this translation helpful? Give feedback.
-
|
I see PowerPlant has been open-sourced at the end of its life - https://github.com/chrisballinger/powerplant, so that would be a good starting point. You'd need to spend a bit of time on build system setup, getting the include paths right (basically, throw everything in there, classic mac software didn't use relative paths in #include statements). There might be some differences between an early c++98 implementation by Metrowerks and a recent GCC. Expect some compiler errors where you will wonder "why did it accept that code?". There's also bound to be some problems with some central defines (PP_Macros.h) that might make wrong assumptions about what features GCC supports. And another small detail I'd be worried about is how modern tooling deals with PowerPlant's use of But on the whole, it should be quite doable. |
Beta Was this translation helpful? Give feedback.
-
|
Hey just seeing this and thanks for replying! I got pretty far with it one evening. I was able to get a whole bunch compiling without errors, and the errors I came across were mostly easy to fix. I manually changed the cp files to cc to avoid that issue. One error that I ignored just to carry on was with |
Beta Was this translation helpful? Give feedback.
-
|
@autc04 I am close (I think!) but am getting some linker errors for functions defined in |
Beta Was this translation helpful? Give feedback.
-
|
num2dec was something Apple-specific. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a a bit of a noob when it comes to CMakeLists, how do I specify it? My usual helper (AI) isn't giving me much here. I think it needs to link to the file |
Beta Was this translation helpful? Give feedback.
-
|
Looks like the following works and for reference
|
Beta Was this translation helpful? Give feedback.
-
|
@autc04 Having another crack at linking this together. I've gathered that But then I still get duplicate definition errors when compiling. I had gotten the whole lot to compile by setting Which is pretty clear. Do I need to omit MacWindows.h somehow? I'll post my CMakeList.txt in case you have any insights. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed response @autc04, I'm learning a lot as I go with cmake etc. While I have you... Incidentally while I was waiting for a response I got https://github.com/facebook/yoga to compile without errors which could be kind of interesting to see if I can build UI with it. I did see a comment in the shared library sample though Does this mean that instead of defining the library and using it, I'd just have to lump all the source files inside my application (like I am with PowerPlant)? I am primarily a UI engineer so am having some crazy ideas of making some kind of ComponentKit like declarative library for classic Macs, although I'm sure it would probably take about 100 years to resize a window ;-) |
Beta Was this translation helpful? Give feedback.
-
|
No shared libraries on 68K, but one could of course create and use a static library using standard CMake functionality. See Mac OS 8 and 9 had a 68K port of the Code Fragment Manager to handle shared libraries, but that never caught on much because 68K was already on its way out, and anyway it'd be a big project to support in Retro68. And before that, there was the "Apple Shared Library Manager", which was strange by modern standards and which I've never seen in actual use at all. Hmmm, yes it would be interesting to see how far it can be taken. Well, the original NeXTstep ran on 68K, and it was already more advanced than all Apple ever did before Mac OS X... I know that some of the old hardware was physically incapable of shuffling all the pixels of a window around quickly enough to allow for really smooth dragging of a window. But it was close, scrolling a few pixels at a time worked. And of course, the Old Ones refrained from double-buffering because they wanted to use their RAM for other things besides the UI itself, and they were apparently scared of asynchronous stuff... |
Beta Was this translation helpful? Give feedback.
-
|
Great information thanks - and of course |
Beta Was this translation helpful? Give feedback.
-
|
@autc04 - me again... I'm stuck with these linker errors. The problem is clear, AEObjectSupportLib and Interface won't link because of the symbols are more than 32kb away (16-bit relative calls). I've tried breaking my source code up into smaller static libraries and reordering, tried recompiling the toolchain with -mlong-calls but it doesn't work because the 16 bit limit is baked into the object files. I am not really sure if I have any other options at this point. |
Beta Was this translation helpful? Give feedback.
-
|
Ok little update - I worked out that PP only needs My next step is to get some resources on screen. I have a menu bar appear, and I was able to affect the Quit item by just plonking Back in March I was able to convert a .rsrc file to .r using some tool on modern macOS but I forget which, care to remind me? PP also uses some ppob resource files which I think are proprietary project files for their constructor app, but I think it ends up converting them to plain .r files, so might be nice to figure out how to do that as well. |
Beta Was this translation helpful? Give feedback.
-
|
On Apr 14, 2025, at 2:45 PM, Wolfgang Thaller ***@***.***> wrote:
No shared libraries on 68K, but one could of course create and use a static library using standard CMake functionality. See add_library in make docs.
Mac OS 8 and 9 had a 68K port of the Code Fragment Manager to handle shared libraries, but that never caught on much because 68K was already on its way out, and anyway it'd be a big project to support in Retro68. And before that, there was the "Apple Shared Library Manager", which was strange by modern standards and which I've never seen in actual use at all.
ISTR some versions of MS Office used it?
Hmmm, yes it would be interesting to see how far it can be taken. Well, the original NeXTstep ran on 68K, and it was already more advanced than all Apple ever did before Mac OS X...
Sure, but NeXTstep also took proper advantage of the virtual memory capabilities of the 68K, which MacOS never did (it would have broken too much about how applications expected to work by the time it was feasible hardware-wise), and it's difficult to do shared libraries efficiently if you can't just map them in like Unix and Windows do.
I know that some of the old hardware was physically incapable of shuffling all the pixels of a window around quickly enough to allow for really smooth dragging of a window. But it was close, scrolling a few pixels at a time worked. And of course, the Old Ones refrained from double-buffering because they wanted to use their RAM for other things besides the UI itself, and they were apparently scared of asynchronous stuff...
I mean, yeah, but also double-buffering takes up enormous CPU resources when you don't have hardware page-flipping (which isn't practical for windowed double-buffering anyway). There is, however, plenty of asynchronous stuff in the old Toolbox, it's just done via callbacks. Drawing procedures for windows and controls and filter procedures are really great examples.
Event handling was primarily done as a loop because honestly that's how it's done a lot of places; you can always abstract that to be asynchronous via your own callbacks if you want, but handling it as a queue consumer is actually a lot more efficient from an overhead standpoint.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Like are there any libraries/headers for working with UI?
Beta Was this translation helpful? Give feedback.
All reactions