Guildhall: A Primer

Guildhall is an application that currently runs just on macOS. It takes over the screen to present an alternate desktop within which it can run a variety of built-in applets. These applets use Guildhall's toolbox to create and manage windows, draw and handle menus, store and retrieve data, and receive and process events. I named the desktop manager the Filer after the desktop manager in the UCSD Pascal system. It's a sentimental choice, given where the earliest sections of code in Guildhall started. You can see a Filer window in the lower left. It is showing the contents of the archive Fin Harbor, the icon for which is visible in the upper right, an archive being just a host file containing its own hierarchical file system.

Also shown are three games: Seahaven Towers, Haniport Levee, and Angeline Crossing. The Paint applet is peeking out from the lower part of the image and the graphics demo Grafiker is up near the top. The credits are also shown on the left, mostly just to get Guildhall's picture in there (thank you Ian H).

At the top just left of center you can see that Guildhall uses pull down menus. Hierarchical menus are supported as well as toggled, checked, and grouped menu items. A variety of controls (fields) are built into Guildhall, and you can see a few such in the picture above. At the bottom of the picture sits what I call the drop bar. Minimized applet documents are parked there. The drop bar also gives access to the trash/recycling bin and can activate the Filer when the desktop is cluttered.

Design Goals

One design goal for Guildhall is to be reminiscent of classic Mac, roughly in the System 9 time frame. The motivation for this is simple nostalgia. That said, the two systems are different enough that they aren't likely to be mistaken one for the other.

Another design goal is for all elements of the Guildhall desktop to be exactly persistent across sessions. If you quit Guildhall and come back, everything should be as you left it. You should have the same windows, the same layout, the same partially edited text fields, even the same clipboard contents and undo chains on the documents that provide them. This is somewhat like an idea that Taligent had, a place in their People, Places, and Things UI approach. I never got to see that fully realized, and in more modern times Spaces on macOS seemed to provide a similar virtual desktop mechanism (now part of Mission Control), but with a few key differences as discussed below.

A third design goal is to make minimal usage of host services. Guildhall uses host toolbox calls to deal with memory, threads, time, files, sound, graphics, input events, and a few other miscellaneous utilities, but that's it. In particular for macOS as the host I use almost nothing from Apple's Cocoa frameworks. Everything you see, windows, menus, icons, controls, and desktop, all of it is drawn and managed by Guildhall's embedded toolbox. Furthermore, all host calls are abstracted into a low level layer. The rest of Guildhall's toolbox has no exposure at all to Mac header files. It makes for speedy compiles and very little sensitivity to OS updates. And, in theory, if the low level host layer is ported to another OS then Guildhall should run there, too (provided, of course, the OS hasn't been hamstrung by having to provide compatibility with a sucky phone OS).

And that leads to the fourth design goal, cross platform compatibility. It actually isn't that far away. When Seahaven Towers and Haniport Levee were products, they used most of the same lower level code that Guildhall uses. The abstraction layer worked pretty well. Once an application worked on macOS, porting to Windows was very easy. In fact, after Haniport Levee worked on macOS, the port to Windows was a recompile and one minor bug fix. It took about 15 minutes. Note that at the time those two products were published, Macs and Windows machines used different byte orderings. The Mac/68K/PPC used big endian ordering while Windows/Intel used little endian ordering. My underlying frameworks could figure out which was which and read and write the data from either, automatically swapping bytes around when needed. This isn't much of a concern today, since most systems are little endian, but one never knows when some machine instruction set designer will decide that big endian is indeed better so lets switch back. The capability to support either one, and to translate data between them, is already present in Guildhall so I just need to make sure I don't lose it somehow. (And regarding that machine instruction set designer, you might be interested in my lofty plans for the Classic applet).

The cross platform abstraction layer hasn't been as carefully maintained in the past decade, but if the need arises I'm confident it can be brought up to date on Windows. Porting to FreeBSD® should be straight forward but I haven't started that port yet. The reason I find it compelling (besides dealing with the obvious threat of Apple blocking all non-app-store applications from running on macOS) regards a demonstration I've long wanted to run. Earlier I talked about virtual desktops. The difference between Guildhall's desktop and something like Spaces lies in the fact that Guildhall's desktop is designed to travel with the host archive file, potentially opening it up on a completely different OS. I want someday to prove this point by starting a Filer file copy on Guildhall/Mac and shutting down Guildhall before it completes. Then I'll move the archive's host file to a Windows or FreeBSD system, run Guildhall there, open that same archive, and watch the file copy complete. It will be glorious. And if FreeBSD makes the same stupid design decision regarding a sucky phone OS, well, it's open source. It can be fixed.

Next Steps

Most changes to Guildhall arise from working on various applets. For example, getting smooth brush tracking in Paint required some tuning of the Guildhall event model. There are, however, a few big missing pieces that I'd like to work on, eventually, listed here in order of degree of wishful thinking:

• Implement video in an applet window
• Implement 3D in an applet window
• Implement networking, integrated with the streaming model Guildhall uses
• Resurrect Guildhall running on Windows
• Port Guildhall to run on FreeBSD
• Install Guildhall as the desktop manager for FreeBSD, elaborate its embedded toolbox as the main API for application development, and make Guildhall's built-in applets into real applications in that environment