Jump to content

Classic Macintosh GUI programming thoughts


Recommended Posts

Nice work. It doesn't appear that toolkits like Nuklear and Dear ImGui have facilities for partial updates, so for better drawing performance I would think lvgl would be a better choice.

 

However, if the UI isn't updated often, Nuklear and Dear ImGui would be fine.

Link to post
Share on other sites
Posted (edited)

I've now got nuklear fully working outside of a few small things and code cleanup  (for test apps anyways, going to start using it to build something more useful soon...) using B&W QuickDraw at https://github.com/CamHenlin/nuklear-quickdraw. I think having a simple immediate mode GUI library is really nice and is going to be an excellent choice for building out small apps for Classic Macs rather than needing to dive in on the toolbox. The UI performance is excellent, with no flicker of any kind and instant response to user input, on the Mac Classic emulator running at standard speed. Using the default system font and standard drawing routines I think also gives things a very "Mac-like" feel.

 

ezgif-4-072a26373626.gif

Edited by camh
better gif
Link to post
Share on other sites

@camh I've been using nuklear for quite a while on linux myself, mostly with the X11/Xft backend. it's quite handy, but has serious limits -- what I don't like is that it "wastes" a lot of time hashing stuff to keep track of context, that will definitely be expensive on a 68k! What I *do* like is the command buffer drawing, kinda like PICT format really!

 

Perhaps you could re-create the Mac widgets 1:1 pixel style in Nuklear, and add a bit more "carried around context" to alleviate the hashing problem... the "current" Nuklear widgets are so un-mac like as to be quite annoying, for example buttons "triggers" when you click them, not when you release the mouse button (even in your demo!)...

 

I was a mac developer for 20+ years, starting from day one more or less. Yes, mac apps had a huge central "boilerplate" piece of code for event loops, menus etc; the later class libraries helped a lot; I never liked MacAp (even tho I always liked the LOOK of MacAp apps, with the splitter views etc!) but I used all the others at some point, culminating with PowerPlant. Pretty much 100% of Apple Telecom 3.0 was PowerPlant, it was really the ultimate IMO

 

 

Link to post
Share on other sites
On 4/2/2021 at 6:45 AM, buserror said:

What I *do* like is the command buffer drawing, kinda like PICT format really!


Yes, I was able to do the same thing. The entire UI is drawn using QuickDraw commands to an offscreen bitmap, then then drawn to the window as a single CopyBits command, much like double buffering in a video game engine. This works really really well and made the UI perform perfectly, eliminated flicker, etc. Like I said the performance here is really, really good. 

Link to post
Share on other sites
  • 68kMLA Supporter

Everything I know about NuKlear I learned just now. Interested concept, if I understand it. The idea is that it provides a framework for a generic UI, in platform independent C, and then everyone writes their own implementation (of the UI widgets and whatnot) for their platform? How big is it, in RAM, with say a basic UI framework going like your calculator demo? I wonder if we could bake it into a ROM chip. 

 

Anyway, very cool, want to learn more about your plans for it (but need to keep nose the grindstone and not pick up another project until I finish one of these 3 open ones I have...)

 

 

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

Everything I know about NuKlear I learned just now. Interested concept, if I understand it. The idea is that it provides a framework for a generic UI, in platform independent C, and then everyone writes their own implementation (of the UI widgets and whatnot) for their platform? How big is it, in RAM, with say a basic UI framework going like your calculator demo? I wonder if we could bake it into a ROM chip. 

 

Anyway, very cool, want to learn more about your plans for it (but need to keep nose the grindstone and not pick up another project until I finish one of these 3 open ones I have...)

 

 

 

Well there are 2 bits to Nuklear that are of interest:

1) The "immediate mode UI" -- instead of creating the UI, keep a separate "state" around to "map" to your own functional state, it implements "immediate mode" UI so instead of something like:

button = CreateMyButton(<there>);

....

if (a_click() && click_location() == button) { if (track_button_click(button) { eventually_do_something() }}

You code stuff like:

if (button(<there>)) { do_something now() }

 

It is actually super handy *for smaller kind of programs* -- you can more or less just slam code together and link the "logic" of the UI directly to what they are supposed to do.

 

2) the way Nuklear implement this

