I am a self-funded Indie (lone) developer. I made a number of classic business blunders on the FaceSpan 5 project. I broke the golden rule: never (never!) rewrite a software product. I massively underestimated the effort required to complete the product. I set off without having sufficient resources to complete the project. Because I took so long to complete my work, the market moved on — AppleScript’s importance to the customers I intended to target declined. Some may argue that the market was never really there to provide a return for a product of this complexity. Finally, I didn’t pull the plug soon enough. Hindsight its great.

Not all was lost. Some of the code I developed for FaceSpan 5 found a home in Script Debugger 5.

A Little History

Many years previously I developed FaceSpan 3 under contract for its owner. As part of that effort I became impressed with FaceSpan’s power and simplicity. FaceSpan 3 was successful, for a development tool, and even received an Apple Design Award at that year’s Worldwide Developers Conference. Sadly, after my involvement with the product ended, FaceSpan fell into disrepair and did not make the leap to Mac OS X. FaceSpan’s developer finally produced FaceSpan 4 which was to little to late and not as successful as hoped for.

I acquired FaceSpan 4 in 2006 and, after a period where I tried to fix the most serious issues with the product, I concluded that FaceSpan 4′s dependance on AppleScript Studio was its core problem. FaceSpan 4 had great integration of a visual UI bilder and coder editor, but lacked a good runtime environment and debugging.

Work on FaceSpan 5 began in 2007 with the aim of freeing FaceSpan from AppleScript Studio and restoring the classic FaceSpan’s attractiveness. By the time I stopped FaceSpan’s development I believe I was well on my way to achieving my aims. Two great Mac developers helped me with the project:

• Adrian Ruigrok, who now works for Apple, developed much of the FaceSpan 5 IDE code.
• Matt Neuburg acted as a sounding board for my ideas and developed the initial FaceSpan 5 documentation.

The project turned out to be too ambitious given my resources. Additionally, FaceSpan revealed a number of AppleScript issues and problems in Apple’s Cocoa Scripting framework which I was ultimately unable to overcome.

What Is (Was) FaceSpan?

FaceSpan 5 was an integrate tool for building Cocoa applications using AppleScript. Many people saw similarities to Apple’s HyperCard. FaceSpan provided a visual UI builder, an AppleScript editor, an AppleScript debugger and a runtime environment designed to take the best advantage of AppleScript’s strengths and provide a collection services and UI widgets out of which applications can be built. Matt wrote this description of FaceSpan 5 back when the project was active.

The FaceSpan 5 runtime environment wrapped Apple’s Cocoa Frameworks in a sanitized and simplified AppleScript focused programming interface. This allowed one to build fully Cocoa-native applications using AppleScript without having to learn anything about Cocoa. The intent was for Cocoa to be an implementation detail rather than the programming interface.

We’ll never know if the FaceSpan 5 approach was actually better than the AppleScript Studio interface offered by Apple. My hope was that FaceSpan’s approach was actually simpler, and not simply a substitution of one complicated programming interface for another.

Since FaceSpan 5 was abandoned there have been several developments in the area of AppleScript GUI tools. Firstly, Apple transitioned from AppleScript Studio to AppleScriptObjC. Shane Stanley has released his ASObjC Runner which can display progress dialogs. And then there is the long lived Appearance OSAX from 24U Software.

The Last Build

When I stopped developing FaceSpan 5, a lot of people came out of the woodwork looking for a copy of the software. I was not willing to make the software available at that time, but I am now. I’m doing this now because I think it might be interesting for those of you who were/are curious about what I was working on to get a chance to play with the product.

Keep in mind that this build predates the release of Xcode 4 and there are some interesting similarities. Apple had to be developing parts of Xcode 4 during the same period so its fascinating to me how common ideas arrise in different places.

Before you download the software, please keep the following conditions in mind:

