Frontier Dreams. In the back of my mind Ive been thinking about the open-sourcing of the Frontier kernel, and like some other folks its made me dream of software thats close in spirit to the early versions of Frontier, before it became the basis for a content management system.
For those who dont know, Frontier began life as a scripting system for Macintosh. But not just another languageit included an object database and a relatively rich (for the time) library of verbs. You wrote code in an outliner, which I still think is a wonderful way to write code.
You used it do many of the same things people use Perl and Python (and so on) for today, only it was on Macintosh System 7. Instead of using pipes and Unix-y things for inter-application communication, it used Apple events. (Like AppleScript.) It was very common to use Frontier to do tasks that required scripting one or more other applications.
For instance, your script might grab data from a Filemaker database, format it as text in Frontier, then create a new email message in Eudora and send it. With Frontiers scheduler, its cron-equivalent, you could make this happen once an hour or whatever. And you might archive the data in its object database and create weekly reports based on that data.
Thats just a for-instance, of course. The gist of it was that it made it possible to do custom things that apps like Filemaker and Eudora would never (quite rightly) have supported on their own.
Sounds like AppleScript, right? Well, yes. But Frontier brought some things that AppleScript doesnt have. (The browse-able object database, the richer library of verbs, the code outliner, the scheduler, and so on. Frontier is an entire environment on its own, though an open one, aware of the rest of the system.)
My dream app
First thingI dont have plans to work on Frontier. Id love to use the results of someone elses work, though! As much fun as it would be for me to work on it (partly because the kernel is an old friend, but more so because I know a lot of Frontier users who are cool cats) it just isnt on my path. However, Id be happy to make sure my software works well with people who want to script it with Frontier.
Anyway… my dream app goes back to that earlier vision of Frontier. To bring it up-to-date, there are a few things Id love to see:
Whitespace-aware Python just begs to be written in an outliner. The language is similar in style to UserTalk (Frontiers scripting language), but, key fact, its object-oriented.
The object-oriented thing is a big deal: Ive gotten so I wont even consider writing in a procedural language for anything but the smallest of tasks. I want objects.
And Python is just plain cool.
I wouldnt advocate dropping UserTalk, Id argue for making Python a first-class peer of UserTalk. There are some challenges to consider, though. Frontier internally is receptive to other languages. (Note that you can write scripts in any OSA language, including AppleScript). But youd have to make it so Python could access the object database (to store and retrieve data and to call other scripts) and youd want a way to freeze-dry Python objects in the database.
Okay, obviously I dont care about classic Mac OS or Windows. I care about OS X.
When Frontier was written, there were no system-supplied user interface controls for tables, outlines, and toolbars. And all applications polled for events (via WaitNextEvent, if I remember correctly).
The first obvious thing to do is replace a bunch of the user interface code with .nib files and standard Cocoa widgets. However, I think Id retain the existing outliner for writing scripts. (Cocoa and Carbon can co-exist: its not a problem.) But all toolbars, the object-database browser, text-editing views, and so on would use Cocoa user interface.
In theory, youd end up with less code, better performance, and a modern OS X UI.
Bonus points: custom windows
Sometimes you want to create a mini-application, a custom dialog or window backed by a script. Frontier has a long history (at least on classic Mac OS) of supporting this: you could run dialogs from resources, you could run MacBird cards.
In the year 2004, the thing to do would be to run dialogs and windows from .nib files. Youd lay out your user interface using Interface Builder, then run it in Frontier.
How would you handle wiring up actions and outlets to scripts in Interface Builder? Glad you asked. You probably wouldnt. One way to handle this is to give each item a unique tag in IB. Then your script might have a handler like
on itemDidSendAction (itemRef, actionRef). This would be called when a checkbox was clicked, a button pressed, whatever. Your script would, obviously, have to branch on which item sent the action and what the action was. Not quite as slick as wiring up actions, but it would work.
The other side of the coin is outlets. Thats where tags come in. To get a reference to an item, you might write something like
itemRef = cocoaWindow.itemWithTag (tag, windowRef). Then you could do things like set the value of a text field like so:
cocoaWindow.setStringValueForItem (itemRef, someString).
Double bonus points
Get PyObjC in the mix of all this, and now youre talking about something extraordinary.
Its possible that there will be an exciting burst of creativity once the kernel is made open-source. I think thats totally cool, it it comes to be. For my part, Id be happy to answer any questions I can for people who work on the code, since I know a little about it.
Its entirely possible that the things Id like to see are not the things most people would like to see, and thats fine. (But I can dream, right?)
P.S. A glimpse into the kernel: The first thing youll discover is that, before Frontier was Frontier, its name was Cancoon. [inessential.com]