Cellsprings Help: Desktop Edition Specifics

Some Advantages of Cellsprings/DT over Cellsprings/Web

Install "springlet" classes by merely placing them in a directory set aside for the purpose. Thus, if you have a compatible Java compiler, you can easily program your own rules and rule families that run in Cellsprings
Save GIF movies with no arbitrary size limits.
Import GIFs from any source to serve as CA seeds.
Import GIF color palettes.
You're not limited to the Java runtime environment (RE) provided by browsers. Some REs run Cellsprings much better than others, so the more options the better.
Users of non-Win32 OSes can often boost performance greatly by tweaking a configuration option exposed by the desktop version.

System Requirements

Cellsprings/DT requires that you have a functioning JDK1.1-compatible Java desktop runtime environment (RE) installed on your system. Further, if you want to compile springlets, a developer's Java installation must be available (usually called a JDK or SDK). Cellsprings makes no system demands beyond those already required for the RE, other than the trivial amount of diskspace taken up by the application files.

As of yet Cellsprings/DT has received only limited testing across environments. All told, 5 desktop REs for Win32 and Linux received at least a cursory trial. Sad to say, the range of performance was large. See the Known Problems page for some details. By way of summary, Sun 1.1.8 and IBM 1.1.8 provided the best performance on Win32 and Linux respectively, though in the latter case speed came at the price of annoyingly jerky update. (BTW, maybe I'm missing something, but Sun's later versions seem to be downgrades as far as realtime apps are concerned. Fortunately, it's easy to install 1.1.8 as a second RE.)

Since there's more to the world than Win32 and Linux - and, for that matter, there's more to Win32 and Linux than were covered in my trials - the status of Cellsprings/DT is best described as "experimental". (In particular, some features of the application probably won't work right on Mac/MRJ - though I'm hopeful that it will at least run, since the applet edition does.) But if you were squeamish about being a guinea pig, you wouldn't be a Java user, right? - so lets go.

Installation

There's not much to installing Cellsprings, though it assumes some basic knowledge of your system. (There is no "one-click installation program", nor is any contemplated.) The following instructions make specific reference only to the Win32 and Unix platforms, but it is hoped that those savvy enough to run Java applications on other platforms will be able to make the appropriate transpositions.

Expand the download package

Expand the download package in the directory (folder) you want the application's base directory to live in. Make sure you unzip it with the unzipping program's directory-preserving option turned on. (This is the default for most GUI-driven unzippers.)

Configure a launching script

The simple command script files csprings.bat and csprings.sh for running the program under Win32 and Unix respectively will be found in the installation's bin subdirectory. Before a provided script can be used to launch the application, it must be configured - but this is just a matter of loading the script into a text editor and editing a path or two. Instructions are in the script file comments. Basically, all the script does is automate calling the java interpreter on the startup class in a way that sets the classpath properly. The Windows batch file assumes it will be run where it is (i.e., that the bin subdirectory will be the startup directory) and only needs information about the desired java launcher. The Unix shellscript wants an additional piece of info, viz., the absolute location of the Cellsprings installation, should the script be run from somewhere else.

BTW, in case you're wondering, the classes JAR file cannot be "self-executing", because part of the classpath must lie outside the JAR in order to support the springlets feature using the default class loader. I could have implemented my own class loader, but it hardly seemed worth it just for that.

Running Cellsprings

On Windows you can just double-click the csprings.bat file to run Cellsprings, but you'll probably want to make a shortcut to that file and put the latter on your start menu, desktop, or whatever. On Unix use your favorite method to run the csprings.sh script or its equivalent. As indicated above, the shellscript template was designed with location-independence in mind - if configured as suggested it can be copied elsewhere and still work.

User options

After you've played with the program a bit you might want to look in the lib subdirectory for the files win.user.props and unix.user.props. If you edit one of these files in a text editor and save it with the name user.props, it will be read by Cellsprings at startup and override the defaults for the options you have specified. (The main motivation for OS-specific versions was the fact that some text editors don't handle non-native line terminators properly.) Information on the available options and how to set them is in the files themselves. If you're on Unix or another non-Win32 OS, be sure to check out the 'misc.minsleepmillis' parameter. Under some REs the performance gains from adjusting it are considerable.

Springlet Installation

Cellsprings/DT lets you install arbitrary rulespaces via the "springlet" mechanism. To install a springlet you merely place its class file in the lib/springlets directory. (If you compile a source file in the src/springlets directory using a provided script, the class file will end up in the right place. Springlet programming is discussed on a separate page.) Warning: When you drop a compatible class file in the lib/springlets directory, you are installing executable code on your computer. There is nothing to stop a malicious third-party springlet from damaging your system. Please read the security notes below before installing a springlet.

Security Issues

Because the springlet feature lets you install third-party binary code, it introduces a security issue. You should exercise the same caution when obtaining and installing springlets as you would with standard executables, since it is theoretically possible for a programmer to write a springlet that intentionally damages your system. Indeed, you might want to be more cautious, as it is unlikely your favorite virus-scanner can detect a springlet trojan horse (since a more obscure threat is hard to imagine :)

The safest thing is to get springlets in source-code form, understand what they do, and compile them yourself. The second safest is to get them from a trusted individual who has done that sort of vetting themselves. One obvious online source of springlets is the reference edition of Cellsprings/Web, since I'll consider anyone's springlet for "publication" therein as long as it is provided in source-code form. Be all that as it may, you're on your own in the matter - I accept no responsibility for the effects of others' code. See the legal page for a statement on the matter.