• This is Alpha-Stage software. This means that it is buggy and its not feature or UI complete. Expect it to crash and fail. If you stick to the examples included with the documentation, you should be okay.
• THE FACESPAN SOFTWARE IS PROVIDED AS-IS FOR EVALUATION PURPOSES ONLY. USE AT YOUR OWN RISK.
• PLEASE DO NOT FILE BUG REPORTS. I’m not going to produce another build.
• PLEASE DO NOT ASK ME TO OPEN SOURCE THE PROJECT. This product shares a lot of code with my Script Debugger product and I’m not willing to release the code.
• RTFM. Seriously, you are on your own.
• The software should run on Snow Leopard (10.6) or Lion (10.7). I have no idea if it will work on Mountain Lion (10.8) or beyond.

View Matt Neuburg’s Alpha Documentation. More FaceSpan 5 information and screencasts.

Download FaceSpan 5.0.

FaceSpan 5 Blog Posts.

To get you going, check out this post: Dock Icon Changer.

Have Fun!

The just released FaceSpan 5.0d70 build will continue to run and has no expiry dates built in. The projects you build with it should continue to execute.

My reasons for suspending FaceSpan development are many. Chief among them are that I keep missing every deadline I have set for myself. I am now over 2 years into this project and I cannot clearly see how to wrap development up so that I have a product to sell. I also am feeling that in the time it has taken me to do this work, the world has moved on and AppleScript-based UIs are not going to be relevant in the marketplace. The Web, Flash and other technologies are moving much faster than AppleScript or I can match. Additionally, there many technical limitations in AppleScript and Cocoa Scripting that I keep having to hack around in order to make FaceSpan usable.

All of this has left me feeling burnt out and I need some perspective. So I’m going to down-tools on FaceSpan for an indefinite period of time. I’m hoping that I can find a way to revive or reuse the work I’ve done at some point in the future, but I have no specific plans at this time.

This FaceSpan example attempts to address this request. The demo presents a simple form in a window, and allows the user to enter data, update, add and remove records.

SQLiteDemo (120Kb)

Testing pre-release software involves some interesting, and sometimes nerve-wracking, decisions. In most cases the best way to test is with a real job, but committing a large job to alpha software can involve a leap of faith. You have to weigh up what happens if it doesn’t work out, what the alternatives are, and even how much faith you have in the developer involved.

Several months back I took on a fairly large project, and this was the process I was going through. In some ways it was a straight-forward scripting job, but what complicated things was the need for a bit of user interface, plus the amount of code likely to be involved. I looked at the options: a series of applets with death-by-display-dialog, or the potential maintenance headache of AppleScript Studio. FaceSpan 5 was at least worth considering, even though it was a long way off release.

I’d already written a fair bit of code in the form of a couple of applets, so the first thing to try was to bring them into FaceSpan and see how much effort was involved.

The process was surprisingly easy, as was adding the basic UI I needed. I could see that things would get more complicated if I wanted to implement non-modal elements such as sheets, with a much more event-oriented approach required, but my immediate goal was to try to get the main basic dialog working. My first impression was one of comfort: the editing and debugging environment were largely similar to Script Debugger, if a little undeveloped in some areas (we’re still talking early development software). So far, so good.

I started running the resulting Facespan 5 apps, and got my second surprise: performance. The apps were mainly targeting InDesign and Illustrator, both of which have a script menu or panel. Anyone who has scripted them knows that there’s a big difference in how fast things happen when scripted from the menu/panel versus an external application. 

But the FaceSpan 5 apps were driving both InDesign and Illustrator more like they were being run from a menu/panel: InDesign stuff happened much faster than when driven from a normal AppleScript applet, and with Illustrator the difference was massive — almost an order of magnitude. This was a big plus for this project.

By now the amount of code was growing, and I had to look at how to manage it. The traditional AppleScript way is to save handlers in libraries, and load them into variables at launch time. 

