Jump to content

Classic Macintosh GUI programming thoughts


Recommended Posts

I was curious what people's opinions were on the state of GUI programming on old Macs. Here goes my rambling post on the subject, hopefully this is enough to get a discussion going. :D

 

For some background, I am new to Mac programming but experienced with programming in general. I have been doing a fair amount of programming using the Retro68 console recently, but now I'm looking to create some more GUI-based applications, so they can feel more "Mac-like".

 

I've been pouring through the books "Inside Macintosh: Macintosh Toolbox Essentials" and "Inside Macintosh: More Macintosh Toolbox" along with some other resources online, and have been playing around a bit manipulating the "MenuSample" test app from this blog post: http://www.toughdev.com/content/2018/12/developing-68k-mac-apps-with-codelite-ide-retro68-and-pce-macplus-emulator/.

 

I'm forming some opinions that I'm wondering if I should be swayed on: 

  • programming against the Macintosh Toolbox is cumbersome, difficult to use
  • for example, even creating a textbox to handle input on the screen requires multiple steps across multiple files (res file definition + handling in code and the code is non-trivial compared to how one might do it today)
  • it is difficult to define layouts and respond to size changes. adding lots of elements to a window and dealing with them is pretty hard
  • this is probably hindering the creation of at least a subset of new Mac apps that could be getting developed... Personally I think there is a lot of interest but the barrier to entry is high
  • GUI programming has advanced a lot in the last 30 years and even basic GUI libraries do a lot more for the programmer these days
  • Programmers writing software for Macs in the 80s and 90s were heroes. It's amazing what they accomplished with the tooling and resources that they had


Am I wrong about any of that? What do you think?

 

So, I'm wondering: back in the day, were there libraries or other resources used to aide the creation of complicated Mac GUIs? Obviously you could slap together whatever you want in HyperCard or something, but I mean libraries that would have been used with MPW, THINK C, etc

 

Additionally, along those lines, but more modern: Has anyone considered writing a QuickDraw implementation for https://github.com/Immediate-Mode-UI/Nuklear or https://github.com/ocornut/imgui? I think that either would be relatively straightforward. For example the Allegro5 and SDL2 back ends for both libraries have a lot of the same functionality that QuickDraw exposes and these libraries both support the creation of some pretty complicated apps without a lot of the difficult code involved. As an aside, I think there used to be an old SDL1 version that supported PPC Classic MacOS that could likely be backported further as well (see: https://nondisplayable.ca/2017/12/20/sdl-on-classic-mac.html), but I think that just rolling with QuickDraw here would be the way to go and likely more performant.

 

I'm interested in hearing your thoughts on GUI programming for old Macs, things that you've dealt with in your own code, your opinion on why I am wrong about Macintosh Toolbox, opinions on single file C libraries, etc

Edited by camh
Link to post
Share on other sites
Posted (edited)
19 hours ago, uyjulian said:

If you are looking for something more lightweight but still maintained, I would check out lvgl: https://lvgl.io/

 

It can run on low-powered microcontrollers, so I suspect it can also apply for old Macs.

 

Nice, hadn't seen that before. I also found its github page at: https://github.com/lvgl/lvgl looks similar to nuklear and imgui, should definitely be in the consideration. edit, although porting looks a lot more intense, see this linux framebuffer example: https://github.com/lvgl/lv_port_linux_frame_buffer

Edited by camh
Link to post
Share on other sites
  • 68kMLA Supporter

I have to say I have come to the same conclusion as you on a few occasions: Mac programming just doesn't look very fun. At least not in the instant gratification sense.

 

My brief encounters with Macintosh Common Lisp were extremely positive, though, but then I was already interested in Lisp. But it definitely looks more responsive/immediate.

Link to post
Share on other sites

I'm still interested in others' input, but I think I am pretty set on trying to create a QuickDraw back end for nuklear using the allegro5 back end as a guide. I am going to start looking at this tonight or tomorrow evening. I have some older experience with Alllegro so this seems like a good fit for me. 

 

My intents up front will be:

- Get a POC working as quickly as possible to prove the idea is solid, get the source code online for others to look at.

- only support 1 font up front - loading in other fonts from nuklear would require more complex image rendering that QuickDraw can't provide

- no image support of any kind - again, QuickDraw has limited facilities for handling images, I think PICTv1 only. this could happen in the future maybe, but someone would need to create a function to render at least BMPs using quickdraw (probably pretty easy tbh)