Each "widget" in Nuklear "draws" stuff into a "command buffer" -- ie instead of drawing *anything*, it stuffs all the drawing commands into one big "stream" buffer. And that's it, thats where Nuklear *stops*. The rest of the rendering is done by another piece of platform specific code that interprets the draw commands and draw them in whatever you fancy. So there is a VERY simple machine that walks that command buffer, and draws lines, curves, text, arcs, "images" in for example, opengl/X11/Cairo and now ... QuickDraw and hopefully it "looks" the same.

This method works fantastic for modern rendering, like OpenGL, because you can build vertex buffers and textures and all that jazz. It's still quite handy on other platforms too.

 

It *is* a bit costly tho, the command buffer WILL grow a lot for more complex drawing, and on modern machines it's not really a problem -- on smaller machines it's to be determined.

 

The beauty of the Mac QuickDraw code has always been that it was very efficient at /not drawing/ anything. The clipping/visible regions are without equal for that. Nuklear and offscreens buffers negate that; *everything* get redrawn each 'frame' so it acts more like a game than the old, efficient way we were used to. But it's terribly handy...

 

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

Thanks for the explanation, that made sense. 

 

Anyone have a built 68k app I could try out on the Mac Plus to see firsthand?

 

 


I can provide the built calculator demo later this evening, I don’t think I included it in the repo. Otherwise you’ll need to build it yourself. Other than that nothing exists yet

Link to post
Share on other sites
On 4/2/2021 at 5:31 PM, camh said:


I can provide the built calculator demo later this evening, I don’t think I included it in the repo. Otherwise you’ll need to build it yourself. Other than that nothing exists yet

 