But libraries involve issues like where to store them, and when it comes to debugging they’re a bit like black boxes. That’s fine when you have well developed code in them, but it can be inconvenient on a project where you’re developing both the library code and the main code at the same time, and the requirements are changing. You end up doing things like putting handlers inside scripts until you have them debugged, and then juggling them — the code management issues start to make the code writing a lot harder.

I was hoping for a better approach, and FaceSpan 5 had it in the bag — objects called bags that are nothing more than containers for holding code.

The advantages of using bags soon became apparent because of another FaceSpan 5 feature, delegation. So I could put some of my “library” handlers in a bag, delegate the bags containing the main code to this library bag, and call the handlers without having to jump through the hoop of loading the bag into a global variable and referencing it that way from then on — I just call dosSomething(), and if there in no doSomething() handler in the bag where it’s called, it just looks further up its delegation chain until it finds one. 

There are a couple of gotchas, but using bags like this really helped me focus on the code, especially at the stage where I was rearranging things and moving stuff about. As a bonus, doing it this way reduces launch time because there’s no need to load slabs of code first — they don’t get loaded until called, and not at all if they’re not called.

The other big advantage of using bags is in debugging: you can step through your script, in and out of handlers in other bags, seemlessly. And having a series of smaller bags of code that you can easily switch back and forth between, without having to worry about what’s in what file or bundle, makes managing a larger project so much simpler. It’s hard to explain, but it seemed to make it easier to arrange the code to reflect how it all interacted.

I still have a wish list, and I still occassionally copy chunks of code into Script Debugger for debugging. At the same time, I’m also moving smaller projects that could happily be done as applets into FaceSpan, largely for the performance gain. And there’s still lots of stuff in FaceSpan I haven’t started exploring. But so far I’m a very happy, and enthusiastic, “tester”.

FaceSpan 5.0 provides two template projects (Applet and Droplet) to make this transition simpler.

The advantage of using XSL over CSS is that you can restructure the incoming XML data in any way you like. For instance, with CSS, you are stuck with the order of XML elements, but with XSL you can re-order them. Additionally, the XSL stylesheet can incorporate additional HTML markup, such as column headings.

Here’s a fairly simple XSL stylesheet that converts the XML into an HTML table, complete with headings.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:output method="html"/>

  <xsl:template match="doc">
        <html>
        <head>
            <title><xsl:value-of select="@name"/></title>
            <link rel="stylesheet" type="text/css2" href="foo.css"/>
        </head>
        <body>
          <table width="100%" border="0" cellpadding="0" cellspacing="0">
            <tr>
              <td>
                <table width="100%" border="0" cellspacing="1" cellpadding="0">
                  <tr>
                    <td height="15" width="140" nowrap="yes">
                      <table width="100%" height="15" border="0" cellpadding="0" cellspacing="0">
                        <tr>
                          <td class="tablehead">Name</td>
                        </tr>
                      </table>
                    </td>
                    <td height="15" width="140" nowrap="yes">
                      <table width="100%" height="15" border="0" cellpadding="0" cellspacing="0">
                        <tr>
                          <td class="tablehead">Modification Date</td>
                        </tr>
                      </table>
                    </td>
                    <td height="15" nowrap="yes">
                      <table width="100%" height="15" border="0" cellpadding="0" cellspacing="0">
                        <tr>
                          <td class="tablehead">Path</td>
                        </tr>
                      </table>
                    </td>
                  </tr>

                  <xsl:apply-templates/>

                </table>
              </td>
            </tr>
          </table>
        </body>
        </html>

  </xsl:template>

  <xsl:template match="row">

        <xsl:variable name="rowStyle">
            <xsl:choose>
                <xsl:when test='(position() mod 2) = 1'>oddRow</xsl:when>
                <xsl:otherwise>evenRow</xsl:otherwise>
            </xsl:choose>
        </xsl:variable>

        <tr valign="top"><xsl:attribute name='class'><xsl:value-of select='$rowStyle'/></xsl:attribute>
          <td height="14" width="140" class="tabletext">
            <xsl:value-of select="./name"/>
          </td>
          <td height="14" width="140" class="tabletext">
            <xsl:value-of select="./date"/>
          </td>
          <td height="14" width="100%" class="tabletext">
            <xsl:value-of select="./path"/>
          </td>
        </tr>
  </xsl:template>