- b&w support only - again, might be easy to use color QuickDraw here, but I am personally more interested in coding for b&w Macs

 

 

Link to post
Share on other sites
  • 68kMLA Supporter

You're beginning to get to the point here why I'm wondering why you're using the Mac at all.  What you are going to get from the above will not act like a Mac application, and it seems an awful lot of work to do badly what you could do easily with better results.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

Honestly, why the hell not. I think I'd learn a lot from this project about how the Toolkit works.

Macintosh Common Lisp is fantastic – it's a good way quickly working and prototyping with the Toolbox. Here's an article from MacTech. However, anyone you create on it probably won't run on a Mac with less than multiple MBs of RAM.

 

Also, as a fun aside: as a joke, I tried to do a similar IMGUI prototyping environment, but with JavaScript (I used Duktape for a modern JavaScript environment.) It took 45 seconds to initialize the VM on System 7 on a Macintosh Classic.

Edited by rplacd
Link to post
Share on other sites

I haven't done Mac Toolbox programming, but it doesn't appear much different from typical procedural GUI API programming like Windows. Object oriented wrappers for the Mac Toolbox existed with Apple's MacApp and later MetroWerks PowerPlant to make things easier. The tradeoff was the added bulk of the libraries bloating your applications.

 

Another concern has to deal with the clunkyness of MPW. 30+ year old developer tools were ugly and cumbersome to deal with. A modern IDE goes a long way to making programming for vintage machines pleasant. When I was doing some Apple IIgs Toolbox development, I can say most of the struggle was dealing with getting the dev. environment working and dealing with its limitations.

Link to post
Share on other sites

Is the toolbox clunky and tedious to work with? Yes, definitely. However, I think anyone still interested in classic macs at this point wants the native look and feel.  Also I suspect it may be difficult to get good performance implementing everything yourself.  Maybe a carefully considered lightweight wrapper library for common UI patterns would be nice.  I don't want to discourage you, though, I'm quite curious to see how your work with this goes.

Link to post
Share on other sites
On 3/22/2021 at 9:32 PM, rplacd said:

Honestly, why the hell not. I think I'd learn a lot from this project about how the Toolkit works.

Macintosh Common Lisp is fantastic – it's a good way quickly working and prototyping with the Toolbox. Here's an article from MacTech. However, anyone you create on it probably won't run on a Mac with less than multiple MBs of RAM.

 

Also, as a fun aside: as a joke, I tried to do a similar IMGUI prototyping environment, but with JavaScript (I used Duktape for a modern JavaScript environment.) It took 45 seconds to initialize the VM on System 7 on a Macintosh Classic.

 

Thanks for posting that MacTech article, I hadn't seen that in the past. I think that using LISP there makes sense from the perspective of testing out the toolbox, as the article mentions, but I find it unpalatable to consider writing a full program in it :D 

 

Is this the duktape project that you mentioned? https://github.com/kentaromiura/NativeReactLikeInMacintosh Regardless, I know you mentioned it was as a joke, but I think it's an interesting idea to bring a JS-based rendering engine to older Macs. I wonder if an even smaller JS engine like quickjs or jerryscript may be a better fit. Maybe worth exploring more? I'm sure the startup time could be much improved.

 

 

22 hours ago, NJRoadfan said:

I haven't done Mac Toolbox programming, but it doesn't appear much different from typical procedural GUI API programming like Windows. Object oriented wrappers for the Mac Toolbox existed with Apple's MacApp and later MetroWerks PowerPlant to make things easier. The tradeoff was the added bulk of the libraries bloating your applications.

 

Another concern has to deal with the clunkyness of MPW. 30+ year old developer tools were ugly and cumbersome to deal with. A modern IDE goes a long way to making programming for vintage machines pleasant. When I was doing some Apple IIgs Toolbox development, I can say most of the struggle was dealing with getting the dev. environment working and dealing with its limitations.

 

I think PowerPlant is a bit new and requires PPC from what I can tell but MacApp is definitely worth looking into a bit more I think, and something I wasn't aware of previously. I agree that a modern IDE plus emulator arrangement goes a long way here and I spent quite a bit of time figuring that out. I couldn't imagine doing complex dev work on an old Macintosh itself. 

Link to post
Share on other sites
  • 68kMLA Supporter
On 3/23/2021 at 1:55 AM, camh said:

So, I'm wondering: back in the day, were there libraries or other resources used to aide the creation of complicated Mac GUIs? Obviously you could slap together whatever you want in HyperCard or something, but I mean libraries that would have been used with MPW, THINK C, etc


Just another angle/twist to this...

 

I feel dirty recommending it, but a little later on in the classic Mac OS era (I think it first surfaced in 1997 or so) there was a solution called REALBasic which offered a friendly drag & drop GUI to create a somewhat native Mac application (I say 'somewhat native' because REALBasic had a very strange way of interpreting the Macintosh Toolbox, and things only got worse, a lot worse, when Carbon and then Cocoa came along). Later on it facilitated building your app for Windows and Linux too, without a rewrite required.

 

REALBasic was my first introduction to programming. My school wouldn't teach me, so I got this instead. I actually remember paying a decent chunk of money for the physical copy of version 3 at the time. I made a few apps with it, and it was fun. It's no replacement for writing in C, and there are many many things about REALBasic which are just terrible, but I think it does give you what you're asking for, with the caveat that you have to ignore all the shortcomings of REALBasic...

 

There aren't many screenshots of earlier versions of REALBasic, so here's what version 2 looks like under System 7. Adding the text field to that window took no effort as its just drag and drop, and I could build that as a standalone app straight away if I wanted.

352431871_Screenshot2021-03-24at05_02_18.thumb.png.31d11d25760d21489d4411643f9f531c.png

 

 

Link to post
Share on other sites
20 hours ago, joshc said:


Just another angle/twist to this...

 

I feel dirty recommending it, but a little later on in the classic Mac OS era (I think it first surfaced in 1997 or so) there was a solution called REALBasic which offered a friendly drag & drop GUI to create a somewhat native Mac application (I say 'somewhat native' because REALBasic had a very strange way of interpreting the Macintosh Toolbox, and things only got worse, a lot worse, when Carbon and then Cocoa came along). Later on it facilitated building your app for Windows and Linux too, without a rewrite required.

 

REALBasic was my first introduction to programming. My school wouldn't teach me, so I got this instead. I actually remember paying a decent chunk of money for the physical copy of version 3 at the time. I made a few apps with it, and it was fun. It's no replacement for writing in C, and there are many many things about REALBasic which are just terrible, but I think it does give you what you're asking for, with the caveat that you have to ignore all the shortcomings of REALBasic...

 

There aren't many screenshots of earlier versions of REALBasic, so here's what version 2 looks like under System 7. Adding the text field to that window took no effort as its just drag and drop, and I could build that as a standalone app straight away if I wanted.

 

Beautiful! My first job was writing VBA applications against Office 97 so I definitely have a soft spot for these kinds of tools

Link to post
Share on other sites
  • 68kMLA Supporter

I agree that the toolbox is cumbersome. I don't think bypassing it is the answer. Personally, I would not be interested in using a UI library that didn't create native widgets. I wouldn't even be interested in using software written with such a library. (Maybe with the exception of games which sometimes make sense to do something completely different.) I just don't see any point to making software that ignores the platform UI on a platform that is defined by its UX.

 

But you do whatever you like to do.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

After using the toolbox for a little while, all you need is to create some wrapper functions to handle the nitty gritty. At this point, creating controls for me is as easy as doing:

 


ControlHandle _myButton = CreateGuiButton("Text", posX, posY, width, height);

.......

void HandleButtons(void)

{

      if(control == _myButton)

      {

            DoStuff( );

      }

}

 

The same for a lot of the other controls in the UI Library. At this point, I'm not even using ResEdit to do any of my gui design, writing it in code is super fast. At worst, a gui editor can be easily made for something like this. 

 

Edit: Layout and size changes are easy if you organise your code into areas and have a reference to the x/y positions of the layout and it's width height. Setup some custom rules about spacing and a multiplier for the width/height based on the screen size and window aspect ratio and your covered in a lot of cases. If I have time this weekend, I can probably cleanup my UI header files that I use for my game and make them public.

It's not "as easy" as modern ui development but then again, I find modern ui development to be too much form over function so I could be biased.

Edited by BacioiuC
Link to post
Share on other sites
  • 68kMLA Supporter

