/ download / 0-9-1

SWT Support

Introduction

E started out adapting AWT and Swing for use as its GUI Toolkit library. In order to allow locally untrusted code, such as caplets, to have a user interface, we would have to tame these libraries to follow capability discipline. As part of the DarpaBrowser exercise, we attempted a first draft taming of AWT/Swing. The section "Taming the Java Interface" of the Darpa Security Review explains taming as well as many of the problems we ran into. Although we have fixed essentially all of the particular problems this document enumerates, the sheer size of the AWT/Swing APIs presents a huge hurdle for the taming process, and makes it implausible we will ever have confidence in the result.

We examined several alternatives, but nothing seemed very attractive until we came across the Standard Widget Toolkit, or SWT, of IBM's Eclipse project. As of 0.8.20 we now have support for SWT integrated into E. SWT is already largely tamed, and we already have an experimental rewrite of eBrowser (our code editor for E) using SWT rather than AWT/Swing.

Besides uniquely meeting our requirements, SWT gives us several other advantages:

• It's platform look-and-feel conforms to the platforms much more closely than do AWT/Swing. It also simply looks and feels better.

• It works with GCJ, giving us hope that ENative will be able to have the same GUI API as E-on-Java. (Indeed, if GCJ comes to meet E's requirements, then ENative and E-on-Java may be different compilations of essentially the same source.)

• Being smaller and simpler doesn't just make it more tameable, but also easier to learn and use.

See MarcS' message E and SWT for further pros and cons of Swing vs SWT for use by E.

Integrating support for SWT into E presented several interesting issues...

New E Command Line

You can get help on command line of the 'e' driver script (a bash script) by typing

$ e --help

As of 0.8.20, the resulting help text is now:

e [-options] [script [args...]]
where options are:
  -cpa <afterpath>     Adds to end of classpath.
  -cpb <beforepath>    Adds to beginning of classpath.
  -D<name>=<value>     Defines Property.  Passed to java.
  -J<java-option>      java-option passed to java.
    For example, "e -J-version" shows the Java version.
  --help               Prints this out and exits.
  --show               Shows the java command line, rather
                       than executing it.
--start=<runnerKind>   Determines the initial runner's kind.
       Where <runnerKind> is one of
           awt         Initial vat runs in the AWT event
                       loop and thread
           swt         Initial vat runs in the SWT event
                       loop and thread
           headless    Initial vat runs in its own event
                       loop and thread
and script is one of
  <filename>.<ext>     The E script file to execute.
               If --start=<...> is not provided, <ext>
               determines the runnerKind, and must be one of
               'e', 'e-awt', 'e-swt', or 'e-headless'.
               ('e' is deprecated and currently defaults to
                'e-awt'. It will default to 'e-swt', at
                which point it will be undeprecated.)
  -            Use stdin as script file.
               runnerKind is determined as if <ext> is 'e'.
  --interact   An interactive command line.
               runnerKind is determined as if <ext> is 'e'.
no script & args is equivalent to "--interact"

The important changes are shown in bold above -- the two ways of specifying what kind of Runner is used to run the initial vat, and therefore the E script being specified. These two ways are via the new "--start=..." option, and via newly recognized extensions: ".e-awt", ".e-swt", and ".e-headless". On platforms where E's installation causes extensions to be recognized for launching (currently only MSWindows platforms), 0.8.20 causes these new extensions to be recognized as well.

To get the effect of the old "--headless" option, no longer supported as of 0.8.20, use "--start=headless" instead. Except for this change, the new e driver command line is upwards compatible from the old.

Rationale

A Runner is an event-loop together with the thread servicing the event-loop. AWT and SWT each have their own event-loop mechanism, and in order for E objects (whether written in ELib or the E language) to access and be accessed from AWT or SWT widgets respectively, their vats need to run within the Runners built to run within these event loops. The third kind of Runner, headless, is an event-loop and thread built just for running E objects.

Because we must choose a kind of Runner before we can execute E code within that Runner, it would have been awkward to place the runner-kind directive within the startup E script, such as with a pragma statement. We would have liked to add the above "--start=..." command-line option to the e driver invocation on the "#!" line, such as

#!/usr/bin/env rune --start=swt   # broken, since #! only allows one option

but the "#!" mechanism, for some stupifying reason, only supports one option, and we've already used up that budget by using the /usr/bin/env program to avoid pinning the location of the e driver. We could have decided to create wrapping shell scripts, e-awt, e-swt, and e-headless to be used after /usr/bin/env, where these would pass all their arguments to the e driver in addition to a "--start=..." argument. But on platforms like MSWindows, that do extension-based launching and ignore the #! line, we'd also have to enhance the E interpreter to read and process the #! line. What a mess. In the end it seemed simpler to encode the choice in the extension. (Both these choices seem ugly. If you know of a better alternative, please let us know.)

Native Code and java.library.path

New Platform Build and Install Hell

Draft SWT eBrowser

New swtGrid__quasiParser

New Features

New Bug

Instance Variable Binding Properties

elib.runner splits off from elib.prim