Okay so maybe not "this evening" but almost a week later (I'm busy!), but I did finally get around to packaging up a relatively comprehensive nuklear demo, nuklear's "overview.c" from their official repo. I zipped it up as a .bin and a .dsk, if anyone wants to try to to run it. So far I have only run this on the pce-mac-classic emulator and not a real Mac.

 

It looks and runs pretty good, maybe needs a little tweaking here and there but seems totally acceptable to build an app with, keeping the limitations in mind. The code behind the app demo is really small in terms of what you would expect for such a complicated Mac gui (see: https://github.com/CamHenlin/nuklear-quickdraw/blob/main/overview.c) - some of the features don't quite work correctly or could just be ignored on Mac. Text input isn't perfect, graphs aren't perfect (looking at you axis labels), I don't have images implemented, (but now have myself eyeing adding a B&W PNG decoder to the repo!) etc...

 

For those not interested in trying to run the demo I included a short GIF clicking through a few items:

 

Kazam-screencast-00002.gif.f84ec54fe12e41fea51ed30a53cbf5a9.gif

NuklearQuickDraw.zip

Link to post
Share on other sites
  • 68kMLA Supporter

Very cool. That looks like a lot of work for one week!

 

I think speed is going to be an issue though. What's the likelihood of massive increases? Is it low, because it redraws the whole window every time? 

 

I tried it at 1x Mac Plus speed, and it was really too slow. 4x was much better, but I would say 8x is about there it starts to feel responsive. So I think for a target machine class, we might be talking Quadra 700+ / PPC machines? I mean, if no other improvements were made to speed. 

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

Very cool. That looks like a lot of work for one week!

 

I think speed is going to be an issue though. What's the likelihood of massive increases? Is it low, because it redraws the whole window every time? 

 

I tried it at 1x Mac Plus speed, and it was really too slow. 4x was much better, but I would say 8x is about there it starts to feel responsive. So I think for a target machine class, we might be talking Quadra 700+ / PPC machines? I mean, if no other improvements were made to speed. 

That’s interesting that you note speed being an issue there- I’ve been testing with the classic emulator at 1x speed and felt like it was totally usable with pretty much native level performance, I’ll have to look into the disconnect there. I see no reason why this shouldn’t be able to work fine on 68000 Macs 

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

That’s interesting that you note speed being an issue there- I’ve been testing with the classic emulator at 1x speed and felt like it was totally usable with pretty much native level performance, I’ll have to look into the disconnect there. I see no reason why this shouldn’t be able to work fine on 68000 Macs 

 

I wonder if it's an emulator thing. I was using mini vMac, FWIW. I can try with the real Mac plus, but Mini vMac at 1x speed has always felt like a pretty accurate representation of the Plus, speed wise. 

Link to post
Share on other sites
On 4/8/2021 at 5:28 PM, Frobozz said:

 

I wonder if it's an emulator thing. I was using mini vMac, FWIW. I can try with the real Mac plus, but Mini vMac at 1x speed has always felt like a pretty accurate representation of the Plus, speed wise. 

 

I went back this evening and realized after reading that I was actually using speed "0" which is variable and not what I intended to be testing on at all. I switched to "1" and agree that performance is a bit lacking. I spent a bit of time on it and got it a lot better this evening but still have some work to do. I also got text width measurement working right which I frustratingly figured out (without any documentation that I could find!) that you must set the graphics port before measuring text - even if the font and font size are the same between ports - otherwise the measurements will not be the same. I think spending a bit more time with performance will have it completely usable on 8mhz systems and will be my sole focus for the next few days of looking at this. 

 

Link to post
Share on other sites
  • 68kMLA Supporter

I definitely think for the most part, it's easier for us to learn these old systems now, than it was in the day: we have access to virtually unlimited books, and they are scanned and searchable. We have easy access to source code from UMich archives, and modern GitHub projects. And we can post on forums like these. But at the same time, there just isn't the same weight of developers working on them, so you don't necessarily have the chance to just walk over and ask somebody a question about font size and be able to get an answer. 

 

Can't wait to see how you do on the speed improvements. If you have any big learnings out of that, things that worked, things that didn't, please share those!

 

 

Link to post
Share on other sites

As I mentioned, most of the speed is very likely sunk into the hashing. The price to pay for that "immediate mode UI" is that it keeps a context in parallel to the UI elements, and goes and finds them all again at each calls using their "names". It is a LOT of lookups. It's quite "cheap" on modern CPUs but it still feels like a waste.

 

I've been pondering making another version of Nuklear where you DO keep the context instead of trying to hide it under the carpet. There's also the problem that hashing has collisions, and I've had several instances of Nuklear crashing as it was finding the context that was registered under another name anyway. So, very kludgy!

 

Link to post
Share on other sites
  • 2 weeks later...

I've never seriously programmed for Classic Mac OS but I've been lurking these programming threads...

 

Anyway, I've been thinking about trying to write a Rust library for System 7 programming; this could provide some abstractions to ease the complexity of GUI programs written in the Macintosh Toolbox, and also allow development using modern computers and IDEs (Rust can cross-compile, which means I could program in VS Code or another IDE on a modern computer and then run it on the old Mac). Unfortunately, Rust doesn't compile to m68k yet, so this would be limited to PowerPC-based Macs (at least for now).

 

I have no idea how complex this would be, or if it's even feasible for one person to do in their spare time. What do you folks recommend as good documentation of Macintosh APIs?

Link to post
Share on other sites
On 4/26/2021 at 3:44 AM, tanuki65 said:

I've never seriously programmed for Classic Mac OS but I've been lurking these programming threads...

 

Anyway, I've been thinking about trying to write a Rust library for System 7 programming; this could provide some abstractions to ease the complexity of GUI programs written in the Macintosh Toolbox, and also allow development using modern computers and IDEs (Rust can cross-compile, which means I could program in VS Code or another IDE on a modern computer and then run it on the old Mac). Unfortunately, Rust doesn't compile to m68k yet, so this would be limited to PowerPC-based Macs (at least for now).

 

I have no idea how complex this would be, or if it's even feasible for one person to do in their spare time. What do you folks recommend as good documentation of Macintosh APIs?

 

Assuming this is you here: https://github.com/autc04/Retro68/discussions/123? if so, very cool! Really interesting project although it's too bad that there can't be 68k support

 

I've been sticking with the "Inside Macintosh" books for everything that I need so far. The vintage apple site has everything in PDFs:

 

https://vintageapple.org/inside_r/

https://vintageapple.org/inside_o/

 

The informatimago website has a mirror of the apple devdocs, and is easily searchable html files: http://mirror.informatimago.com/next/developer.apple.com/documentation/macos8/mac8.html 

 

 

Link to post
Share on other sites
On 3/23/2021 at 11:18 AM, joshc said:

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).

 

Would you please explain how it interacted with the toolbox? I downloaded the User's Guide and Reference (for different versions, alas), but they just had cursory information about using "Declare" to make a particular Toolbox call invokable. They didn't say anything about where to find the name of the particular library that the call was associated with, or how you use calls that you have to pass, say, a Pascal-formatted string or a pointer to. Is this just not possible?

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...