(tl;dr: yeah, use RealBASIC or something like @BacioiuC's wrappers)

 

Yeah, now that I've slept, I think the point I was trying to make above has been made better by others, but to summarise in perhaps a clearer way that makes me sound less grumpy:

 

Really, the main thing the classic MacOS has going for it is its GUI and its graphics systems.  There are a number of other good ideas in it, but on the whole it's not a great OS.  If you're just using it as, like, a mediocre block terminal or rendering surface for JavaScript, you are not going to produce an idiomatic application, and Mac users in general have a high tendency to interpret UI idiomaticity as quality, and its absence as absence of quality.  And it's going to be a frustrating experience, because writing for classic MacOS isn't particularly nice.

 

Perhaps the most infamous example of this in Mac terms was when Microsoft decided to use the same GUI code for Word 6 for Mac (IIRC).  They had a set of shims that allowed you to cross-compile Win32 GUI code and have it run on a Mac, reskinning things as necessary.  This was a remarkable technical achievement but a complete bloody waste of everyone's time, as it turned out, because people perceived the resulting application as low-quality, and stayed with the previous version, which had had a more idiomatic Mac UI (and was noticeably faster).

 

Adaptation on either the canvas level or the lexical level (reskinning, etc) will not, and in the general case cannot, produce reliably idiomatic UIs.  This was actually my research area back when I was pretending to be an academic for a little while :-).  (I wasn't good at it).  The academic research in the area isn't great (including mine), but has quite convincingly pinned down the problem space, even if good solutions in the general case are rather lacking both from industry and from academia.

 

In this case, if you want to write apps that feel like Mac apps, the right approach is probably to use something where someone else has done the drudge work for you.  There's a lot of snobbery around things like RealBASIC, but they exist for a reason, and RealBASIC itself does what it sets out to do rather well, it enables basic application development without much overhead.  As a wildcard I might also throw in HyperCard here, if you want the retro look :-).

 

Something like that will give you a much better perceived-quality end result for much less effort, and will probably run a lot better, too.

 

20 hours ago, BacioiuC said:

If I have time this weekend, I can probably cleanup my UI header files that I use for my game and make them public.

 

I'd really like this.  I am very bad at toolbox development and would appreciate anything that makes it more bearable (still, at least it isn't GEM...)

Link to post
Share on other sites
  • 68kMLA Supporter

Wow, interesting thread.

 

A couple people mentioned PowerPlant and MacApp.  Another useful vintage framework was the THINK Class Library (“TCL”).  Less feature-packed perhaps, but probably easier to use than MacApp for most people and very well documented, and fully 68k.

 

A couple people mentioned the lack of a modern IDE in the 68k era and frustration with MPW ... my absolute no-exceptions advice is, don’t use MPW!  For straight 68k development, use Symantec C++.  Aside from the need to switch over to ResEdit for GUI design, the Symantec IDEs were pretty excellent with a nice integrated developer (sadly the C debuggers were never as nice as THINK Pascal’s, but c’est la vie).

 

Regarding not being able to easier auto-generate code for UI widgets ...  TCL would help with that.  You could also definitely roll your own mini frameworks like BacioiuC did and I’ve done a little of that too.  But really, “write it once and copy/paste the relevant bits of your code into a new project” always worked pretty well for me, and the actual dialog box handling stuff is pretty easy if a bit tedious; you just end up calling GetDItem and SetCtlValue and GetIText a lot but who cares.  I actually think a huge part of the pleasure of Mac programming is assembling beautiful working things from tiny little granular atomic components:  individual trap calls to the Toolbox.  But that’s just me, I’m old and old school.  :) 

Link to post
Share on other sites

Seems like RealBasic would still be super useful for visualizing how you might want a GUI to look before jumping into ResEdit.  Come to think of it, is there a reason you couldn't compile the RealBasic dummy app just for the GUI layout, then copy/paste the relevant resources?  Could save you some time as opposed to trial and error trying to get the x,y positions right on everything.

Link to post
Share on other sites
On 3/23/2021 at 5:45 AM, BacioiuC said:

If I have time this weekend, I can probably cleanup my UI header files that I use for my game and make them public.

 

Super interested in your headers if you have the opportunity to do that - sounds like you have a really solid approach figured out. If you put them up in a public github or gitlab repo I may be willing to use and contribute as well - very interesting!

 

On 3/23/2021 at 8:55 AM, Crutch said:

 Another useful vintage framework was the THINK Class Library (“TCL”).  Less feature-packed perhaps, but probably easier to use than MacApp for most people and very well documented, and fully 68k.

 