</xsl:stylesheet>

And here’s the AppleScript code that generates the XML data, and displays it in an HTML view. Its very similar to the CSS example. The key difference is the inclusion of the <?xml-stylesheet type=”text/xsl” href=”foo.xsl”?> directive in the XML data which directs the HTML view to apply the foo.xsl stylesheet to the data before displaying it.

on didInvokeListFinderFiles(theObject)
    local rsrcsFolder, theNames, theURLs, theDates, theXML

    set rsrcsFolder to POSIX path of (get my application's resources folder)

    try
        --  Generate XML listing the files in the top Finder window
        tell application "Finder" to ¬
            set {theNames, theURLs, theDates} to {name, URL, modification date} of items of first window

        set theXML to {"<?xml version="1.0"?>"}
        set end of theXML to "<?xml-stylesheet type="text/xsl" href="foo.xsl"?>" -- associated a XSL stylesheet with this XML document
        set end of theXML to "<doc>"
        repeat with i from 1 to length of theNames
            set end of theXML to "  <row>"
            set end of theXML to "    <name>" & (item i of theNames) & "</name>"
            set end of theXML to "    <path>" & (item i of theURLs) & "</path>"
            set end of theXML to "    <date>" & (item i of theDates) & "</date>"
            set end of theXML to "  </row>"
        end repeat
        set end of theXML to "</doc>"

        --  Convert the list of strings we have accumulated into one long string that we can display
        set AppleScript's text item delimiters to {return}
        set theXML to theXML as string

        --  A this point we end up with an XML document looking something like this:
        --
        --  <?xml version="1.0"?>
        --  <?xml-stylesheet type="text/xsl" href="foo.xsl"?>
        --  <doc>
        --    <row>
        --      <name>AbstractConnection.h</name>
        --      <path>file://localhost/Users/mall/Desktop/connection/trunk/AbstractConnection.h</path>
        --      <date>Friday, July 13, 2007 4:59:01 PM</date>
        --    </row>
        --    <row>
        --      <name>AbstractConnection.m</name>
        --      <path>file://localhost/Users/mall/Desktop/connection/trunk/AbstractConnection.m</path>
        --      <date>Friday, July 13, 2007 4:59:01 PM</date>
        --    </row>
        --    ...
        --  </doc>

        --  Display the XML in an HTML view using an XSL stylesheet to make it look like a nice pretty table.
        tell my htmlView
            set value MIME type to "text/xml" -- makes the HTML view treat the string as XML rather then HTML
            set value base URL to (path to resource "foo.xsl") -- tells the HTML view where the resources are (stylesheets, CSS & gifs)
            set value to theXML -- apply the XSL stylesheet and display the resulting HTML
        end tell
    on error errMsg
        display alert "No Finder Window" message "Please open a Finder window to list." buttons "OK" over my window
    end try
end didInvokeListFinderFiles

When you put all this together in FaceSpan, here’s what it looks like:

Display XML (XSL) Example Project

I’m going to use this blog post to collect a summary of the differences between FaceSpan 5 and FaceSpan 3. This list will no doubt grow over time as we learn more about how best to program FaceSpan 5.

So here we go:

1. The names of many properties have changed. When the FaceSpan 5 dictionary settles down, I’ll prepare a table that maps the old FaceSpan 3 names to the new FaceSpan 5 names. Until then, you’ll have to use the FaceSpanKit dictionary to find the new names.

2. You can safely ignore FaceSpan 5′s delegates when starting out with FaceSpan 5. FaceSpan 3 message dispatching is identical to FaceSpan 5′s default way of dispatching events (i.e. upwards the containment hierarchy: view -> window -> application).

3. FaceSpan 3 allowed you to reference any view from any other view. This allowed you to say things like text view “myViewName” in any other view’s script and FaceSpan would search the window for you.

   In FaceSpan 5, you have to explicitly reference the window using my window‘s text view “myViewName” (or more directly: my window’s myViewName).

4. There are no storage items. However, you can simulate storage items using Bag objects. Just create Bag instances at the application level in the IDE. You can then use the Bag‘s persistent data property to store information that should be retained between application runs.

…more later

The very fact that I was able to do this should serve as an indication of just how rich and how powerful FaceSpan 5 is already, even in its current state.

Glass half empty, glass half full

There are actually two main areas in which FaceSpan 5 isn’t finished yet:

• The IDE. By this I mean the environment in which you work as you develop your application. For example, you can drag a button into a window to tell FaceSpan that there should be a button at this location in this window. But, so far in FaceSpan’s growth, no guidelines appear to show you when the button is at the correct position (a certain number of pixels from the edge of the window, or aligned with other widgets in the window), and you can’t yet double-click on the button to change its title (you have to work in FaceSpan’s “inspector” palettes). Also, when you’re debugging, certain powerful Script Debugger features, such as breakpoints, aren’t yet implemented in FaceSpan.

• The “widget” repertoire. Certain standard interface elements that lots of people would like to use just aren’t there yet, or are present only in rudimentary form.

Despite these current limitations, the actual process of developing LAMEncoder was wonderfully fast and easy. In fact, I’d have to say (not without a certain amount of prejudice, to be sure) that FaceSpan 5 is already shaping up to be the best application development environment I’ve ever used. The IDE has enough functionality, and we have enough interface widgets in place, that we’ve passed a certain tipping point of usability and usefulness.

Indeed, I can specify for you quite precisely what tipping point it is. Very early on, when FaceSpan 5 was just a gleam in Mark’s eye, he posed me a challenge: At some point, he hoped, there would come a day when I would tell him that I’d rather develop using FaceSpan than any other development environment. That day is here. Not since HyperCard has an IDE felt so satisfying and easy to me. In a future article, I’d like to write more about that, using the organization and development of the LAMEncoder code to illustrate.

In this article, though, I’ll just describe the finished product, LAMEncoder itself, particularly with regard to its interface. This (and using LAMEncoder itself, of course) should give you an idea of just how powerful FaceSpan is, even now.

The LAME game

So. What does LAMEncoder do? It encodes WAV and AIFF files to MP3 using the freeware LAME encoding engine. I prefer LAME to iTunes’ MP3 encoding engine. But LAME is a command-line tool, and I can never remember the commands. LAMEncoder’s purpose is to remember and construct those commands for you. You hand it some WAV or AIFF files, and set the parameters the way you want them. Then you press the Convert button, and LAMEncoder uses the LAME engine to encode the files to MP3.

If this sounds familiar, it should. The idea comes straight from the LAME Encode Automator action developed starting on p. 452 of my AppleScript book. That Automator action wraps an AppleScript script in “just enough interface” to make it convenient and powerful. LAMEncoder wraps the same functionality in even more interface — enough interface to constitute a full-fledged, stand-alone application.

Here’s the main window:

In the screen shot above, notice the tooltip. All the interface widgets have tooltips, and, like this one, many of them are dynamic – they change depending on the situation. Here, the tooltip is explaining why the file list area is blank. Once we hand LAMEncoder some files to convert, the tooltip will automatically read differently (as we shall see later).

There are three ways to hand LAMEncoder some files to convert. One way is to press the Add File button in the toolbar at the top of the window. When you do, a standard Open File dialog appears:

In the above screen shot, I’ve selected an AIFF file. Now I’ll press Add. The Open File dialog closes and the selected file appears in the list:

Notice that the Clear and Convert buttons have become enabled as well. They were disabled before, because, with nothing in the file list, there was nothing useful they could do.

Another way to add files to the list is to press the Add Folder button in the toolbar. When you do this, a standard Choose Folder dialog appears:

When I choose the “wavs” folder and click Add, any AIFF or WAV files in that folder are added to the list:

Naturally, the toolbar isn’t the only place to access the Add File and Add Folder functionality; after all, the user could hide the toolbar, or even customize it to remove those buttons. So the same functionality is also present in the menu, complete with keyboard shortcuts:

The third way of adding files, not illustrated here, is to drag them from the Finder into the list.

HTML View benefits

At this point we should pause to answer a burning question that I’m sure you’re racking your brains over right now: what the heck is this interface widget in which the file list appears? It clearly is not a standard Table View. And that makes sense, because the Table View is one of the important interface widgets that hasn’t been written into FaceSpan 5 yet.

This was probably the biggest limitation of the FaceSpan 5′s current state that I faced when writing LAMEncoder. It meant that I had to find a workaround means of displaying a scrolling list of the files the user wanted to encode. The workaround was to use FaceSpan’s HTML View widget. Yes, that area in the middle of the window is actually a Web browser! LAMEncoder structures the list of files as HTML and hands that HTML to the HTML View widget.

An HTML View widget is a powerful animal in FaceSpan. To see how powerful, take a look at this next screen shot:

The above screen shot displays the tooltip for the HTML View when the list actually contains some files. Notice that it has changed from the tooltip we saw earlier. Notice also that it claims we can click on a file name to play that file. Let’s try it! We click on the last file in the list, and a dialog appears:

You can’t hear it, of course, but in that screen shot the dialog really is playing the WAV file. That part is easy, because FaceSpan has a Movie View widget; the dialog’s interface is nothing but a movie controller, and QuickTime knows how to play AIFF and WAV files. But how is it possible that you can click in the list of files in order to play a file? Well, as I said, an HTML View widget is a powerful thing in FaceSpan. One of the powerful things it can do is intercept the user’s request to navigate to a link. The names of the files are links. So when the user clicks on the name of a file, that’s a link navigation request; the HTML View hears about this, and instead of actually navigating to anything, it hands the information about the link over to the file-playing dialog, which opens and plays the file.

Incidentally, the power of an HTML View is also why we can drag and drop a file from the Finder in order to add it to the list. This is quite remarkable, because in general, drag-and-drop is one of the things that isn’t implemented yet in FaceSpan! But an HTML View is its own little world, and it already knows how to respond to drag-and-drop. When it does, this counts as navigation (basically, it counts as an attempt to open a file). In LAMEncoder, the HTML View intercepts this attempt, and instead of navigating anywhere, it effectively hands the file over to the Add File button.

Encoding in action

So now that we’ve created a list of files to convert, let’s actually convert the files in the list. First, we use the “Conversion parameters” area of the window to set up how the conversion will be performed. In this next screen shot, I’ve decided to use CBR (constant bitrate) encoding, and I’ve entered a bitrate value of 320 for very high quality:

Notice that the text above the popup menu has changed from lame --preset standard to lame --preset cbr 320. That text represents the command-line parameters that will actually be sent to LAME to perform the encoding. The change in the text happens automatically as you play with the “Conversion parameters” interface.

Furthermore, however you set the “Conversion parameters” interface is automatically remembered by LAMEncoder when you quit, by being written into the application’s user defaults (its Preferences .plist file); when you start up LAMEncoder again, that information is fetched from the user defaults and the “Conversion parameters” interface appears just the way you left it when you quit. That sort of thing, which adds a nice professional touch to our application, is extremely easy in FaceSpan.

Anyway, now we press the Convert button. The Terminal opens and LAME is started, with the files and conversion parameters that we specified in LAMEncoder’s window:

That may seem a little nerdy, but for that very reason I like it. LAME provides nice progress feedback as it runs in the Terminal, so it makes sense to me to hand over the actual conversion process to the Terminal and let LAME do its thing. Meanwhile, LAMEncoder itself is free for further use; having handed off the correct command to the Terminal, it returns instantly and sits idle. The user can even quit LAMEncoder at this point, while the Terminal chugs merrily along, encoding the files.

Finishing touches

Now I’d like to point out a few of the finishing touches in the LAMEncoder interface that give it a full-fledged, “professional” application quality. First, there’s a standard About dialog:

All the underlined blue terms are links that the user can click to go to the relevant Web pages.

LAMEncoder also has a second About dialog, which properly attributes the LAME engine and provides the text of the LGPL agreement under which it can be used in an application. That’s required, because LAMEncoder actually includes a copy of the LAME engine inside itself:

(Incidentally, the above window is the only part of LAMEncoder containing an interface widget that isn’t really built into FaceSpan. The scrolling Text View containing the text of the LGPL is implemented through a “plug-in”, which is essentially a bundle of Objective-C code. Eventually, the Text View will be a native FaceSpan widget.)

Next, LAMEncoder has some preferences that the user can set. When you choose Preferences from the LAMEncoder menu, the preferences dialog appears:

As you can see, we have two preferences here.

• First, using radio buttons, the user can decide whether to use the LAME engine built into LAMEncoder, or to use a copy of the LAME engine that may already be installed on the user’s computer. This is because it’s possible to compile LAME yourself, possibly using settings optimized for your processor, and we wouldn’t want to prevent a user who has done so from using that specially compiled LAME.

• Second, having chosen the second radio button, it is also necessary to press the Set button and tell LAMEncoder where that on-disk copy of the LAME engine is. In this case, I’ve specified a bogus location; there is no copy of LAME on my desktop. If I press the second radio button and try to dismiss the preferences dialog, I’ll get an error alert:

  

  The preferences dialog then opens again, forcing me either to use LAMEncoder’s internally provided LAME engine or to specify a location where there really is a copy of the LAME engine on my hard disk.

Finally, like any good application, LAMEncoder provides online help:

The user chooses from the Help menu, and the online help appears (in this case, it’s a page of HTML, and opens in the user’s default browser).

Future directions

So much for LAMEncoder itself. There are two kinds of future directions I’d like you to be thinking about.

First, there are future directions for LAMEncoder. Now that this version of LAMEncoder is finished, it’s easy to add further features. For example, right now LAMEncoder implements only the --preset subset of LAME commands (because those are the only ones I really use). It would be easy to add even more LAME commands, making LAMEncoder an even more powerful, complete front-end interface to LAME.

Second, there are future directions for FaceSpan 5 — and for you. If LAMEncoder is the kind of application FaceSpan 5 can create right now, think what kinds of application it will be able to generate in the future. Clearly, this is an application development tool worth watching. Stay tuned!

As always when creating FaceSpan plugins from Cocoa frameworks, the tough part is converting the Cocoa APIs into a simple to use AppleScript syntax. In the case of these graphing views, I have substituted the ‘Data Source’ based APIs with a simple event for the curve view, and a value property that accepts a list of values to be graphed (a list of reals for the histogram and a list of x-y points for the scatter plot).

Here’s how it all looks running in a FaceSpan-built application:

The code for the curve view looks like this:

--
--  CT curve uses this event handler to get the data to be graphed
--
on CT get y value theCTCurve for theXValue
    return theXValue * theXValue * theXValue + 1.0
end CT get y value

The event is called repeatedly by the curve view to generate the data to be graphed.

The code for the histogram looks like this:

on initialize theResponder
    --  CT histogram needs a list of reals to graph
    set theData to {}

    repeat with i from (x axis minimim) to (x axis maximum)
        set end of theData to random number from 1 to 10
    end repeat
    set value to theData

end initialize

Here I simply generate a random series of values and assign them to the view’s value property. The plugin does the rest.

And finally, the code for the scatter plot looks like this:

on initialize theResponder
    --  CT scatter plot requires a list of points (x, y pairs) to graph...

    set yValue to 1.0
    set theData to {}

    repeat with i from (x axis minimim) to (x axis maximum)
        set end of theData to {i, yValue}
        set yValue to yValue + (random number from 0 to 2.0)
    end repeat
    set value to theData

end initialize

Again, I simply generate a random series of point values and assign them to the view’s value property. The plugin does the rest.

The sources for the plugin are included in the FaceSpan 5.0d42 SDK.

However, this is at odds with how AppleScript is commonly used to orchestrate the actions of other applications. One generally begins a long process that involves directing one or more applications to complete a task. Even if the AppleScript code is short, it may have to wait for another application to complete a lengthy operation.

The question becomes how best to accomplish this kind of AppleScript automation in FaceSpan. One answer is forking. This involves breaking the long-running portion of your project’s AppleScript code out into a separate script, and then running that script in its own Unix task. However, you want to do this in a way that keeps all the benefits of running AppleScript code within the FaceSpan environment (delegation, access to the UI, etc.).

The answer is to use AppleScript’s parent property to link the forked script back to the FaceSpan responder (e.g. a button) that forked it. Here’s a simple example of a long running AppleScript that uses this technique:

using terms from application "Forking" -- the name of the FaceSpan project
    property parent : application "Forking"'s pushMe
    --  From this point onward, all commands and property access is directed
    --  at the "pushMe" button.  Note that this includes scripting addition
    --  commands!

    on doSomethingTimeConsuming()
        delay 1
    end doSomethingTimeConsuming

    try
        --  Simulate a long-running AppleScript task
        repeat with i from 1 to 10
            reportProgress(i) -- tell the main app how far we have gotten
            doSomethingTimeConsuming()
        end repeat

        --  To send commands to the process running this script rather than
        --  the main FaceSpan application, you must do the following:
        tell current application to current date

        --  Report back to the main application that we are finished
        reportAllDone()

        --  Prove that this code can be written as if its running in FaceSpan:
        display alert "Done" ¬
            message "I've finished wasting some time" ¬
            buttons "OK" ¬
            over my window
    on error errMsg
        set responderName to get my name
        display alert "Runtime Error" ¬
            message "Error in " & responderName & "'s forked script: " & errMsg ¬
            buttons "OK" ¬
            over my window
    end try
end using terms from

This code is saved as a standard AppleScript compiled script using Script Editor/Script Debugger in a file within the FaceSpan project’s bundle.

Now you are ready to fork the script from FaceSpan:

on action theObject
    set enabled to false

    --  Fork off a process running an AppleScript that thinks its running in
    --  the context of this object (button)...
    set theCommand to "osascript " & ¬
        quoted form of (POSIX path of (path to resource "fork.scpt"))
    tell (make new task ¬
        with properties {command:theCommand, auto delete:true})
        start
    end tell
end action

--  Subroutines that the forked script can call to tell the main application
--  what's going on:
on reportProgress(theProgress)
    set title to "Progress: " & theProgress
end reportProgress

on reportAllDone()
    set title to "Push Me"
    set enabled to true
end reportAllDone

Notes:

• since the forked script runs in a FaceSpan task, you could use the task’s ‘task did end’ event to discover when the forked script completes instead of the reportAllDone() subroutine.
• if you need to abort the forked script for some reason (e.g. the user pressing a Cancel button), you can tell the FaceSpan task to stop.

This seems like such an important thing to be able to do that I’m working on integrating this capability directly into the FaceSpan runtime for a future build.

UPDATE: The FaceSpan 5.0d42 build provides this capability with the new fork command. The fork command accepts an AppleScript script object that is executed in a seperate process, thus allowing for long-running operations that don’t block the UI.