Thanks for posting about TCL - I just started looking at this one and it actually looks somewhat nice to use as well. One of the things that immediately strikes me about TCL is that it is all relatively simple standard .c and .h files that could be (I think, obviously haven't tried yet) fed into a modern Retro68 project without a ton of effort, whereas MacApp 2 is huge and versions capable of targeting 68k are Pascal and somewhat difficult (again, I think) in modern code.

Link to post
Share on other sites
  • 68kMLA Supporter

Great topic. 

 

My POV:

  • Toolbox is a bit of a pain to learn, but it's just another framework you have to get familiar with. 
  • My top recommendation for a Mac starter book: Mac Programming By Example. I wish I had come across this a few years ago. Get it here with the other Mac programming books (can also get this from AbeBooks, etc.). https://vintageapple.org/macprogramming/
  • REALBasic is probably the one GUI builder available, but it doesn't build much that would be useful to you in a C app. OTOH, you could consider it for a rapid development / prototyping tool (or just do it in REALBasic, but then you have to learn its conventions, and you are stuck in it, with its limitations). REALBasic (current incarnation: XOJO) is actually pretty good as a prototyping tool. 
  • There's some programmer folklore I saw once to the effect that every programmer really just writes one program, over and over again. On 68k Mac, if you set up an app framework for yourself, you will be able to re-use it for A LOT of different apps in the future. 
  • I definitely like the recommendation above to set up something for yourself to automatically create and position controls. Consider including that in your app framework. 
  • Can't wait to see more from your JS co processor!
Link to post
Share on other sites
  • 68kMLA Supporter

There were actually some apparently-decent GUI building tools back in the 68K era.  Based on my extensive perusal of old MacTutors, the most well known were Prototyper, AppMaker, and FaceIt.  I keep meaning to try these but haven’t yet.  Prototyper may have been the most general-purpose of the three and is available here and can allegedly generate C code as well as Pascal:

 

https://macintoshgarden.org/apps/prototyper

 

Here’s some info on it in an old MacTutor:  http://preserve.mactech.com/articles/mactech/Vol.05/05.05/Userlog,tools/index.html

Link to post
Share on other sites
  • 68kMLA Supporter

Definitely! I have never used GEM (I've actually never seen an ST used in anger), but I've done some Amiga work, and yeah, well, there are good and bad in both AmigaOS and MacOS toolboxes/kernals. One thing I really like about the Mac though is there are a TON more books about programming for it. It also does more for you than the Amiga ROM does, but I dunno. I don't think I'm any slower or faster overall, writing an app for either system. Just have to get into a groove... 

 

Crutch: good point, I should have stated that one more clearly. I have a personal bias against those kinds of tools, in that I often think it's more work to figure out how it works (never documented as well as official stuff, and never written about as much), and they often produce kind of nasty bloat. Besides... If I didn't like reinventing the wheel, why would I be doing this stuff. <grin>

 

 

Link to post
Share on other sites
  • 68kMLA Supporter
20 hours ago, Frobozz said:

I have never used GEM (I've actually never seen an ST used in anger)

 

I've never written for the Atari but I spent a while fiddling with the innards of PC-GEM, then I did my big GEMDOS project last year which involved fiddling inside GEM too, and ew.  :p

Link to post
Share on other sites
20 hours ago, Frobozz said:

On 68k Mac, if you set up an app framework for yourself, you will be able to re-use it for A LOT of different apps in the future. 

Definitely true. I now make it a point, that if I have even the slightest thought that I might reuse a subroutine again, to make that subroutine fairly general-purpose. And yes, now that I've written 5 Macintosh applications in 2 years (TeleDisk, Sabina Test, Sabina Setup, Neptune, Aurora) it is paying off because I'm building my own library of subroutines.

Link to post
Share on other sites

I made some progress on building a QuickDraw backend for Nuklear (https://github.com/Immediate-Mode-UI/Nuklear) last night and finally got it drawing a UI! Not usable yet but I’m liking where it’s going. I’ve found the “Inside Macintosh: Imaging with QuickDraw” most helpful here so far: https://github.com/CamHenlin/nuklear-quickdraw/tree/messy-but-kinda-working

 

I’ve got it trying to display (and run) a calculator and took a short video. I believe I’ll have it fully functioning soon. Even if it ends up not being entirely useful I’m learning a lot building it out 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...